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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
