[bess] Comments on draft-dawra-idr-srv6-vpn-03

[Eric C Rosen <[e-mail]>]

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.