CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL
nok.it/ext for additional information.
Reviewer: Susan Hares
Review result: Has Issues
This is OPS-DIR review. It should be take as any other WG LC comments
Status: Has Issues and editorial NITS
Summary:
My main concerns are:
1) RFC9012 related concerns
(a) descriptions associated with RFC9012 in sections 2.2 and 3.0 of this
document, (b) Warnings about RFC9012 + RFC8365 interactions in Appendix A of
RFC9012 (c) Lack of clarity of draft-ietf-bess-evpn-geneve in RFC9012 usage.
2) Error handling
a) Lack of Error handling section
b) assumptions on NVE actions under local bias (see section 1.2)
What is good about the draft:
a) Clear description and discussion of ESI Label-based Split Horizon and Local
Bias, b) Clear delineation of default (Table 1) c) Consideration of BUM traffic
==========
RFC 9012 issues
1) Section 2.2 paragraph 2 states:
current text:/
As an example, egress NVEs that support IP-based MPLS tunnels, such
as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES
along with the BGP Encapsulation extended community, as defined in
[RFC9012]. This extended community indicates the encapsulation type
(MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to
signify the intent to use Local Bias or ESI Label, respectively./
/
It would be helpful to link this to a Encapsulation tunnel type in
RFC9012 or other documents.
Based on the definitions in your introduction:
* MPLSoUDP: Multi-Protocol Label Switching over User Datagram
Protocol, [RFC7510]
* MPLSoGRE: Multi-Protocol Label Switching over Generic Network
Encapsulation, [RFC4023].
What are the correct BGP Encapsulation tunnel types that MPLSoUDP and
MPLSoGRE utilize in the extended community? Are you intending the following:
* MPLSoGRE: Multi-Protocol Label Switching over Generic Network
Encapsulation, MPLS-in-GRE (RFC9012 Tunnel type 11)
* MPLSoUDP: Multi-Protocol Label Switching over User Datagram
Protocol, [RFC7510], UDP Destintaion port (RFC9012 tunnel type 7)?
If so, please specify in the text. If not, please indicate what are the
valid RFC9012 tunnel types for these symbols.
[jorge] we added a reference to the IANA registry and the corresponding tunnel type in the registry. Hopefully that clears the concern.
2. Section 2.2, paragraph 3, needs to give a direct link to RFC9012
tunnel types.
Current text:/
An egress NVE MUST NOT use an SHT value other than 00 when
advertising an A-D per ES route with encapsulation types such as
VXLAN, NVGRE, MPLS, or no BGP tunnel encapsulation extended
community, as specified in [RFC9012]. /
Proposed text:/
An egress NVE MUST NOT use an SHT value other than 00 when
advertising an A-D per ES route with RFC9012 Tunnel encapsulation
types of VXLAN, NVGRE, and MPLS Label stack./
[jorge] added this:
“An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with [RFC9012] Tunnel
encapsulation types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP tunnel encapsulation extended community at all.”
Question to authors:
What did you mean "No BGP tunnel encapsulation extended community"?
If BGP passses a [RFC9012] tunnel, it must come with a tunnel type.
Are you suggesting there is no "Encapsulation Extended Community"
Attached?
[jorge] Yes, from RFC8365:
“The MPLS encapsulation tunnel type, listed in
Section
11, is needed
in order to distinguish between an advertising node that only
supports non-MPLS encapsulations and one that supports MPLS and
non-MPLS encapsulations. An advertising node that only supports MPLS
encapsulation does not need to advertise any encapsulation tunnel
types; i.e., if the BGP Encapsulation Extended Community is not
present, then either MPLS encapsulation or a statically configured
encapsulation is assumed.”
3. section 2.2, paragraph 4, Geneve tunnel
Current text:/
An egress NVE advertising A-D per ES route(s) for an ES with GENEVE
encapsulation MAY use an SHT value of 01 or 10. /
New text:/
An egress NVE advertising A-D per ES route(s) for an ES with GENEVE
tunnel encapsulation [RFC9012, I-D.ietf-bess-evpn-geneve]
MAY use an SHT value of 01 or 10. /
[jorge] added references.
4. issue with Geneve specification (draft-ietf-bess-evpn-geneve)
RFC9012 only allows the Encapsulation Community to specify
RFC9012 tunnel type. draft-ietf-bess-evpn-geneve specifies
tunnel type Geneve (Value=19) and the Geneve Tunnel Options SubTLV
for the EVPN (AFI: 25/ SAFI: 70). This definition indicates
that the Geneve tunnels must have a Tunnel Encapsulation attribute
with SubTLVs.
draft-ietf-bess-evpn-geneve does not specify:
a) What SubTLVs are valid for the Genve Tunnel Type in
the Tunnel Encapsulation attribute.
b) What validation procedures are used for the Geneve tunnel type
with the tunnel encapsulation attribute.
c) What happens if the Geneve tunnel type is specified on the
Encapsulation Extended Community and a
tunnel Encapsulation Attribute?
d) What happens if the Geneve Tunnel type is specified
in the Encapsulation Extended Community?
[jorge] I agree those things can be clarified in draft-ietf-bess-evpn-geneve, it would be great if you can let the authors know your comments about this draft (I’m one of them,
but it would be great if you can send all the comments relevant to that draft in a separate email, please. Thanks for bringing this up.
5. Need complete specification on what [RFC9012] tunnels are supported
by this procedure. Please add a section or a table that indicates which
tunnel types can be used for section 2.2 and 2.3.
For example, is the Prefix-SID [RFC9012] a valid encapsulation?
(see
https://eur03.safelinks.protection.outlook.com/?url="">
[jorge] table 1 specifies the encapsulations supported by this document, and then their definition is in section 1.1. That should address your comment.
6. Section 3, NVE announces multiple A-D with multiple Encapsulations
If you have multiple A-D per ES routes for the same ES,
will you have multiple encapsulation communities?
[jorge] yes, as per RFC8365, which we refer to in this section.
Section 3 - in the 4th paragraph suggests this point in the text:
text:/
a. An A-D per ES route for ES-x may be advertised with multiple
encapsulations, some of which support a single Split Horizon
method. In this case, the Split Horizon Type (SHT) value MUST be
00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN,
GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an
A-D per ES route. In all these cases, the SHT value MUST be 00./
In addition, the GENEVE Encapsulation
(per draft-ietf-bess-evpn-geneve-08.txt) can only be passed in
a Tunnel Encapsulation Attribute [RFC9012].
[jorge] for the A-D per ES route yes, I agree. Not for the other EVPN route types.
The error handling does not handle what happens if geneve encapsulation is
in a extended community.
[jorge] please check the version 11 diff for section 3. It addresses your comments.
7. Why does the text not suggest the possiblity of
using the Tunnel Encapsulation Attribute as well as the encapsulation
community?
It seems that the SRv6 work would hint that the
tunnel encapsulation Attribute should be considered in this
draft.
[jorge] this document does not define the procedures for each encapsulation. The scope is only the split horizon filtering procedures for the already defined encapsulations in
EVPN. The specifications for EVPN and the different encapsulations are RFC8365 (for all NVO encapsulations), RFC7432 for MPLS, RFC9252 for SRv6, I-D.ietf-bess-evpn-geneve for GENEVE. Those specs define if the BGP encapsulation extended community or BGP Tunnel
Encapsulation Attribute (or no indication of the encapsulation at all) is used along with the EVPN routes.
Procedures + Error issues
1. Section 1.1, paragraph 2 - Local Bias Description could help build the case
for NVE errors
a) How does NVE track the IP Addresses(es) of other NVEs with which it shares
multihomed ESs? What happens to local bias if the following occurs: a) NVEs
incorrectly miss the IP addresses of other NVEs on the same multihomed ES. b)
What happens if NVE does not filter out frames on the local interfaces
connected to ESs that are shared with the same ingress NVE?
[jorge] RFC8365 is the specification about local-bias and how the NVE tracks other NVEs. This document does not alter the local-bias specification. I would suggest to go through
RFC8365 and if needed, discuss with the RFC8365 authors. As a WG participant I can also share my opinion, of course, and I’ll be happy to discuss.
These errors can cause local bias to have errors. It needs to be stated what
happens if these errors occur? There should be some error handling or
"manageability" warnings in the text.
[jorge] We added this note in section 1.2 to clarify that the procedures themselves are not modified:
“Note that this document does not modify the Local Bias or the ESI Label Split Horizon procedures themselves, just focuses on the signaling and selection of the Split Horizon method
to apply by the multihomed NVEs.”
2) Due to the complexity of the [RFC9012] issues and the
text in sections 2 and 3, it would be good to have a manageability
and an error handling section.
The manageability section should summarize what operators need to configure
and monitor.
The error handling section should include RFC9012 error handling (see comments
above) and what happens when assumptions (see the word "assume" in this text)
does not occur.
[jorge] see resolution of your comments above please. The use of RFC9012 in EVPN for the different encapsulations is specified in other standard documents, we are not modifying
that in this document. Hopefully the new text help clarify the scope.
Editorial NITS:
Nit 1: Section 1.1, MPLS and non-MPLS NVO tunnels, 1st sentence.
Old text:/
* MPLS and non-MPLS NVO tunnels: refer to Multi-Protocol Label
Switching (or the absence of it) Network Virtualization Overlay
tunnels. /
Comment: This sentence is unclear and needs a rewrite. I think you man
MPLS tunnels and non-MPLS NVO tunnels.
[jorge] you’re right, fixed now.
Nit 2: Section 1.2, paragraph beginning "Similarly, certain IP Tunnels -",
In this paragraph, it would be very helpful to provide the sections in
[I-D.ietf-bess-evpn-geneve], [RFC9252], and [RFC8986]
My understanding is [RFC8986]- section 4.12, RFC9252 - section 6.1.1,
draft-ietf-bess-evpn-geneve - section 4.1
[jorge] added, thx
Nit 3: Section 2.1, paragraph 1
It would be helpful to augment the second sentence with the section in
RFC8365 that is the default behavior. I found the default behavior in section
8.3.2. If this is correct, please add this to sentence 2.
[jorge] added “section 8.3.1”, which I think it is what you meant, thanks.
Nit 4: Section 2.1, SHT Bit descriptions
old text/
0 0 --> Default SHT. Backwards compatible with [RFC8365] and [RFC7432]
/
issue: wrap in this text extends past 72 lines, and gets cut off
[jorge] fixed now, thx
Nit 5: Section 2.1, paragraph 3, "treat-as-withdraw behavior".
old text:/ If a route with any of
the mentioned encapsulation options is received and has an SHT value
different from 00, it SHOULD apply the treat-as-withdraw behavior./
new text:/ If a route with any of
the mentioned encapsulation options is received and has an SHT value
different from 00, it SHOULD apply the treat-as-withdraw behavior
per [RFC7606]. /
[jorge] added, thanks.
Nit 6: section 2.2, second to last paragraph, beginning "An egress".
reason: clarity of comma usage
Old text:/ A value of
00 indicates the default behavior outlined in Table 1, which is to
use Local Bias if no ESI-Label is present in the Ethernet option TLV,
or if there is no Ethernet option TLV. /
Suggested new text:/Old text:/ A value of
00 indicates the default behavior outlined in Table 1 which is to
use Local Bias if: a)no ESI-Label is present in the Ethernet option TLV,
or b) if there is no Ethernet option TLV. /
[jorge] added, thanks.
Thanks again for the thorough review!
Jorge
