Re: [bess] Questions and comments regarding draft-ietf-bess-rfc7432bis-02

[Alexander Vainshtein <[e-mail]>]

Luc,
Lots of thanks for a detailed response and apologies for my delayed reaction.
Please see some comments inline below.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Luc André Burdet <[e-mail]>
Sent: Monday, March 7, 2022 8:17 PM
To: Alexander Vainshtein <[e-mail]>om>; [e-mail]
Cc: [e-mail]
Subject: [EXTERNAL] Re: [bess] Questions and comments regarding draft-ietf-bess-rfc7432bis-02

Hi Sasha,

Thanks for the careful review.
Please see comments inline, for the changes incorporated you will see them in -04

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]<mailto:[e-mail]>  |  Tel: [phone]


From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 22, 2022 at 05:00
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [bess] Questions and comments regarding draft-ietf-bess-rfc7432bis-02

Hi all,
I have some new questions regarding this draft.


  1.  The definition of the F flag in the Layer 2 Attributes Extended Community in Section 7.11 of the draft<https://clicktime.symantec.com/3Tkj3g3JsbhhaurZz57Ebhd6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-rfc7432bis-02%23section-7.11>  (added to the list of flags defined in RFC 8214) says that, If this flag is set to 1, a Flow Label MUST be present when sending EVPN packets to this PE. If set to 0, a Flow Label MUST NOT be present when sending EVPN packets to this PE.
     *   I am not sure whether the first MUST is a good idea because the receiving PE can always recognize presence or absence of the Flow Label in the label stack by:

                                                               i.      The "application" label (advertised in the appropriate EVPN route) not being marked as Bottom of Stack

                                                             ii.      The label following it not being in the range of reserved (special purpose) labels

     *   This is different from the situation with the C flag in the same extended Community, because presence or absence of the Control Word cannot be recognized by the receiving PE
     *   The second MUST (that would indicate inability of the receiving PE to handle received Flow Labels) is, of course, OK
     *   May I suggest that you replace the first MUST in the definition with "MAY" (leaving the decision to include or not to include the Flow Label to the ingress PE)?
[LAB] I updated the MUST to a SHOULD because you make a valid point re: detection at the receiving PE.  This is even expanded upon in Section 18.1.
The intent is that the ingress PE "SHOULD when capable itself, impose FL" when the remote asks for it.
SHOULD because its ability to impose FL is really based on its own local capability as well, not just remote's request. Remote/egress will understand both as you describe => updated 18.1
[[Sasha]] Great, lots of thanks!


     *   I also wonder if you plan to request an early allocation of the F Flag in the appropriate IANA registry<https://clicktime.symantec.com/3BgcurwGbwtUkx6rC4FSoC46H4?u=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-extended-communities.xhtml%23evpn-layer-2-attributes-control-flags>
[LAB] it is RFC-Required type not FCFS, but it's a good idea to email them
[[Sasha]] I have looked up Section 2 of RFC 7120<https://datatracker.ietf.org/doc/html/rfc7120#section-2> and it lists the following conditions for early allocation of code points:
   a.  The code points must be from a space designated as "RFC
       Required", "IETF Review", or "Standards Action".  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC.

   b.  The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an Internet-Draft.

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

   d.  The Working Group chairs and Area Directors (ADs) judge that
       there is sufficient interest in the community for early (pre-RFC)
       implementation and deployment, or that failure to make an early
       allocation might lead to contention for the code point in the
       field.
As I see it, (a), (b) and (c) are satisfied. As for (d), this thread may be (hopefully) considered as an indication of "sufficient interest in the community".


  1.  The draft includes references to the DF Election procedure defined in RFC 8584<https://clicktime.symantec.com/3DQVomwANEAkrBUP9t9CWkd6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8584>84>. However, it seems to ignore AC-influenced DF Election capability  defined in Section 4 of this document, and its implications. In particular:
     *   Without AC-influenced DF Election procedure:

                                                               i.      Attachment of an EVI to a Single-Active Multi-Homing ES has to be instantiated in every PE to which this ES is attached:

                                                             ii.      This justifies the requirement in Section 6.3 of RFC 7432 to use the numerically lowest VLAN value in the default DF Election algorithm for EVI that implement VLAN Bundle and VLAN-aware Bundle service interface

     *   With AC-influenced DF Election procedure:

                                                               i.      It is possible for a specific Bridge Table in an EVI that implements VLAN-aware Bundle service interface to be instantiated in some, but not all PEs attached to a given Single-Active Multi-Homing ES

                                                             ii.      As a consequence, Section 4.1 of RFC 8584 has redefined the DF Election scheme for the EVI that implements VLAN-aware bundle service interface, so that DF is elected per Bridge Table and uses just the VLAN attaching a specific Bridge Table to the MH ES in question

     *   May I suggest that you incorporate the AC-influenced DF Election scheme (with its implications for DF election for the EVI  that implement VLAN-aware Bundle Service interface in the draft?
[LAB] I went over that section again and put 7432 and 8584 side by side to get clarity. If you look carefully at the changes in 7432bis re: a clearer definition of "Ethernet tag" I think that improvement already addresses your concern.
The only change RFC8584 adds is the candidate list based on including presence of EtherA-D per EVI.  The DF itself does not change and 8584 only added the clarifying "as the Ethernet Tag" which is already addressed with the new terminology ?
[[Sasha]] I have re-read the relevant text in Section 8.5 of 7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-03#section-8.5>.5>, and it explicitly states that "For VLAN-Aware Bundle service, then the numerically lowest Ethernet tag in that EVI MUST be used in the modulo function"   which, to me, means that the DF is elected per <ES, VLAN Bundle> while Section 4 of RFC 8584<https://datatracker.ietf.org/doc/html/rfc8584#section-4> states that "a PE will perform a DF election per <ES, VLAN>, as opposed to per <ES, VLAN Bundle>".  I.e., 8584 allows normal operation of  an EVI that is attached to a specific MH ES in Single-Active mode with AC-influenced DF election in some, but not all PEs that are attached to such a MH ES, while 7432bis makes such configuration problematic. What, if anything, did I miss?



     *   Additionally, may I suggest that Section 6.3 of the draft would clarify that, for a Bridge Table of an EVI that is attached to a MH ES the per EVI Ethernet A-D route would be also advertised with the "aliasing" label for this Bridge Table and an appropriate Ethermet Tag ID? The current text (inherited from RFC 7432) only mentions Label1 field in the EVPN MAC/IP routes advertised for each Bridge Table

[LAB] that's pretty clear and straightforward, I see no problem adding that.


     *   Last but not least, the text in Section 8.5 of the draft differs from the original text in  Section 8.5 of RFC 7432 when it comes to DF election for EVI that implement VLAN Bundle and VLAN-aware Bundle service interface (the differences are highlighted):

                                                               i.      The latter document says "In the case of VLAN-(aware) bundle service" meaning that the text applies to both VLA Bundle and VLAN-aware Bundle service interface

                                                             ii.      The former (i.e. the draft) says "In the case of VLAN-aware bundle service" i.e. EVI that implement VLAN Bundle service interface from the definition are excluded

                                                           iii.      This looks as a simple type and should be trivial to fix.


[LAB] Actually, if you look at the whole paragraph the mention of ", for VLAN-based service," was removed implying the DF/ordinal of the first sentence applies to all modes. The qualifier "use lowest ETag" applies really only to VLAN-Aware Bundle now.

[[Sasha]] Please see above.

Hopefully these notes will be useful. Your feedback will be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.