Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)

[Rabadan, Jorge (Nokia - US/Mountain View)]

Benjamin,

Thank you very much for your review.
Satya and I have looked at your points one by one, please see in-line. Let us 
know if you are ok now. We'll publish revision 08 soon.
Thanks.
Jorge

-Original Message-
From: Benjamin Kaduk 
Date: Tuesday, January 8, 2019 at 6:52 PM
To: The IESG 
Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
, Stephane Litkowski 
, "bess-cha...@ietf.org" , 
"stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Benjamin Kaduk's Discuss on 
draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Resent-From: 
Resent-To: , , 
, , , 

Resent-Date: Tuesday, January 8, 2019 at 6:51 PM

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/



--
DISCUSS:
--

   
It's not really clear to me that the question of Updating 7432 has been
settled by the responses to the directorate reviews; I've noted a few
places in the text that are problematic in this regard, in the COMMENT
section.
   
   [JORGE] We finally agreed on making it updating 7432 and explain why in the 
intro/abstract. Thanks.
   

[concerns about combinatoric explosion were overblown; removed]
   
Section 3.3
   
   Section 7.6 of [RFC7432] describes how the value of the ES-Import
   Route Target for ESI types 1, 2, and 3 can be auto-derived by using
   the high-order six bytes of the nine byte ESI value. The same auto-
   derivation procedure can be extended to ESI types 0, 4, and 5 as long
   as it is ensured that the auto-derived values for ES-Import RT among
   different ES types don't overlap.
   
How do I ensure that the auto-derived values don't overlap?
   
[JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used 
"only if it produces ESIs that satisfy the uniqueness requirement specified 
above." RFC7432 does not specify how the overlap is avoided, it is out of 
scope, but one may think the operator must manually check that the values 
auto-deriving the 9-octet ESI value don't match. We added the following text, 
let us know if it is okay:
"As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or 
ES-import RT values for different ESIs do not match is out of scope of this 
document."
   
Section 4.2
   
 The ESI value MAY be set to all 0's in the Weight
   function below if the operator so chooses.
   
I'm not 100% sure I'm interpreting this correctly, but this sounds like 
a
piece of device-specific configuration (i.e., configured by the 
operator)
that must be the same across all devices for correct operation, but is 
not
covered by the advertisement of the DF Election Exctended Community.  
This
would decrease the robustness of the system to basically the 
"experimental"
level of DF election algorithm 31, which also relies on universal 
agreement
of manual configuration.  Is this actually something we want to include?
   
[Satya] This is to accommodate the case in 
https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00.
Specifically, if the same set of PES are multi-homed to the same set of ESes, 
setting the ES to 0, would result in the "same unique" PE be the DF for a given 
EVI for all those ESes.
Use can be made of this property in the optimization in 
https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00.
Yes, it would need manual configuration to enable this.
   
Section 5
   
   The AC-DF capability MAY be used with any "DF Alg" algorithm. It MUST
   
As written, this suggests that it is true for any current or future
algorithm, which is in conflict with the text in Section 3.2 that notes
that "for any new DF Alg defined in future, its 
applicability/compatibility
to the existing capabilities must be assessed on a case by case basis." 
 It
seems more prudent to make the assessment after the relevant 
technologies
are both extant, so I would suggest this be non-normative text, perhaps
"the AC-DF capability is expected to be of general applicability with 
any
  

Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

[Alvaro Retana]

On January 17, 2019 at 12:55:33 AM, Rabadan, Jorge (Nokia - US/Mountain
View) (jorge.raba...@nokia.com) wrote:

Hi!

Thanks for all the answers.

I’ll leave any decision to change up to Martin. :-)

Thanks!

Alvaro.



(6) The HRW1999 reference must be Normative.
[JORGE] please check out the discussion with Adrian and Satya related to
this, where Adrian recommended to move it to informative references.
https://www.ietf.org/mail-archive/web/bess/current/msg03740.html

I don’t think that was Adrian’s intent when he said: "HRW1999 is provided
as a normative reference, and from the text I can see why.”

In any case, I think the reference has to be Normative because HRW "must be
read to...implement the technology in the new RFC”.

https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/

[JORGE] we can change it as long as it does not create any issues. By the
way, sorry, I provided the wrong Adrian’s email. I should have sent this:
https://mailarchive.ietf.org/arch/msg/bess/T47tlmuswbj1VFDh5QkA-p8ZMHc

“In general (and I think your draft is an example of this) it is possible
to describe/rewrite the pieces of normative text without infringing
copyright. That usually reduces the reference to Informative and provides
enough information in the RFC for implementation. Your draft is an example
of this because you have described the algorithms in your text with enough
detail to allow an implementation: the reference is really only there to
provide context and proof of the algorithms. (And anyway, having found a
freely accessible copy of the reference in your draft, we are probably home
and dry.)”

