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

[Mach Chen <[e-mail]>]

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:[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 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
> 
>