[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] Comments on draft-li-mpls-global-label-usecases
From:       "Nobo Akiya (nobo)" <nobo () cisco ! com>
Date:       2014-07-31 23:33:22
Message-ID: CECE764681BE964CBE1DFF78F3CDD39439B2F9AC () xmb-aln-x01 ! cisco ! com
[Download RAW message or body]

Hi Xiaohu,

> -----Original Message-----
> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> Sent: Wednesday, July 30, 2014 9:40 PM
> To: Nobo Akiya (nobo); Lizhenbin; draft-li-mpls-global-label-
> usecases@tools.ietf.org
> Cc: mpls@ietf.org
> 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.

Thanks!

-Nobo
 
> 
> Best regards,
> Xiaohu

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


[prev in list] [next in list] [prev in thread] [next in thread]