Following are a few comments (look for lines beginning ****) on
draft-dawra-idr-srv6-vpn-03. The name of the draft notwithstanding, I
think this is clearly a draft that falls within the scope of BESS, so
I've sent my comments to the BESS list. (Also copying the 12 "authors" ;-))
Section 1
...
To provide SRv6-VPN service with best-effort connectivity, the egress
PE signals an SRv6-VPN SID with the VPN route. The ingress PE
encapsulates the VPN packet in an outer IPv6 header where the
destination address is the SRv6-VPN SID provided by the egress PE.
The underlay between the PE's only need to support plain IPv6
forwarding [RFC2460].
**** This suggests that an IPv6 address has to be assigned to each VRF (for
**** per-VRF "labeling"), or even to each CE (for per-CE labeling).
**** Presumably these would be taken from an IPv6 prefix owned by the
**** advertising PE? Or not?
**** If those addresses are routable, doesn't this create a security issue
**** as discussed in RFC 4023 Section 8.2?
Section 3
...
For egress-PEs which supports SRv6-VPN advertises an SRv6-VPN SID
with VPN routes. This SRv6-VPN SID only has local significance at
the egress-PE where it is allocated or configured on a per-CE or per-
VRF basis.
**** The phrase "only has local significance" suggests that these SIDs are
**** not routable. But later on there is a suggestion that they are
**** routable, or at least that they might be.
...
In practice, the SID encodes a cross-connect to a
specific Address Family table (END.DT) or next-hop/interface (END.DX)
as defined in the SRv6 Network Programming Document
[I-D.filsfils-spring-srv6-network-programming]
**** I'm not sure what is meant by "in practice". Aren't these semantics
**** NECESSSARY in order to provide the L3VPN service?
The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
serves the dual purpose of providing reachability between ingress-PE
and egress-PE while also encoding the VPN identifier.
**** Did you mean:
The SRv6 VPN SID MAY be routable all along the path from the ingress-PE
to the egress-PE, and if so, MAY serve the dual purpose of providing
reachability between ingress-PE and egress-PE while also encoding
the VPN
identifier.
**** Though I guess if the SID is routable only in the egress AS, one could
**** tunnel to an entry point of that AS and then route within the AS based
**** on the SID. (Of course this amplifies the spoofing problem discussed
**** in Section 8.2 of RFC 4023.)
**** So there are a number of options:
**** - not routable
**** - globally routable
**** - routable only within egress AS
**** If the intention is to allow all those options, please explain the
**** signaling that lets the ingress PE know which option to use. Or is the
**** intention that this is known a priori (i.e., via provisioning)?
To support SRv6 based L3VPN overlay, a SID is advertised with BGP
MPLS L3VPN route update[RFC4364]. SID is encoded in a SRv6-VPN SID
TLV, which is optional transitive BGP Prefix SID
attribute[I-D.ietf-idr-bgp-prefix-sid]. This attribute serves two
purposes; first it indicates that the BGP egress device is reachable
via an SRv6 underlay
**** Whether the egress PE is reachable via an SRv6 underlay has nothing to
**** do with the presence or absence of the SRv6-VPN SID TLV. The presence
**** of that TLV really only means that the egress PE can handle the SRv6
**** encapsulation for L3VPN.
and the BGP ingress device receiving this route
MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
the value of the SID to include in the SRH encapsulation. For L3VPN,
only a single SRv6-VPN SID MAY be necessary.
**** I don't understand the phrase "only a single SRv6-VPN SID MAY be
**** necessary".
A BGP speaker supporting an SRv6 underlay MAY distribute SID per route
via the BGP SRv6-VPN Attribute.
**** I think you mean "If a PE supports an SRv6 underlay, it may attach the
**** BGP SRv6-VPN attribute to the VPN-IP routes that it originates".
If the BGP speaker supports MPLS based
L3VPN simultaneously, it MAY also populate the Label values in L3VPN
route types and allow the BGP ingress device to decide which
encapsulation to use. If the BGP speaker does not support MPLS based
L3VPN services the MPLS Labels in L3VPN route types MUST be set to
IMPLICIT-NULL.
**** Please provide a reference that specifies how you set the Label field
**** of a SAFI-4 or SAFI-128 route to "implicit null". I don't recall any
**** such thing existing in RFC 3107, 4364, or 8277.
**** If you mean "set to zero", I think that will generally be interpreted
**** in a SAFI-4 or SAFI-128 route as "push on label 0 (explicit null)".
**** If you mean "set to three" (the value defined in RFC 3032 to represent
**** "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
**** generally interpret the value three in that manner.
**** I'm not really sure what you're trying to do here. There are at least
**** four cases to consider:
**** 1. For the case where the backbone doesn't have MPLS, there is no harm
**** in saying "set the label to zero".
**** 2. For the case where the backbone supports both MPLS and SRv6, and
**** some PEs support L3VPN both ways, while others support only MPLS-based
**** L3VPN, then a real label needs to be put in.
**** 3. For the case where the backbone supports both MPLS and SRv6, but a
**** particular egress PE only supports SRv6, there needs to be some way to
**** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
**** presence of the prefix-SID attribute with VPN-SID TLV is sufficient.
**** 4. For the case where the backbone supports both MPLS and SRv6, the
**** egress PE supports both for transit, but the egress PE only supports
**** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a
**** value that will cause the egress PE to discard the packet. If there
**** happens to be an ingress PE that only supports the MPLS style of L3VPN,
**** this will prevent the egress PE from misrouting MPLS packets that
**** arrive from that ingress PE. (This would be an odd, probably
**** transitional, deployment. But the draft isn't very explicit about just
**** what combinations of MPLS and SRv6 it is supposed to support.)
**** In any event, the draft would be better off specifying the actual
label value
**** to be included rather than saying "implicit null". This occurs several
**** times in the draft.
Section 3.1
...
SRv6-VPN SID is encoded as part of the SRv6-VPN SID TLV defined in
Section 2. The function of the SRv6 SID is entirely up to the
originator of the advertisement. In practice, the function may
likely be End.DX4 or End.DT4.
**** Obviously, the behavior is not up to the originator, it MUST provide
**** the functionality necessary to provide the behavior that would have
been
**** provided by the MPLS label(s). Statements like this occur several
**** times in the draft and should all be fixed.
Section 4
...
Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable
method of building an EVPN overlay. It primarily focuses on MPLS
based EVPNs but calls out the extensibility to IP based EVPN
overlays. It defines 4 route-types which carry prefixes and MPLS
Label attributes, the Labels each have specific use for MPLS
encapsulation of EVPN traffic. The fifth route-type carrying MPLS
label information (and thus encapsulation information) for EVPN is
defined in[I-D.ietf-bess-evpn-prefix-advertisement].
The Route Types discussed below are:
**** After carefully counting up to five route types, the document then
proceeds to identify eight route types ;-)
**** And there are lots more on the way!
Section 4.1.1
...
SRv6-VPN TLV MAY be advertised along with the route advertisement and
the behavior of the SRv6-VPN SID is entirely up to the originator of
the advertisement. In practice, the behavior would likely be
Arg.FE2.
**** This seems to require that a unique IPv6 address be assigned to each
**** ES. Is that the intention? If so, then probably those addresses
**** should not be routable.
...
Section 4.3
...
An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI
consists of the following [RFC7432] where:
o BGP next-hop: IPv6 address of egress PE
**** I don't think there is any reason for this document to specify the
**** contents of the NH field of the IMET route. The above doesn't make
**** much sense anyway, as the term "egress PE" doesn't really make sense in
**** the context of the IMET route, and the next hop can change as the route
**** is propagated.
o SRv6-VPN TLV MAY encode END.DX2/END.DT2M function.
o BGP Attribute: PMSI Tunnel Attribute[RFC6514] MAY contain MPLS
implicit-null label and Tunnel Type would be similar to defined in
EVPN Type-6 i.e. Ingress replication route.
**** Is the intention to prohibit the use of either P2MP tunnels or assisted
**** replication in an SRv6 overlay? That seems to be a consequence of the
**** above. If that's the intention, please say so explicitly and do not
**** leave it as an inference. If that's not the intention, then do not say
**** what the tunnel type should be.
The format of PMSI Tunnel Attribute attribute is encoded as follows
for an SRv6 Core:
+---------------------------------------+
| Flag (1 octet) |
+---------------------------------------+
| Tunnel Type (1 octet) |
+---------------------------------------+
| MPLS label (3 octet) |
+---------------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------------+
o Flag: zero value defined per [RFC7432]
**** The EVPN specs (of which RFC 7432 is not the only one) use five or six
**** of the PMSI tunnel attribute flags. This spec should not say to set
**** the flags to zero, unless it is meant to prohibit the use of any
**** function requiring the flags.
o Tunnel Type: defined per [RFC6514]
o MPLS label: Implicit-Null
**** MPLS label should be zero; in the PMSI Tunnel attribute, it is clear
**** that zero means "no label is specified".
o Tunnel Identifier: IP address of egress PE
**** This makes no sense when P2MP tunnels are used.
**** For IR, the tunnel identifier is the identifier of the PE originating
**** the route, per RFC 7432 section 11.2.
**** Note that this will require that a unique IPv6 address be assigned to
**** each Broadcast Domain; that should be stated explicitly.
**** In a draft entitled " BGP Signaling of IPv6-Segment-Routing-based VPN
**** Networks", it would be nice if the following little details were
**** mentioned explicitly:
**** - In L3VPN, an IPv6 address must be assigned to each VRF (or to each
**** VRF interface)
**** - In EVPN, an IPv6 address must be assigned to each ES.
**** - In EVPN, an IPv6 address must be assigned to each BD.
**** It would also be nice if multicast were covered in both MVPN and EVPN.
...
6. Implementation Status
The SRv6-VPN is available for SRv6 on various Cisco hardware and
other software platforms.
**** Does it provide the full set of L3VPN/EVPN features? If not,
**** what subset of features are supported? Does it support
**** transitional scenarios without relying on non-standard
**** behaviors?
...
7. Error Handling of BGP SRv6 SID Updates
When a BGP Speaker receives a BGP Update message containing a
malformed SRv6-VPN SID TLV, it MUST ignore the received BGP
attributes and not pass it to other BGP peers. This is equivalent to
the -attribute discard- action specified in [RFC7606]. When
discarding an attribute, a BGP speaker MAY log an error for further
analysis.
**** If the attribute is discarded, and there is no label (or the backbone)
**** doesn't support MPLS, what will happen to the VPN traffic? Can it be
**** misdelivered outside the VPN? That wouldn't be very good.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
