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

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

On 12/28/2017 1:55 PM, Robert Raszuk wrote:
> Ok let's start all over :)

 From the draft:

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.

I took this to mean that  a single IPv6 address could cause the backbone 
to forward the packet to the egress-PE and cause the egress-PE to look 
up the payload's IP address in a VRF which is identified by that same 
IPv6 address.  Did I misunderstand that?

>     **** 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).
>
>
> ​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 
> SID which when appended to IPv6 prefix forms a complete SRv6 SID. 
> Semantics does matter here. ​

Given the above quote from the draft, I'm not sure what is wrong with 
what I said.

>
>     **** If those addresses are routable, doesn't this create a
>     security issue
>     **** as discussed in RFC 4023 Section 8.2?
>
>
> ​PE's loopback address say /64 being routable causes any security risk ? ​

Please see the reference.

>
>     **** 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.
>
>
> ​Again SIDs are not routable and they have only local significance - 
> true. ​They are prepended to say loopback address to form IPv6 SID.
>
>     **** So there are a number of options:
>     **** - not routable
>     **** - globally routable
>     **** - routable only within egress AS
>
>
> ​This is referring to routability of SID ... not right. SID does not 
> need to be routable. What prefix they are part of may be routable. ​​

Just replace my use of the term "SID" with the longer term "the IPv6 
address of which the SID is a part".

>
>        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".
>
>
> ​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​

Still don't understand what is being said.

>
>
>        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.
>
>
>
> ​4364 does not restrict what value of VPN label is used - does it ? I 
> think this draft now right here defines ​how to read implicit-null 
> being placed there :) It's not my idea though - so I will let real 
> inventors to comment on it more.
>
>     **** 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.
>
>
> ​As mentioned I think it just is being defined here and now. ​

I didn't see any mention of the numeric value to put in the label field 
of the NLRI.

> or to define a new special or reserved label ​for that embedded 
> signalling.

Some discussion of why this won't cause any backwards compatibility 
problems would be appropriate.


>
>
>     **** 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".
>
>
> ​Really ? ​What does the backbone having or not having MPLS has to do 
> with this ? Underlay forwarding does not matter and this is what I 
> read as "backbone".

What I meant is that if it is known a priori that SRv6 is being used 
instead of MPLS, the label value obviously doesn't matter, because it 
will never be used.

>
>     **** 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.
>
>
> ​OK.​
>
>     **** 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.
>
>
> ​Perhaps not ... and this is exactly ​the case trying to be addressed.

Why isn't the presence of the attribute sufficient in this case?

>
>     **** 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
>
>
> ​Label in SAFI 1 ? ​

Sorry, I meant SAFI-4.  Actually, only SAFI-128 really matters in this 
context, I think.