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

From: Mach Chen <[email-masked]>
Date: Tue, 13 May 2014 10:39:40 +0000

Hi Yimin,

Thanks for your detail review and valuable comments on the draft!

Please see my reply inline...

> -----Original Message-----
> From: Mach Chen
> Sent: Tuesday, May 13, 2014 6:18 PM
> To: Mach Chen
> Subject: FW: MPLS-RT review of draft-chen-mpls-source-label
> 
> 
> 
> From: mpls [mailto:[email-masked]] On Behalf Of Yimin Shen
> Sent: Monday, May 12, 2014 9:53 PM
> To: [email-masked]; [email-masked];
> Martin Vigoureux
> Cc: [email-masked]
> Subject: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> WG chairs, authors,
> 
> I have finished my review for this draft. Overall, I think the document is easy to
> understand, and useful from the perspective that the mechanism may support
> egress routers to identify source of traffic for measurement purposes.

Thanks.

> 
> From technical perspetive, I do have the following comments, and hope the
> authors can address them before WG adoption.
> 
> 1. Granularity of SL
> 
> The document currently views "sources" as ingress nodes, hence assumes the
> granularity of SL as per-node. From a generic point of view, I'd like to see some
> discussion on per-flow SL (multiple flows ingress on a given node), or why this
> mode may not be useful.

I personally open to this point and had thought about this. There are scenarios that may need multiple SLs. I'd like to hear more opinions from the WG. 

> 
> 2. SL  allocation and disbritubtion.
> 
> I think this is a big missing piece. The draft currently pushes this out of scope.
> However, the procedures of how a router may allocate an SL for itself without
> colliding with other routers, and how a source-to-SL mapping may be disctributed
> to egress routers are both relavant and important to the proposal. Therefore,
> they should be specified in this draft for completeness.

Regarding to the allocation, this is same as the IP address allocation, "segment index" allocation. In practice, this is the task of the operators to guarantee the uniqueness. It's more about a deployment issue. The operator could use either static or dynamic mechanisms to achieve this.

As for the distribution, seems that IGP extension is a reasonable choice, normally, the IGP extensions will be defined in draft-xxx-ospf or draft-xxx-isis, means it's better to define the distribution mechanisms in separate document. And actually, there are two initial drafts submitted (draft-chen-ospf-source-label-distribution-00 and draft-chen-isis-source-label-distribution-00).
 
> 
> 3. Transit router use cases.
> 
> The draft has improved its clarity from previous rev by removing transit router
> use cases. However, transit router is still mentioned in a few places. So a cleanup
> may still be need to achieve consistency.

OK.

Thanks,
Mach
> Regards,
> /Yimin Shen

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 May 2014 10:03:39 -0700

Mach,

> Please see my reply inline...

few comments in-line below...

> I personally open to this point and had thought about this. There are scenari
os that may need multiple SLs. I'd like to hear more opinions from the WG. 
> 
> > 
> > 2. SL's allocation and disbritubtion.
> > 
> Regarding to the allocation, this is same as the IP address allocation, 
> "segment index" allocation. 

Saying that it is the same as "IP address allocation" is a bit
misleading, as for IP allocation we have a hierarchy of allocation
authorities that intended to provide *globally* unique allocation
of IP addresses.

> In practice, this is the task of the operators to guarantee the uniqueness. 

Saying that "this is the task of the operators to guarantee
the uniqueness", assumes that providing such guarantee 
is fully within the control of the operator, which may                          
not be the case when not all the equipment is under control    
of a single operator.

> It's more about a deployment issue. The operator could use 
> either static or dynamic mechanisms to achieve this.
> 
> As for the distribution, seems that IGP extension is a reasonable
> choice, normally, the IGP extensions will be defined in draft-xxx-ospf
> or draft-xxx-isis, means it's better to define the distribution
> mechanisms in separate document. And actually, there are two initial
> drafts submitted (draft-chen-ospf-source-lab el-distribution-00 and
> draft-chen-isis-source-label-distribution-00).

