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

[Luc André Burdet <[e-mail]>]

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]  |  Tel: [phone]


From: BESS <[e-mail]> on behalf of Alexander Vainshtein <[e-mail]>
Date: Tuesday, February 22, 2022 at 05:00
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[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://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-02#section-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


     *   I also wonder if you plan to request an early allocation of the F Flag in the appropriate IANA registry<https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn-layer-2-attributes-control-flags>
[LAB] it is RFC-Required type not FCFS, but it’s a good idea to email them


  1.  The draft includes references to the DF Election procedure defined in RFC 8584<https://datatracker.ietf.org/doc/html/rfc8584>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 ?



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



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]


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.