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

[Mach Chen <[e-mail]>]

Hi Yimin, Eric(s) and Lizhong,

Thanks for your comments!

We just uploaded two updates (Version 4 and 5) to address your comments. 

Version 4 solved most of your comments, changes include:
1) Add text to discuss how to prevent SL from leaking to unintended domains; (according to Eric Rosen's comments)
2) Remove RSPV-TP related part (according to Lizhong and Eric Osborne's comments)
3) Add text to allow one or more SLs that can be allocated to an LSR(according to Yimin's comments);
4) Refine the Security Consideration;

Here is diff from Version 03 to 04 (http://www.ietf.org/rfcdiff?url2=draft-chen-mpls-source-label-04), please refer.

Version 5 solved one comment from Eric Rosen, add text to discuss how to prevent LDP based SLC from leaking SLC outside SLAD.
Here is diff from 04 to 05 (http://www.ietf.org/rfcdiff?url2=draft-chen-mpls-source-label-05 )


The authors believe that the latest version has solved the received comments so far and is ready to be considered as an WG document.

Thanks,
Mach

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Mach Chen
> Sent: Tuesday, June 03, 2014 11:17 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> 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
> > Mach> in 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
> > Mach> start 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
> > Eric> interpret the source label in the proper scope.  The draft
> > Eric> doesn't address the issue of how to ensure that ingress and
> > Eric> egress agree on the 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
> > Mach> interpret 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
> > Eric> label, 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
> > Mach> domain 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls