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

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

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
> Sent: Thursday, May 15, 2014 2:01 AM
> To: Yakov Rekhter; Mach Chen
> Cc: draft-chen-mpls-source-label@tools.ietf.org; mpls@ietf.org;
> mpls-chairs@tools.ietf.org
> Subject: Re: [mpls] MPLS-RT review of draft-chen-mpls-source-label
> 
> 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; draft-chen-mpls-source-label@tools.ietf.org;
> mpls-chairs@tools.ietf.org; Martin Vigoureux; mpls@ietf.org
> 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:mpls-bounces@ietf.org] On Behalf Of Yimin Shen
> > > Sent: Monday, May 12, 2014 9:53 PM
> > > To: draft-chen-mpls-source-label@tools.ietf.org;
> > > mpls-chairs@tools.ietf.org
> ;
> > > Martin Vigoureux
> > > Cc: mpls@ietf.org
> > > 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.
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls