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