Given all this and my comments above, I wonder whether the document
should explicitly spell out that the scope of source-label is a
single IGP domain, and also spell out what should be done to prevent
source labels to leak across IGP domain boundaries.

Yakov.

---

From: Yimin Shen <[email-masked]>
Date: Wed, 14 May 2014 18:01:19 +0000

Hi Mach,

Taking Yakov's point as well, I think granularity and scope are two things that draft would need to make additional consideration when defining the semantics of SL. 

Once that is decided, it will in turn shape the requirements for SL allocation and distribution. Allocation and distribution would need to be done in a scalable and manageable fashion. Configuration and static provisioning cannot scale well. Therefore some protocols or protocol extensions are needed here. This is where inter-operability would demand standardization. Without a detailed specification for allocation and distribution, it is difficult to evaluate the feasibility and usability of the proposal. So I think this should be in-scope for this draft.

Thanks for pointing out draft-chen-ospf-source-label-distribution-00 and draft-chen-isis-source-label-distribution-00. I'd like to suggest to incorporate them into the current draft. OTOH, both drafts currently assume per-node SL and intra-area scope, which remains to be seen as sufficient or not, per the granularity and scope above.

Thanks,

/Yimin

-----Original Message-----
From: Yakov Rekhter 
Sent: Wednesday, May 14, 2014 1:04 PM
To: Mach Chen
Cc: Yimin Shen; [email-masked]; [email-masked]; Martin Vigoureux; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label 

Mach,

> > To: [email-masked]; 
> > [email-masked]
;
> > I have finished my review for this draft. Overall, I think the 
> > document is
easy to
> > understand, and useful from the perspective that the mechanism may 
> > support egress routers to identify source of traffic for measurement purposes.
> 
> Thanks.
> 
> > 
> > From technical perspetive, I do have the following comments, and 
> > hope the authors can address them before WG adoption.
> > 
> > 1. Granularity of SL
> > 
> > The document currently views "sources" as ingress nodes, hence 
> > assumes the granularity of SL as per-node. From a generic point of 
> > view, I'd like to se
e some
> > discussion on per-flow SL (multiple flows ingress on a given node), 
> > or why
this
> > However, the procedures of how a router may allocate an SL for 
> > itself without colliding with other routers, and how a source-to-SL 
> > mapping may be disctributed to egress routers are both relavant and 
> > important to the proposal.
> > Therefore,
> Regarding to the allocation, this is same as the IP address 
> allocation, "segment index" allocation.

Saying that it is the same as "IP address allocation" is a bit misleading, as for IP allocation we have a hierarchy of allocation authorities that intended to provide *globally* unique allocation of IP addresses.

> In practice, this is the task of the operators to guarantee the uniqueness. 

Saying that "this is the task of the operators to guarantee the uniqueness", assumes that providing such guarantee 
is fully within the control of the operator, which may                          
not be the case when not all the equipment is under control    
of a single operator.

> It's more about a deployment issue. The operator could use either 
> static or dynamic mechanisms to achieve this.
> 

Given all this and my comments above, I wonder whether the document should explicitly spell out that the scope of source-label is a single IGP domain, and also spell out what should be done to prevent source labels to leak across IGP domain boundaries.

Yakov.

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 May 2014 08:06:19 +0000

Hi Yakov,

Thanks for your comments!

See my reply inline...

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Thursday, May 15, 2014 1:04 AM
> To: Mach Chen
> Cc: Yimin Shen; [email-masked];
> [email-masked]; Martin Vigoureux; [email-masked]

Sniped.

> Saying that it is the same as "IP address allocation" is a bit misleading, as for IP
> allocation we have a hierarchy of allocation authorities that intended to provide
> *globally* unique allocation of IP addresses.

Here the "Same as IP address allocation" is just an analog, there are similar cases that require to guarantee the uniqueness of IDs, for example, Router ID. 

