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.
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./
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?
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. /
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?
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://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml)
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?
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].
The error handling does not handle what happens if geneve encapsulation is
in a extended community.
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.
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?
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.
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.
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.
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
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.
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
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]. /
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. /
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
