Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label

[Mach Chen <[e-mail]>]

Hi Eric,

Thanks for your comments!

We are preparing an update to address the comments from the MPLS-RT reviewers and you.

Regarding how to prevent SLC and LS leaking outside to the unintended nodes and/or domains, we have the following thoughts:

1) Naturally, IGP based SLC negotiation and SL distribution will not leak the SLC and SL outside an IGP domain, should be no more concerns here; 

2) LDP based LSC negotiation, normally LDP is running within an AS, although as you said, technically, it may running across domains and leak the SLC outside domain. As you suggested, we will add some text to the LDP based SLC part to discuss this.

3) For inter-AS scenario, presumably, BGP will be used for SLC negotiation and SL distribution, we are considering to use non-transitive attribute + policy control (e.g., as the way AIGP uses ) to prevent SLC and SL leaking outside to the unintended domain(s). 


Thanks,
Mach

> -----Original Message-----
> From: Eric Rosen [mailto:[e-mail]]
> Sent: Friday, May 30, 2014 12:23 AM
> To: Mach Chen
> Cc: [e-mail]
> Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> Mach> My point is that the distribution mechanisms should be defined in
> Mach> separate documents
> 
> I don't think anyone is really concerned right now with the number of documents
> used to define the "source label" mechanisms.  The issue at hand is whether
> the "source label" proposal is architecturally sound.  Any proposal that uses
> scoped identifiers has to provide mechanisms that prevent the identifiers from
> leaking out of their intended scope, either via the control plane or the data plane.
> Right now there is no draft or set of drafts that we can look at to see how the
> scoping is enforced.  The source-label draft is just one piece of the architecture,
> and I don't think it can be accepted until we can determine whether the
> architecture can be completed.
> 
> If one looks at the two proposed distribution mechanisms for which there are
> internet drafts (draft-chen-isis-source-label and draft-chen-ospf-source-label),
> we see that these two proposals only distribute the labels within a single IGP
> domain.  Since the scope of a source label is not restricted to a single IGP
> domain, we can conclude that these two proposals are not, by themselves,
> adequate.
> 
> The drafts also don't seem to have any procedures for dealing with the case
> where two nodes advertise the same source label.
> 
> Mach> There may need other solutions (e.g., BGP extensions) for the
> Mach> distribution in that case. This should be discussed when we start
> Mach> to define the distribution mechanisms.
> 
> I think we need to see the proposal for the BGP extensions before the
> source-label draft can be considered.  That is, I don't think the WG should
> accept the SL draft until some progress has been made in defining the
> distribution mechanisms.
> 
> Xiaohu> the SL advertisement could be done by a centralized mapping
> Xiaohu> server
> 
> Sure, one could imagine a provisioning system that knows exactly which egress
> LSRs need to know the source labels for which ingress LSRs, and would provision
> the LSR accordingly.  However, unless the draft is going to say that source labels
> MUST NOT be used unless there is such provisioning system, this doesn't really
> help.  Also, this doesn't address the issue of source labels in the data plane
> leaking outside the domain.
> 
> Eric> The ingress would have know, not only that the egress is capable
> Eric> of processing the source label, but that the egress will interpret
> Eric> the source label in the proper scope.  The draft doesn't address
> Eric> the issue of how to ensure that ingress and egress agree on the
> Eric> intended scope of the label.
> 
> Mach> For single domain case, the SLC will be only exchanged among the
> Mach> LSRs within the domain, when the ingress knows the egress can
> Mach> support SLC, it implicit indicates that the egress will interpret
> Mach> the SL in the same scope of itself.
> 
> Mach> Actually, even for multiple domains, it is still the case, since
> Mach> SL will be used across domains, the SL space should be shared by
> Mach> the domains.
> 
> The question is, how does the ingress LSR know that the egress LSR is in the same
> domain, or in a domain that shares the same SL space?  I think you're assuming
> that the capability advertisement from the egress will not cross the domain
> boundary.  Given that assumption, if an ingress LSR sees an SL capability
> advertisement from an egress LSR, the ingress could assume that the egress is in
> the same domain.  However, the SLC signaling mechanisms described in the
> draft do not prevent the SL Capability signal from crossing a domain boundary.
> On the contrary, the mechanisms described in the draft will cause the SLC to be
> signaled from egress to ingress with no regard for domain boundaries.
> 
> Consider, for instance, the LDP extensions.  From section 6.1.1:
> 
>    "If all the advertised Mappings for F include the SLC TLV, then X
>     MUST advertise its Mapping for F with the SLC TLV."
> 
> This will cause the SLC to go from egress to ingress, with no regard for
> domain boundaries.   Perhaps the above should say "MAY advertise", and
> should have some discussion of policy.
> 
> Section 6.1.2 proposes a BGP path attribute to signal the SL Capability:
> 
>     "When Border Gateway Protocol (BGP) [RFC4271] is used for distributing
>     Network Layer Reachability Information (NLRI) as described in, for
>     example, [RFC3107], [RFC4364], the BGP UPDATE message may include the
>     SLC attribute as part of the Path Attributes.  This is an optional,
>     transitive BGP attribute of value TBD3.  The inclusion of this attribute
>     with an NLRI indicates that the advertising BGP router can process
>     Source Labels as an egress LSR for all routes in that NLRI.
> 
>     ...
> 
>     Suppose a BGP speaker T receives an UPDATE U with the SLC attribute.  T
>     has two choices.  T can simply re-advertise U with the SLC attribute if
>     either of the following is true:
> 
>     B1: T does not change the NEXT_HOP attribute OR
> 
>     B2: T simply swaps labels without popping the entire label stack and
>     processing the payload below."
> 
> Note that if the SLC attribute is an optional transitive attribute, then if T does not
> understand this attribute, T will pass it along even if conditions B1 and B2 do not
> hold.  (Perhaps the attribute needs to be
> non-transitive.)
> 
> B2 is a little hard to understand.  Let P be the prefix in the NLRI of update U.  I
> think the intention is that the SLC attribute be left on by T if each of T's installed
> routes to P has the SLC attribute.  (B2 as written seems to be about the data
> plane, but the context of this section is the control plane.)
> 
> Even if B1 does hold, it may still be incorrect for router T to pass along the SLC.
> For example, suppose the data path from R1 to R2 is as follows:
> 
>       R1---ASBR1---ASBR2---R2
> 
> but suppose that R1 and R2 exchange VPN routes through a different path:
> 
>       R1---T1---T2---R2
> 
> where T1 and T2 aren't in the data path at all.  This could occur in an "option C"
> type of interconnect. (RFC4364 section 10 option c.)  Suppose that R1 and R2 are
> in different domains.  T1 and T2 would leave the next hop unchanged.  When
> R1 has data to send to P, it would find R2 to be the next hop, and then would do
> recursive route resolution to find that ASBR1 is its next hop to R2.  In this
> scenario, R1's route to P would have the SLC attribute, but R2 would not properly
> interpret R1's source label.
> 
> To make this work at all, you'd have to mandate that the SLC attribute be
> attached to a route that travels along the data path (i.e., goes through the ASBRs),
> and there would have to be policy at the ASBRs that strips off the SLC if the
> ASBRs are at a domain boundary.  The proper behavior when recursive route
> resolution is done would also have to be specified.
> 
> I'm having some trouble understanding the following paragraph from the draft:
> 
>    "However, if T changes the NEXT_HOP attribute for U and in the data plane
>    pops the entire label stack to process the payload, T MAY include an SLC
>    attribute for UPDATE U' if both of the following are true:"
> 
>    C1: T sets the NEXT_HOP attribute of U' to itself AND
> 
>    C2: T can process source labels.  Otherwise, T MUST remove the SLC
>    attribute."
> 
> The term UPDATE U' doesn't appear to have been defined anywhere, though I
> assume this is meant to be the update you get when you take Update U and
> change the next hop.  Does the phrase "and in the data plane pops the entire
> label stack to process the payload" mean that T is the egress LSR for the prefix in
> U's NLRI?  If so, I don't think this entire paragraph is needed, as T will be
> originating an Update for that prefix, and will include the SLC attribute if
> necessary.
> 
> Eric> With no structure and no "domain identifier" in the source label,
> Eric> it is very easy end up with non-unique labels within a domain.
> 
> Mach> There are also many non-structure cases, for example, Router ID,
> Mach> Segment ID, VE ID of BGP VPLS
> Mach> (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fine.
> 
> I have to admit that I have always regarded the VPLS VE IDs as a very bad idea.
> However, they do have a well-defined scope, namely a single VPLS.
> RT-based mechanisms are used to constrain their distribution so that they don't
> leak unintentionally into other VPLSes.  And the VE IDs do not appear in the
> data packets.  These characteristics make it possible to get away with an
> unstructured identifier space.  SLs don't seem to have a well-defined scope, or a
> well-defined distribution mechanism, and they do get carried by data packets.
> Leakage out of the intended domain is thus much more of a problem.  So I don't
> think SLs can be compared to VPLS VE IDs.
> 
> With regard to router ids, if you've ever followed any of the vituperative
> discussions that arise when router ids are discussed (e.g., when discussing
> whether a 32-bit id is appropriate for an IPv6-based protocol), you'll see that
> there are quite a few issues in the management of that numbering space.
> 
> Mach> In addition, even for your RT example, for L3VPN inter-AS
> Mach> scenario, the RT has to be considered as single space, the domain
> Mach> identifier does not help here.
> 
> RTs are structured so that a SP can allocate RT values that are globally unique, not
> just unique within a domain.  So a "domain identifier" is not needed.  I believe
> it is true that some SPs use  RTs that are not globally unique, but that is a choice
> they have made for themselves, not a choice that is forced upon them by the
> architecture.
> 
> Eric> One might also ask why there is a need to use a 20-bit label to
> Eric> identify a node, instead of using some other format.
> 
> Mach> We are talking about identifying the source of an LSP, and the
> Mach> label stack is the MPLS header and there are only labels, then
> Mach> seems that a label to identify the ingress LSR is a naturally choice.
> 
> A couple of other possibilities come readily to mind:
> 
> - Treat the SLI as the bottom of the stack, and follow it with a 32-bit
>   address (or even a 128-bit address) of the ingress.  (Or maybe use
>   something based on the "generic associated channel".)
> 
> - Use two label stack entries and stuff a 32-bit "router id" in them,
>   using more per-packet overhead but eliminating the need to manage a 20-bit
>   domain-wide numbering space.
> 
> But perhaps the use case is easier to implement if the SL fits into the same
> 20 bits usually used for labels.  If so, that would be worth mentioning.
> 
> With regard to the name,
> 
> Xiaohu> What about IIL (Ingress Identification Label)?
> 
> I do like that better.
> 
> However, getting all the details right is going to be a lot of work, especially for
> something that has only one use case, and a controversial one at that.
> 
> 
> 
> 
> 
> 
> 
> 
>