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: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@rbbn.com
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._______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
