> -----Original Message----- > From: Nobo Akiya (nobo) [mailto:[email protected]] > Sent: Friday, August 01, 2014 7:33 AM > To: Xuxiaohu; Lizhenbin; [email protected] > Cc: [email protected] > Subject: RE: Comments on draft-li-mpls-global-label-usecases > > Hi Xiaohu, > > > -----Original Message----- > > From: Xuxiaohu [mailto:[email protected]] > > Sent: Wednesday, July 30, 2014 9:40 PM > > To: Nobo Akiya (nobo); Lizhenbin; draft-li-mpls-global-label- > > [email protected] > > Cc: [email protected] > > Subject: RE: Comments on draft-li-mpls-global-label-usecases > > > > > 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. > > > > 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.
Hi Nobo, I'm not creating a framework doc. I'm just expressing a different opinion from your argument as below: > > [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. 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 > Thanks! > > -Nobo > > > > > Best regards, > > Xiaohu _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
