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

[Robert Raszuk <[e-mail]>]

Ok let's start all over :)

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

**** 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 ? ​

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


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


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


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

**** 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 ? ​




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

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

Kind regards,
R.