IMHO, the allocation is more like a management policy issue other than a technical issue, it may not be suitable to discuss it in this document. 
 
In addition, the Source Label is not intended to be *globally* unique. The draft says:

  "In its function as a
   Source Label, it MUST be unique within a domain.  In cases where a
   Source Label is used across domains it MUST be unique within the
   scope it is used."

> not be the case when not all the equipment is under control

Yes, for a single operator, to guarantee the uniqueness is relevant easy. For multiple operators case, if they want to use the source label across domains, they have to make an agreement how to allocate the source label and make sure the uniqueness.  

> Given all this and my comments above, I wonder whether the document should
> explicitly spell out that the scope of source-label is a single IGP domain, and also
> spell out what should be done to prevent source labels to leak across IGP domain
> boundaries.

Presumably, most of the cases, SL is used within a single administrative domain, but there may be requirement to use SL across domains. I'd like to hear more opinions from WG about the scope of the SL. 

Thanks,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 May 2014 08:38:07 +0000

Hi Yimin,

I'd like to encourage more people to express their opinions about the granularity and scope of the SL.

Regarding allocation and distribution, IMHO, they may not belong to this base document. There are separate drafts for defining distribution of SL, and for the allocation, as replied to Yakov, it's a management policy issue other than a technical issue. 

Thanks,
Mach

> Sent: Thursday, May 15, 2014 2:01 AM
> To: Yakov Rekhter; Mach Chen
> Cc: [email-masked]; [email-masked];
> Taking Yakov's point as well, I think granularity and scope are two things that draft
> would need to make additional consideration when defining the semantics of SL.
> 
> Once that is decided, it will in turn shape the requirements for SL allocation and
> distribution. Allocation and distribution would need to be done in a scalable and
> manageable fashion. Configuration and static provisioning cannot scale well.
> Therefore some protocols or protocol extensions are needed here. This is where
> inter-operability would demand standardization. Without a detailed specification
> for allocation and distribution, it is difficult to evaluate the feasibility and usability
> of the proposal. So I think this should be in-scope for this draft.
> 
> Thanks for pointing out draft-chen-ospf-source-label-distribution-00 and
> draft-chen-isis-source-label-distribution-00. I'd like to suggest to incorporate
> them into the current draft. OTOH, both drafts currently assume per-node SL and
> intra-area scope, which remains to be seen as sufficient or not, per the
> granularity and scope above.
> 
> Thanks,
> 
> /Yimin
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Eric Rosen <[email-masked]>
Date: Thu, 15 May 2014 11:50:02 -0400

Mach> As for the distribution, seems that IGP extension is a reasonable
Mach> choice,

The distribution mechanism needs to ensure that each egress LSR will learn
the source label of each ingress LSR.  There are MPLS deployments in which
an ingress LSR may be separated from an egress LSR by multiple Autonomous
Systems, each of which consists of at least one IGP domain.  (Of course, an
AS is not limited to consisting of only one IGP domain.)  In a deployment
like this, how will the egress LSRs learn the source labels of all the
ingress LSRs?  Something more than an IGP extension seems to be required.

Or is the intention that source labels be unique only within an IGP domain?
In that case, I agree with Yakov that the draft should state that clearly.
But that would mean that the source label can only be used when the ingress
and egress LSRs are in the same IGP domain.  But that would raise a number
of other issues:

- With a restriction to one IGP domain, can the intended use case be
  supported?

- The ingress would have know, not only that the egress is capable of
  processing the source label, but that the egress will interpret the source
  label in the proper scope.  The draft doesn't address the issue of how to
  ensure that ingress and egress agree on the intended scope of the label.

- Since a packet does not carry an identifier of its ingress IGP domain, the
  egress wouldn't be able to interpret the label without first determining
  the ingress IGP domain.  The draft says nothing about how this is done.

At the very least, this draft needs to specify the characteristics a
distribution mechanism must have in order to ensure that a source label
never gets distributed outside the "domain" in which it is unique.  There
also need to be assurance that a data packet carrying a source label will
never carry the source label outside the proper domain.

