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

[Yimin Shen <[e-mail]>]

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; [e-mail]; [e-mail]; Martin Vigoureux; [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label 

Mach,

> Hi Yimin,
> 
> Thanks for your detail review and valuable comments on the draft!
> 
> Please see my reply inline...

few comments in-line below...

> > -----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:[e-mail]] On Behalf Of Yimin Shen
> > Sent: Monday, May 12, 2014 9:53 PM
> > To: [e-mail]; 
> > [e-mail]
;
> > Martin Vigoureux
> > Cc: [e-mail]
> > 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 se
e 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 
> scenari
os that may need multiple SLs. I'd like to hear more opinions from the WG. 
> 
> > 
> > 2. SL's 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.

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.