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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 27 Jul 2014 19:05:27 +0000

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. However, what you need is a label that ingress and egress agree on, which granularity is likely at least one label per LSP. 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.

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.

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".

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?"

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.
- This can become a use case if things like this was ever required.
- This can become a use case but there are solutions out there already.

My 2 yen.

Thanks!

-Nobo

---

From: Lizhenbin <[email-masked]>
Date: Tue, 29 Jul 2014 08:30:05 +0000

Hi Nobo,
Thanks very much for your detailed my comments. Pleaser refer to my inline reply.

Best Regards,
Robin

________________________________________
发件人: Nobo Akiya (nobo) [[email-masked]]
发送时间: 2014年7月28日 3:05
收件人: [email-masked]
抄送: [email-masked]
主题: Comments on draft-li-mpls-global-label-usecases

Hi Authors,

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. 
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.

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.

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!

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.

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. 
- 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. 
- 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. 

b
My 2 yen.

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 31 Jul 2014 00:38:03 +0000

Hi Robin,

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

> -----Original Message-----
> From: Lizhenbin [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2014 4:30 AM
> To: Nobo Akiya (nobo); [email-masked]
> Cc: [email-masked]
> Subject: 答复: Comments on draft-li-mpls-global-label-usecases
> 
> Hi Nobo,
> [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.

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

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

> [Robin] Regarding the latter two, my opinion is that we need to change with

[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

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 31 Jul 2014 01:39:59 +0000

> 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 
> 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.

Hi Nobo,

It's fine that SFC is data plane agnostic. In the MPLS-SPRING-based SFC approach (http://www.ietf.org/proceedings/90/slides/slides-90-spring-5.pdf) where the SFC-specific header is implemented in the form of an MPLS label stack, the SFC-encapsulated packet (i.e., the MPLS packet) could still be transported between service nodes over any transport such as MPLS, IP (e.g., MPLS-over-UDP or MPLS-over-GRE) or even Ethernet. To some extent, the MPLS-SPRING-based SFC approach is data plane agnostic as well. 

As had been mentioned in the above PDF, if it's the SFP information that is encoded in the MPLS label stack, there is no need for global labels. However, provided that some operators did want to encode the SFC information, rather than the SFP information in the MPLS label stack, the only feasible way to realize such goal is to use global labels. Here the global labels just need to be unique within the SFC-enabled domain, in other words, they are domain-wide unique labels. Just like the global label usage proposed in the segment routing mechanism, it only requires that a common label block, referred to as SF Label Block (SFLB) is reserved by all service nodes and Classifiers for SF SIDs. The domain-wide unique label for a given SF would be automatically determined by adding the SF ID to the first label value of the above SFLB. 

Best regards,
Xiaohu

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 31 Jul 2014 23:33:22 +0000

Hi Xiaohu,

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2014 9:40 PM
> To: Nobo Akiya (nobo); Lizhenbin; draft-li-mpls-global-label-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-li-mpls-global-label-usecases
> 
> > 2. Service Chaining
> >
> [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.
> 
> Hi Nobo,
> 
> It's fine that SFC is data plane agnostic. In the MPLS-SPRING-based SFC
> approach (http://www.ietf.org/proceedings/90/slides/slides-90-spring-
> 5.pdf) where the SFC-specific header is implemented in the form of an
> MPLS label stack, the SFC-encapsulated packet (i.e., the MPLS packet) could
> still be transported between service nodes over any transport such as MPLS,
> IP (e.g., MPLS-over-UDP or MPLS-over-GRE) or even Ethernet. To some
> extent, the MPLS-SPRING-based SFC approach is data plane agnostic as well.
> 
> As had been mentioned in the above PDF, if it's the SFP information that is
> encoded in the MPLS label stack, there is no need for global labels. However,
> provided that some operators did want to encode the SFC information,
> rather than the SFP information in the MPLS label stack, the only feasible
> way to realize such goal is to use global labels. Here the global labels just
> need to be unique within the SFC-enabled domain, in other words, they are
> domain-wide unique labels. Just like the global label usage proposed in the
> segment routing mechanism, it only requires that a common label block,
> referred to as SF Label Block (SFLB) is reserved by all service nodes and
> Classifiers for SF SIDs. The domain-wide unique label for a given SF would
> be automatically determined by adding the SF ID to the first label value of
> the above SFLB.

You are creating a framework document based on a use case document that includes use cases from another use case document that is still an individual document. I understand the diff between SFC vs. SFs on SR and complications of NSH on the latter, but the way you are claiming this as a use case seems premature. Let the SFC folks do their work. Let the SPRING folks do their work. Let's focus our energy into helping to progress the two. If either of those spin off real inter-WG requirements, then we probably won't even need separate use case documents to start discussing solutions to address those requirements. In other words, let's not take use cases w/o WG consensus to drive additional use cases to drive solutions.

Thanks!

-Nobo

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 1 Aug 2014 01:37:37 +0000

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: Friday, August 01, 2014 7:33 AM
> To: Xuxiaohu; Lizhenbin; [email-masked]
> Cc: [email-masked]
> > > 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.
> > > 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.
> >
> > It's fine that SFC is data plane agnostic. In the MPLS-SPRING-based
> > SFC approach
> > (http://www.ietf.org/proceedings/90/slides/slides-90-spring-
> > MPLS label stack, the SFC-encapsulated packet (i.e., the MPLS packet)
> > could still be transported between service nodes over any transport
> > such as MPLS, IP (e.g., MPLS-over-UDP or MPLS-over-GRE) or even
> > Ethernet. To some extent, the MPLS-SPRING-based SFC approach is data plane
> agnostic as well.
> >
> > As had been mentioned in the above PDF, if it's the SFP information
> > that is encoded in the MPLS label stack, there is no need for global
> > labels. However, provided that some operators did want to encode the
> > SFC information, rather than the SFP information in the MPLS label
> > stack, the only feasible way to realize such goal is to use global
> > labels. Here the global labels just need to be unique within the
> > SFC-enabled domain, in other words, they are domain-wide unique
> > labels. Just like the global label usage proposed in the segment
> > routing mechanism, it only requires that a common label block,
> > referred to as SF Label Block (SFLB) is reserved by all service nodes
> > and Classifiers for SF SIDs. The domain-wide unique label for a given
> > SF would be automatically determined by adding the SF ID to the first label
> value of the above SFLB.
> 
> You are creating a framework document based on a use case document that
> includes use cases from another use case document that is still an individual
> document. I understand the diff between SFC vs. SFs on SR and complications of
> NSH on the latter, but the way you are claiming this as a use case seems
> premature. Let the SFC folks do their work. Let the SPRING folks do their work.
> Let's focus our energy into helping to progress the two. If either of those spin off
> real inter-WG requirements, then we probably won't even need separate use
> case documents to start discussing solutions to address those requirements. In
> other words, let's not take use cases w/o WG consensus to drive additional use
> cases to drive solutions.

Hi Nobo,

> > there is no need to use global labels to describe service functions.

That is: even when SFC runs on MPLS data plane, it's still feasible to use the MPLS label stack to describe the SFP or the SFC information. Furthermore, in the latter case (i.e., encoding SFC information in the label stack), using global labels (i.e., domain-wide unique label) to indicate SFs is the only choice. Otherwise, the SFF (contained in the service node device) may need to swap the whole label stack. BTW, global labels (i.e., domain-wide unique label) just need to be processed by classifiers and service nodes. The underlay could be IP networks (e.g., using MPLS-in-UDP). It doesn't require any change to the existing data plane. In other words, it's just a network configuration issue. Hence I really don't understand why you and some other guys are so strongly opposing the usage of global labels. 

Best regards,
Xiaohu