Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03
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 wrote: > 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 t
Re: [bess] Comments on draft-dawra-idr-srv6-vpn-03
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 exactl