Let us know if you still want us to change it to normative, please.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Alvaro,

Thank you very much. Please see in-line.
Thx
Jorge

From: Alvaro Retana 
Date: Wednesday, January 16, 2019 at 11:49 PM
To: The IESG , "Rabadan, Jorge (Nokia - US/Mountain View)" 

Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" , Stephane Litkowski 

Subject: Re: Alvaro Retana's No Objection on 
draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

On January 15, 2019 at 7:49:53 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
(jorge.raba...@nokia.com) wrote:

Jorge:

Hi!


...
(b) Form that text, what I get is that a new algorithm can define the meaning
of the bits. Is that correct? If so, (1) s/a specific DF Alg MAY determine
the use/a specific DF Alg MUST/SHOULD determine the use ...and... (2) for DF
Algs 0 and 1, what happens if any of the other bits are set?
[JORGE] the use of the reserved bits for any future DF Alg is optional, so, a 
MAY should be fine? I changed the text to:

The use of the bits is optional, yes.  But because each DF Alg may use the bits 
in a different way, I think that each DF Arg MUST specify how the bits are 
used.  If there’s no use for the bits, then a future DF Alg should still 
specify how they are used: ignored when received.
"- In general, a specific DF Alg MAY determine the use of the
reserved bits in the Extended Community, which may be used in a
different way for a different DF Alg. In particular, for DF Algs
0 and 1, the reserved bits are not set by the advertising PE and
SHOULD be ignored by the receiving PE."

Maybe if you changed the “In particular…” text to apply to every DF Alg (unless 
specifically specified in the future) then I think we could be ok with a MAY 
above.

[JORGE] ok, I think I understood now what you meant. I changed it to:

“- In general, a specific DF Alg SHOULD determine the use of the reserved bits 
in the Extended Community, which may be used in a different way for a different 
DF Alg. In particular, for DF Algs 0 and 1, the reserved bits are not set by 
the advertising PE and SHOULD be ignored by the receiving PE.”

BTW, why only SHOULD and not MUST?

[JORGE] why a PE SHOULD ignore the received rsv bits? Well, there may be other 
specs in the future that use DF Algs 0 or 1 and change the rsv bits (in fact 
there is one already). So I guess we want to leave a window open to that 
possibility.


(5) §3.2: "if even a single advertisement for the type-4 route is not received
with the locally configured DF Alg and capability, the Default DF Election
algorithm (modulus) algorithm MUST be used" Given that the PEs advertise only
their preferred algorithm/capability, it is possible that it also supports
other algorithm/capability combinations, which may have been advertised. I
assume that it is up to the implementation if they want to update their
advertisement. Do you want to say anything about this? Are there potential
downsides to an implementation changing their preferred combination?
[JORGE] If the advertised ext community is not consistent across all the PEs in 
the Ethernet Segment, the DF Alg falls back to the default DF Alg. This is 
added in this section and also in the security section. Besides these two 
bullets have been modified for clarity and completeness. Let us know if you are 
not ok with it.
"- Otherwise if even a single advertisement for the type-4 route is received 
without the locally configured DF Alg and capability, the Default DF Election 
algorithm (modulus) algorithm MUST be used as in [RFC7432]. This procedure 
handles the case where participating PEs in the ES disagree about the DF 
algorithm and capability to apply.
- The absence of the DF Election Extended Community or the presence of multiple 
DF Election Extended Communities (in the same route) MUST be interpreted by a 
receiving PE as an indication of the Default DF Election algorithm on the 
sending PE, that is, DF Alg 0 and no DF Election capabilities."

Yes, that text is fine with me.

The comment I tried to make above is different.  Let me try to give an example 
— let’s assume that 3 algorithms have been defined: the default and 2 more (A1 
and A2).  Let’s assume that all PEs support all the algorithms, and that all, 
except 1 prefer A1 — the other router (R2) prefers A2.  In this scenario 
neither A1 nor A2 will be used…  My question above was along the lines of: if 
R2 prefers A2, then A1 and then the default…then it can advertise A1 once it 
sees that all other PEs prefer that…resulting in something better than the 
default.

[JORGE] in the past we discussed something like that but decided to keep it 
simple to avoid having route type 4 updates coming back and forth and make the 
DF Election more complicated. So at the moment implementations always fall back 
to default when there is no unanimity.


(6) The HRW1999 reference must be Normative.
[JORGE] please check out the discussion with Adrian and Satya related to this, 
where Adrian recommended to