Mach> Regarding to the allocation, this is same as the IP address allocation

If an allocation scheme is to have more than local scope, it usually has
some sort of hierarchy that can be used to prevent collisions.  IP
addresses, Route Distinguishers, Route Targets, all have some kind of
structure.

> for a single operator, to guarantee the uniqueness is relevant easy.

With no structure and no "domain identifier" in the source label, it is very
easy end up with non-unique labels within a domain.

One might also ask why there is a need to use a 20-bit label to identify a
node, instead of using some other format.  The draft doesn't actually seem
to address this issue, it just says "right now you can't identify the
ingress, we need to identify the ingress, therefore we need to have a 20-bit
label that identifies it".  It would be good if the draft said more about
why a single 20-bit value is needed to identify the ingress router.  

By the way, "source label" is an unfortunate choice of terminology for a
field that identifies an ingress LSR, as folks outside the Routing Area will
have trouble thinking of a router as the "source" of a packet.

---

From: Mach Chen <[email-masked]>
Date: Fri, 16 May 2014 06:46:52 +0000

Hi Eric,

See my reply inline...

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, May 15, 2014 11:50 PM
> To: Mach Chen
> The distribution mechanism needs to ensure that each egress LSR will learn the
> source label of each ingress LSR.  There are MPLS deployments in which an
> ingress LSR may be separated from an egress LSR by multiple Autonomous
> Systems, each of which consists of at least one IGP domain.  (Of course, an AS is
> not limited to consisting of only one IGP domain.)  In a deployment like this,

The reply to Yimin is not about whether IGP is sufficient for all cases, it's about whether the distribution mechanisms should be define in this document. My point is that the distribution mechanisms should be defined in separate documents.

> how will the egress LSRs learn the source labels of all the ingress LSRs?
> Something more than an IGP extension seems to be required.

I agree that IGP may not satisfy all the scenarios, especially the inter-AS case. There may need other solutions (e.g., BGP extensions) for the distribution in that case. This should be discussed when we start to define the distribution mechanisms.

> Or is the intention that source labels be unique only within an IGP domain?

The draft says:
"In its function as a

The intention is not just a single IGP domain, it may be used across domains when needed. 

BTW, we'd like to solicit the feedbacks about the scope of SL. 

> In that case, I agree with Yakov that the draft should state that clearly.

The draft currently explicitly says as above, if you have better text, that will be appreciated! 

> But that would mean that the source label can only be used when the ingress and
> egress LSRs are in the same IGP domain.  But that would raise a number of
> other issues:
> 

Even limited to a single administrative domain, the use case is still valid. And IMHO, for most of the cases, one single administrative domain is the major scenario. 

>   ensure that ingress and egress agree on the intended scope of the label.

For single domain case, the SLC will be only exchanged among the LSRs within the domain, when the ingress knows the egress can support SLC, it implicit indicates that the egress will interpret the SL in the same scope of itself.

>   the ingress IGP domain.  The draft says nothing about how this is done.

For single domain case, there is only one space, the egress could just interpret the label in the space. 

Actually, even for multiple domains, it is still the case, since SL will be used across domains, the SL space should be shared by the domains. There is no different from the Segment ID, VE ID (BGP VPLS). 

> 
> At the very least, this draft needs to specify the characteristics a distribution
> mechanism must have in order to ensure that a source label never gets
> distributed outside the "domain" in which it is unique.  There also need to be
> assurance that a data packet carrying a source label will never carry the source
> label outside the proper domain.

Good point, will add some text to say this.

> 
> Mach> Regarding to the allocation, this is same as the IP address
> Mach> allocation
> 
> If an allocation scheme is to have more than local scope, it usually has some sort
> of hierarchy that can be used to prevent collisions.  IP addresses, Route
> Distinguishers, Route Targets, all have some kind of structure.
> 
> With no structure and no "domain identifier" in the source label, it is very easy
> end up with non-unique labels within a domain.

