Re: [mpls] Comments on draft-li-mpls-global-label-usecases

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Robin,

Thanks for your response.
Please see further comments in-line

> -----Original Message-----
> From: Lizhenbin [mailto:[e-mail]]
> Sent: Tuesday, July 29, 2014 4:30 AM
> To: Nobo Akiya (nobo); [e-mail]
> Cc: [e-mail]
> Subject: 答复: Comments on draft-li-mpls-global-label-usecases
> 
> Hi Nobo,
> Thanks very much for your detailed my comments. Pleaser refer to my
> inline reply.
> 
> Best Regards,
> Robin
> 
> 
> ________________________________________
> 发件人: Nobo Akiya (nobo) [[e-mail]]
> 发送时间: 2014年7月28日 3:05
> 收件人: [e-mail]
> 抄送: [e-mail]
> 主题: Comments on draft-li-mpls-global-label-usecases
> 
> Hi Authors,
> 
> The presentation for this document at IETF90 added some use cases.
> 
> http://www.ietf.org/proceedings/90/slides/slides-90-mpls-13.pptx, Slide 2.
> 
> Below are my comments on just the new use cases added.
> 
> 1. MPLS OAM for LDP LSP
> 
> The problem isn't specific to LDP, but SR as well as TE/TP with PHP.
> [Robin] I agree with you that the problem also exists with MPLS TE with PHP.
> But for MPLS TP, it excludes PHP, so it is not an issue for MPLS TP:) However,
> what you need is a label that ingress and egress agree on, which granularity
> is likely at least one label per LSP.
> [Robin] The granularity is not this way you mentioned. It is just to allocate a
> unique global label for each PE node in the network . When send packet, it
> will use the label stack (label for the LSP + label for the PE).  So the egress
> node can count the packet for the flow from a specific PE for a specific prefix.
> There are not many PE nodes in the network. So it will not burn up the
> labels.

[NOBO] I would say your comment above has 2 wrong assumptions.
(a) Taking LDP with PHP for example, all egress will get will be [label for the PE]. Egress will know the sender PE but will have no idea which LSP it came on. This is just one example, I can think of other scenarios where just having [label for the PE] will be insufficient.
(b) Your comment about number of PEs will not be many PEs is an assumption you do not want to make lightly. The number is relative and varies from one deployment scenario to another. 

> Attempting to solve this through suggested "global label" will unnecessary
> burn up labels in the "global label space" (i.e. severe scalability problem). In
> other words, LSP egress allocated context label appears to be simpler and
> technical superior, IMHO.
> [Robin] I think global label and context label is not the parallel concept. I
> have explained it in the draft draft-li-mpls-global-label-framework. MPLS
> global label can be allocated from the per-platform label space or the
> context-specific label space. No matter which label space, if the meaning of
> the label can be understand by multiple nodes, it should be called as the
> global label. In this use case, the global label for the source PE node can be
> allocated from the context-based label space.  Since its meaning to identify
> a specific PE should be understood by all involved nodes in the network, it
> is the global label.

[NOBO] That's not what I'm trying to convey. What I'm saying is that context labels will solve this use case much simpler and easier.

> 
> 
> 2. Service Chaining
> 
> Why not let SFC folks to do their work, which SFC will then work on the
> MPLS data plane without any changes to the MPLS data plane nor
> architecture, certainly doesn't require any "global label" as this use case is
> describing. Unless the SFC WG require the "global label" (which it doesn't)
> or the MPLS WG is re-chartered to pick up creation of a tangent SFC solution
> specifically for MPLS, I don't think this use case is valid.
> [Robin] SFC WG truly works on some new header for service functions. We
> need to work out the when MPLS dataplane applied, what the possible
> problem and the solution. I think MPLS has been widely deployed in the
> existing network and SFC is the possible useful use case in MPLS network
> which should be taken into account in the MPLS world. MPLS global label is
> one of the possible solutions. This does not preclude other solutions.

[NOBO] SFC is data plane agnostic. When SFC runs on MPLS data plane, there is no need to use global labels to describe service functions.

> 
> 3. Segment Routing
> 
> The Segment Routing technology is much further down the road (i.e. we
> even saw some cool stuff in the Bits-n-Bites at IETF90) and they already
> have a solution for SRGB. Even if Segment Routing was using global labels
> (which isn't the case), I'm not sure if there's any value in listing this as a use
> case for "global label".
> [Robin] SRGB is the solution. But what is the global unique segement
> identifier in the segment routing? Do you think the network administrator
> will configure distinct SRGBs for all nodes, node 1 use SRGB [100, 200], node
> 2 use SRGB [200, 300], node 3 use SRGB [300, 400], etc.? I think this way may
> be crazy. The simplest way is just to configure the SAME SRGB as much as
> possible. Moreover, if all SRGBs in the nodes begin from 0, what is the
> difference between the global unique segment identifier and the global
> label? No matter global SID for global label, SR needs a global identifier
> which needs to be advertised to all nodes in the network. I think the global
> label is the direct way. SRGB is just an indirect way to force the global
> identifier to becomes a form of local label. That is it!

[NOBO] That's not what I'm saying. You agree that SRGB is a solution. We know that there are SRGB implementations out there. So attempting to say that SRGB of Segment Routing needs your global label framework just doesn't seem sound to me.

> 
> 
> I've only had a quick scan of draft-li-mpls-global-label-usecases (and haven't
> fully read all the referenced documents), but my immediate reaction was
> "are these real use cases?"
> [Robin] I understand you reaction and I hope you can read the usecase and
> the possible reference documents. In fact, these problem statement or
> usecase proposed here already exists in some RFC or WG drafts. But in these
> documents, the solutions may be called as other name which in my opinion
> is one type of global lablel or it adopts complex way to solve the issue
> which in my opinion can be easily solved if global label is adopted.

[NOBO] Sure I'll try to find time to read more of your documents.

> 
> Perhaps there's a value is re-writing this documents to exclude following
> categories:
> - This can become a use case if folks didn't want to use context labels.
> [Robin] I have explained it.Per-platform and context-specific are the
> parallel concepts to divide MPLS into two. Local and global label are another
> parrallel concepts to divide MPLS into two. Even if context lael is used, it
> should also be called as global label if it has global meaning.

[NOBO] I'm not discussing any solution here, but just trying to understand the validity of use cases you listed for the need for global labels.

> - This can become a use case if things like this was ever required.
> [Robin] Partly agree. I rembers one thing Ford (founder of Ford car ) said
> that if I asked people what required, they may say a faster horse instead of
> car.

[NOBO] Kudos to you.

> - This can become a use case but there are solutions out there already.
> [Robin] Partly agree. MPLS TE does work and has been deployed widely.
> Why segment routing?
> [Robin] Regarding the latter two, my opinion is that we need to change with
> time.

[NOBO] That depends on the validity of your use cases, but at least the 3 above you added really aren't valid use cases. At this point, your "horses have these problems" reasons haven't been able to convince me.

Thanks!

-Nobo

> 
> 
> b
> My 2 yen.
> 
> Thanks!
> 
> -Nobo