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

From: Alvaro Retana <[email-masked]>
Date: Tue, 08 Jan 2019 12:50:57 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) Some of my comments are related to Benjamin's DISCUSS.

(1) The FSM in §3.1 applies to rfc7432, the introductory text (in that section)
says as much, and even the text in §1 calls it "a formal definition and
clarification".  I understand that the new procedures are not intended to
update rfc7432 (which is fine), but the fact that this document says that an
"implementation MUST comply with a behavior equivalent to the one outlined in
this FSM" seems like an Update to rfc7432 to me.  Note that the Update can, and
should, be qualified in the Abstract/Introduction, so you can explicitly
indicate what is being Updated and what isn't.

(2) The MAYs in this paragraph (§1.3) are not needed because they are used to
state a fact:

o HRW and AC-DF mechanisms are independent of each other. Therefore,
  a PE MAY support either HRW or AC-DF independently or MAY support
  both of them together. A PE MAY also support AC-DF capability along
  with the Default DF election algorithm per [RFC7432].

(3) "Only one DF Election Extended Community can be sent..."  What should a
receiver do if more than one community is received?

(4) §3.2 -- I'm confused about this text:

  - DF Algs 0 and 1 can be both used with bit AC-DF set to 0 or 1.

  - 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.

(a) This text is assigning a function to the "reserved bits", so they are
really not reserved.  The description should be updated (from "Reserved bits
for future use") to reflect that their interpretation depends on the DF Alg.

(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?

(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?

(6) The HRW1999 reference must be Normative.

(7) [nit] There are a couple of references to other sections on this document
that don't exist: §1.2.2 points to section 2.1, §1.3 to 2.2...

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 15 Jan 2019 15:49:52 +0000

Alvaro,

Thank you very much for reviewing.
Please see in-line to see the resolution of your comments, with [JORGE].

Thx
Jorge

-----Original Message-----
From: Alvaro Retana <[email-masked]>
Date: Tuesday, January 8, 2019 at 9:51 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Alvaro Retana's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, January 8, 2019 at 9:50 PM

    
    
    (0) Some of my comments are related to Benjamin's DISCUSS.
[JORGE] we are fixing all the issues raised by Benjamin. We'll reply in a separate email.

[JORGE] sounds good. We'll "update 7432" in the next revision and will indicate why.

[JORGE] ok, changed to "may" instead of "MAY".
    
    (3) "Only one DF Election Extended Community can be sent..."  What should a
    receiver do if more than one community is received?
[JORGE] we modified this sub-bullet in the same section / next bullet, hopefully it clarifies:
"- 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."

    
    
    (a) This text is assigning a function to the "reserved bits", so they are
    really not reserved.  The description should be updated (from "Reserved bits
    for future use") to reflect that their interpretation depends on the DF Alg.
[JORGE] ok, that's fair. Description changed to:
   "o RSV / Reserved - Reserved bits for DF Alg specific information."
    
    (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:
    "- 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."

    (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."
    
    (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

[JORGE] fixed, thanks.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 16 Jan 2019 14:49:08 -0800

On January 15, 2019 at 7:49:53 AM, Rabadan, Jorge (Nokia - US/Mountain
View) ([email-masked]) 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.

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.

BTW, why only SHOULD and not MUST?

(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.

(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/

Thanks!

Alvaro.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 17 Jan 2019 08:55:32 +0000

Hi Alvaro,

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

From: Alvaro Retana <[email-masked]>
Date: Wednesday, January 16, 2019 at 11:49 PM
To: The IESG <[email-masked]>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>
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) ([email-masked]<mailto:[email-masked]>) wrote:

Jorge:

Hi!

...

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.

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.”

[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.

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.

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”.

[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.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Jan 2019 21:29:22 +0100

On January 17, 2019 at 12:55:33 AM, Rabadan, Jorge (Nokia - US/Mountain
View) ([email-masked]) wrote:

Hi!

Thanks for all the answers.

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

Thanks!

Alvaro.

[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.)”