There are also many non-structure cases, for example, Router ID, Segment ID, VE ID of BGP VPLS (http://tools.ietf.org/html/rfc4761#section-3.4.4 ), they work fine. 

In addition, even for your RT example, for L3VPN inter-AS scenario, the RT has to be considered as single space, the domain identifier does not help here. 

> 
> One might also ask why there is a need to use a 20-bit label to identify a node,
> instead of using some other format.  The draft doesn't actually seem to address
> this issue, it just says "right now you can't identify the ingress, we need to
> identify the ingress, therefore we need to have a 20-bit label that identifies it".
> It would be good if the draft said more about why a single 20-bit value is needed
> to identify the ingress router.

We are talking about identifying the source of an LSP, and the label stack is the MPLS header and there are only labels, then seems that a label to identify the ingress LSR is a naturally choice.

> 
> By the way, "source label" is an unfortunate choice of terminology for a field that
> identifies an ingress LSR, as folks outside the Routing Area will

Any better name are welcome!

Thanks,
Mach

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 16 May 2014 09:49:52 +0000

Hi Eric,

> -----邮件原件-----
> 发件人: Eric Rosen [mailto:[email-masked]]
> 发送时间: 2014年5月15日 23:50
> 收件人: Mach Chen
> 抄送: Yimin Shen; [email-masked];
> 主题: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> 
> Systems, each of which consists of at least one IGP domain.  (Of course, an AS
> is not limited to consisting of only one IGP domain.)  In a deployment like this,

It doesn't require that the source label of a given ingress LSR must be advertised by that ingress LSR, especially in the inter-AS scenario as you mentioned. In fact, the SL advertisement could be done by a centralized mapping server in each IGP domain as well (see http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). As such, the egress LSR in domain X could learn the source label of the ingress LSR in domain Y through the SL advertisement originated by a mapping server in domain X, as long as domain X and Y share a single source label space and allocate the same SL for a given ingress LSR. In addition, as Mach has mentioned in a previous email, we could further consider using BGP extension to exchange the SL mapping information between domains. In this way, the mapping server within each domain could directly redistribute the SL mappings learnt from neighboring domains into IGP.

Anyway, I agree with Mach's point that the SL distribution mechanisms should be defined in separate documents.

> and egress LSRs are in the same IGP domain.  But that would raise a number of
> other issues:
> 

Since the source label is not intended for packet forwarding, the source label space can be deemed as another particular context-specific label space. Once an egress LSR indicates it has the SLC, it implicitly means that it could correctly interpret the source label in that particular label space.

> end up with non-unique labels within a domain.

If you still have a concern about the uniqueness of flat ids within a domain, you could choose to allocate such ids through a centralized mapping server (see http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00).

> By the way, "source label" is an unfortunate choice of terminology for a field
> that identifies an ingress LSR, as folks outside the Routing Area will

What about IIL (Ingress Identification Label)?

Best regards,
Xiaohu

---

From: Eric Rosen <[email-masked]>
Date: Thu, 29 May 2014 12:22:42 -0400

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 to
Mach> 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 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 of
Eric> processing the source label, but that the egress will interpret the
Eric> source label in the proper scope.  The draft doesn't address the issue
Eric> of how to ensure that ingress and egress agree on the intended scope
Eric> of the label.

Mach> For single domain case, the SLC will be only exchanged among the LSRs
Mach> within the domain, when the ingress knows the egress can support SLC,
Mach> it implicit indicates that the egress will interpret the SL in the
Mach> same scope of itself.

Mach> Actually, even for multiple domains, it is still the case, since SL
Mach> will be used across domains, the SL space should be shared by the
Mach> 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, it
Eric> 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 scenario,
Mach> the RT has to be considered as single space, the domain identifier
Mach> 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 label
Mach> stack is the MPLS header and there are only labels, then seems that a
Mach> 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.