Luc,
Lots of thanks for a detailed response and apologies for my delayed reaction.
Please see some comments inline below.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
From: Luc André Burdet <[email protected]>
Sent: Monday, March 7, 2022 8:17 PM
To: Alexander Vainshtein <[email protected]>;
[email protected]
Cc: [email protected]
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 |
[email protected]<mailto:[email protected]> | Tel: +1 613 254 4814
From: BESS <[email protected]<mailto:[email protected]>> on behalf of
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Tuesday, February 22, 2022 at 05:00
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
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>.
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>,
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: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
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._______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
