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

From: Eric C Rosen <[email-masked]>
Date: Tue, 2 Jan 2018 09:10:45 -0500

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.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Jan 2018 16:29:45 +0100

Hi Eric,

Being routable is not the same as having per VRF or per CE unique IPv6
address. Being routable to me means that lookup on first N bits of the
address will result in forwarding action while the last N bits of the
address can have local significance.

The use of "dual purpose" is indeed a bit confusing in the draft however it
is only MAY which one can also read as MAY NOT :) If operator wishes to
have per VRF IPv6 SID implementation complaint with the draft allows that.
However smart implementation may also provide mechanism not to require to
have full IPv6 address per VRF or per CE.

Cheers,
R.

On Tue, Jan 2, 2018 at 3:10 PM, Eric C Rosen <[email-masked]> wrote:

> 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
> ​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
> **** The phrase "only has local significance" suggests that these SIDs are
> ​Again SIDs are not routable and they have only local significance - true.
> ​They are prepended to say loopback address to form IPv6 SID.
>
> ​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. ​​
>
>
>>    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,
>>    L3VPN simultaneously, it MAY also populate the Label values in L3VPN
>>    encapsulation to use.  If the BGP speaker does not support MPLS based
>> **** 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
> 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.
>
>
>> **** "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
> 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.
>
>
>> **** I'm not really sure what you're trying to do here. There are at least
>> **** 1. For the case where the backbone doesn't have MPLS, there is no
>> harm
> ​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".
>
>
> 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
>> **** 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
>> **** 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
>>
>
> ​Label in SAFI 1 ? ​
>
>