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

[Robert Raszuk <[e-mail]>]

Hi Eric,

A lot of your comments are an indication that you treat SID to be IPv6
address fully responsible for demux to proper VRF or CE. This was never the
intention.

Imagine egress PE having /64 loopback. Then you have remaining 64 bits to
put there a 20 bit VPN label (as we know it :) and even much more then
that. You can attach new arbitrary new functions to this single "VPN SID".

And further notice that this has no bearing on SID being routable or not.
Only the first /64 bits of the dst address need to be routable in order for
forwarding packets to happen ... So by no means there should be a case to
have per vrf IPv6 address or per CE IPv6 address and make it fully /128
routable.

Happy New Year !
Robert.


On Thu, Dec 28, 2017 at 5:44 PM, Eric C Rosen <[e-mail]> wrote:

> 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.
>
>
>
>
>
>
>