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

[Alexander Vainshtein <[e-mail]>]

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

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.