Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 4 Apr 2016 19:44:32 +0000

So, I found time to read the NSH draft in its entirety. A few suggestions:

Identify specific use cases that require NSH Sec 2.2 lists 7 broad areas that are too high level. 

 Examples

Bullet 2 "Service Chain Construction" cites the notion that most chains are built through manual config which is slow and error prone. Would a process that relies on a controller to configure these chains correct this deficiency or can it only be fixed with NSH.

Bullet 4 "Per Service (re) Classification"  How needed is this ? What percentage of chains will require it? More specific examples, what are the alternatives such as the not redirect the to a new chain but take terminal action there or send to a centralized controller ....

Bullet 6 "Limited End-to-End Service Visibility"  A bit confused here. Do we anticipate chains spanning multiple data centers? This would seem to require quite a bit of effort for the transport layer i.e MPLS.
 
IMO this entire section needs to be made for more specific. You may consider pulling it out into a reqs/use case draft.

Sec 2.3 identifies how all of the issues in Sec 2.2 are ameliorated. Need a better definition of Sec 2.2 prior to assigning the NSH remedy in Sec 2.3

Although I read the rest of the document I will not comment as the drivers for this new data plane encap is not clear to me. Have you reached out to the WGs that deal with data plane encap to see if they can meet the reqs?

It would be useful to see a matrix of data plane encaps currently in use and what functions required by SFC are supported. This may lead to a solution that does not create a new data encap but extends one of the current set.

If the notion here is to abstract data plane encap as there are too many, then it may be best to pick the one that most satisfies the SFC need and put a stake in the ground. 

Jim Uttaro

"This email and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing, or copying of this email is strictly prohibited."

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2016 9:59 PM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: Jim Guichard (jguichar) <[email-masked]>; Joel M. Halpern <[email-masked]>; Stewart Bryant <[email-masked]>; UTTARO, JAMES <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2016 9:54 PM
> To: Xuxiaohu
> Cc: Jim Guichard (jguichar); Joel M. Halpern; Stewart Bryant; UTTARO, JAMES;
> Ron Parker; Dave Dolson; Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul;
> [email-masked]; [email-masked]
> Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
> 
> 
> > On Mar 21, 2016, at 9:56 PM, Xuxiaohu <[email-masked]> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> >> Sent: Tuesday, March 22, 2016 12:15 AM
> >> To: Xuxiaohu; Joel M. Halpern; Stewart Bryant; UTTARO, JAMES; Ron
> >> Parker; Dave Dolson; Dolganow, Andrew (Nokia - SG); EXT Bottorff,
> >> Paul; [email-masked]
> >> Cc: [email-masked]
> >> Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of
> >> NSH
> >>
> >>>
> >>>
> >>>
> >>>> So even if we had wanted to use a label stack for path
> >>>> identification, as far as I  can tell we would still need a header
> >>>> to carry the metadata.
> >>>
> >>> Yes. However, if metadata is not a mandatory component in any
> >>> service chain, it'd better to decouple the path identification
> >>> header from the metadata header, IMHO.
> >>
> >> In which case you can use MD-type 2 with length set to 0x2.
> >
> > What about if we just want the NSH to act as a metadata container?
> >
> 
> https://tools.ietf.org/html/rfc7665
> 
>    SFC Encapsulation:  The SFC encapsulation provides, at a minimum, SFP
>         identification, and is used by the SFC-aware functions, such as
>         the SFF and SFC-aware SFs.  The SFC encapsulation is not used
>         for network packet forwarding.  In addition to SFP
>         identification, the SFC encapsulation carries metadata including
>         data-plane context information.

My point is: when the SFP identification could be implemented by using a given existing forwarding paradigm, what we really need to invent is just a metadata container.

Best regards,
Xiaohu

> — Carlos.
> 
> > Best regards,
> > Xiaohu
> >
> >> Jim
> >>
> >>>
> >>>
> >>>> And that means that anything that needed the metadata or inner
> >>>> packet would  have to parse the label stack.
> >>>> At which point ...
> >>>
> >>> At the bottom of the label stack.
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>> On 3/17/16 11:31 AM, Stewart Bryant wrote:
> >>>>> Yes, the MPLS label should be seen as an instruction - which is
> >>>>> exactly what it is, and always has been.
> >>>>>
> >>>>> You can trivially carry MPLS over IP.
> >>>>>
> >>>>> We do carry MPLS over Ethernet.
> >>>>>
> >>>>> In the above cases MPLS is the instruction, and IP and Ethernet
> >>>>> are the point to point transports.
> >>>>>
> >>>>> What is more interesting is how we carry the metadata, since there
> >>>>> may need to be several instances of the metadata in the packet.
> >>>>>
> >>>>> Stewart
> >>>>>
> >>>>> On 17/03/2016 12:30, UTTARO, JAMES wrote:
> >>>>>>
> >>>>>> */Ron,/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> */Have not been following the SFC WG that closely due to other
> >>>>>> more pressing needs for my network. That being said, it would
> >>>>>> seem that an MPLS label could be used as the basis for what you
> >>>>>> are looking for an thus could be applied to all network types.
> >>>>>> Using the MPLS label format does not force you to have an MPLS
> >>>>>> enabled network all that is needed is the required info to be
> >>>>>> populated in the label. It seems that the argument is for
> >>>>>> independence of network thus inventing a new label is based on an
> >>>>>> assumption that using MPLS labels imposes an MPLS control plane.
> >>>>>> Is that right?/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> */Jim Uttaro/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> "/This email and any files transmitted with it are AT&T property,
> >>>>>> are confidential, and are intended solely for the use of the
> >>>>>> individual or entity to whom this email is addressed. If you are
> >>>>>> not one of the named recipient(s) or otherwise have reason to
> >>>>>> believe that you have received this message in error, please
> >>>>>> notify the sender and delete this message immediately from your
> >>>>>> computer. Any other use, retention, dissemination, forwarding,
> >>>>>> printing, or copying of this email is strictly prohibited/."*//*
> >>>>>>
> >>>>>> *From:*Xuxiaohu [mailto:[email-masked]]
> >>>>>> *Sent:* Thursday, March 17, 2016 3:47 AM
> >>>>>> *To:* Ron Parker <[email-masked]>; UTTARO,
> >> JAMES
> >>>>>> <[email-masked]>; Dave Dolson <[email-masked]>;
> Dolganow,
> >>>>>> Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff,
> >>>>>> Paul <[email-masked]>; Stewart Bryant
> >>>>>> <[email-masked]>; [email-masked]
> >>>>>> *Cc:* [email-masked]
> >>>>>> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> Ron,
> >>>>>>
> >>>>>> The SFC approach of encoding the SFP information by an MPLS label
> >>>>>> stack can meet the transport-independency requirement very well.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Xiaohu
> >>>>>>
> >>>>>> *From:*Ron Parker [mailto:[email-masked]]
> >>>>>> *Sent:* Wednesday, March 16, 2016 11:20 PM
> >>>>>> *To:* UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew
> >>>>>> (Nokia - SG); EXT Bottorff, Paul; Stewart Bryant;
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> James,
> >>>>>>
> >>>>>> I can’t speak for the entire group, my understanding of the
> >>>>>> decision not to standardize on MPLS as the forwarding paradigm
> >>>>>> was to make SFC broader such that it could utilize MAC based
> >>>>>> networks, IP based networks, and IP-over-MPLS based networks.
> >>>>>>
> >>>>>> Ron
> >>>>>>
> >>>>>> *From:*UTTARO, JAMES [mailto:[email-masked]]
> >>>>>> *Sent:* Wednesday, March 16, 2016 11:11 AM
> >>>>>> *To:* Ron Parker <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Dave Dolson
> >>>>>> <[email-masked] <mailto:[email-masked]>>; Xuxiaohu
> >>>>>> <[email-masked] <mailto:[email-masked]>>; Dolganow,
> >>>> Andrew
> >>>>>> (Nokia - SG)
> >>>>>>
> >> <<mailto:[email-masked]>[email-masked]>;
> >>>> EXT
> >>>>>> Bottorff, Paul <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Stewart Bryant
> >>>>>> <[email-masked] <mailto:[email-masked]>>;
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> */Comments In-Line/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> */Jim Uttaro/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> "/This email and any files transmitted with it are AT&T property,
> >>>>>> are confidential, and are intended solely for the use of the
> >>>>>> individual or entity to whom this email is addressed. If you are
> >>>>>> not one of the named recipient(s) or otherwise have reason to
> >>>>>> believe that you have received this message in error, please
> >>>>>> notify the sender and delete this message immediately from your
> >>>>>> computer. Any other use, retention, dissemination, forwarding,
> >>>>>> printing, or copying of this email is strictly prohibited/."*//*
> >>>>>>
> >>>>>> *From:*Ron Parker [mailto:[email-masked]]
> >>>>>> *Sent:* Wednesday, March 16, 2016 10:01 AM
> >>>>>> *To:* Dave Dolson <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Xuxiaohu <[email-masked]
> >>>>>> <mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG)
> >>>>>>
> >> <<mailto:[email-masked]>[email-masked]>;
> >>>> EXT
> >>>>>> Bottorff, Paul <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Stewart Bryant
> >>>>>> <[email-masked] <mailto:[email-masked]>>;
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> My recollection of the discussion and analysis of MPLS forwarding
> >>>>>> to support SFC was not oriented around hierarchical SFC domains.
> >>>>>> Instead, I thought the discussion was around an MPLS label per SF
> >>>>>> instance so that the stack of MPLS labels provided the full SFP/RSP
> >>>>>> description.    An elegant approach, for sure, but not one adopted by
> >>>>>> the WG.
> >>>>>>
> >>>>>> */[Jim U>] Was this decision based on the notion that all fabrics
> >>>>>> are IP only?? IMO the model of all DCs being large and IP only is
> >>>>>> not a correct assumption./*
> >>>>>>
> >>>>>> The current discussion of MPLS is more of the hierarchical nature
> >>>>>> – a stack of labels in the general case represents a set of nested LSPs.
> >>>>>> For SFC, the discussion is that a stack of NSH represents a stack
> >>>>>> of per-SFC-domain SFPs. But an individual NSH does not
> >>>>>> self-describe the SFP/RSP at its own domain level, relying
> >>>>>> instead on a flat identifier (SFP ID) that is used to lookup the full
> SFP/RSP.
> >>>>>>
> >>>>>> Ron
> >>>>>>
> >>>>>> *From:*Dave Dolson [mailto:[email-masked]]
> >>>>>> *Sent:* Wednesday, March 16, 2016 9:48 AM
> >>>>>> *To:* Xuxiaohu <[email-masked]
> >> <mailto:[email-masked]>>;
> >>>>>> UTTARO, JAMES <[email-masked] <mailto:[email-masked]>>;
> >> Dolganow,
> >>>>>> Andrew (Nokia - SG)
> >>>>>>
> >> <<mailto:[email-masked]>[email-masked]>;
> >>>> EXT
> >>>>>> Bottorff, Paul <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Ron Parker
> >>>>>> <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Stewart Bryant
> >>>>>> <[email-masked] <mailto:[email-masked]>>;
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> Recall that draft-homma-sfc-forwarding-methods-analysis compares
> >>>>>> the different approaches.
> >>>>>>
> >>>>>> <https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-a
> >>>>>> n
> >>>>>> aly
> >>>>>> sis-05>https://tools.ietf.org/html/draft-homma-sfc-forwarding-met
> >>>>>> sis-05>h
> >>>>>> sis-05>ods
> >>>>>> -analysis-05
> >>>>>>
> >>>>>> The MPLS approach falls into the category discussed in section
> >>>>>> 3.1.2, “Method 2: Forwarding with Stacked Headers”,
> >>>>>>
> >>>>>> whereas the NSH approach falls into section 3.1.3, “Method3:
> >>>>>> Forwarding based on Service Chain Identifiers”.
> >>>>>>
> >>>>>> Section 4 analyzes the different methods, with pros and cons for
> >>>>>> all of the approaches.
> >>>>>>
> >>>>>> -Dave
> >>>>>>
> >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Xuxiaohu
> >>>>>> *Sent:* Tuesday, March 15, 2016 8:21 PM
> >>>>>> *To:* UTTARO, JAMES; Dolganow, Andrew (Nokia - SG); EXT Bottorff,
> >>>>>> Paul; Ron Parker; Stewart Bryant; [email-masked]
> >>>>>> <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> When applying a particular SFC (i.e., an ordered list of SFs) to
> >>>>>> the selected traffic, the traffic needs to be steered through the
> >>>>>> corresponding SFP (i.e., an ordered list of SFFs and SFs) in the
> >>>>>> SFC-enabled network. MPLS-SPRING is a particular MPLS source
> >>>>>> routing paradigm where the explicit path information (i.e., an
> >>>>>> ordered list of explicit hops) is encoded as a label stack (i.e.,
> >>>>>> an ordered list of labels with each indicating a particular
> >>>>>> explicit hop) and then piggybacked on the source routed packets.
> >>>>>> The MPLS-SPRING paradigm can be easily leveraged to steer the
> >>>>>> selected traffic through a particular SFP by encoding the SFP
> >>>>>> information as an MPLS label stack (i.e., an ordered list of
> >>>>>> labels with each indicating a particular
> >>>> SFF or SF).
> >>>>>> In this way, SFFs could be implemented on existing MPLS switches
> >>>>>> without any change to the data-plane provided that SFs are
> >>>>>> capable of recognizing MPLS packets.  As pointed out by somebody
> >>>>>> else, it’s much straightforward to support the stack of SFC
> >>>>>> encapsulations if the SFC encapsulation is implemented in the
> >>>>>> form of an
> >> MPLS label stack.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Xiaohu
> >>>>>>
> >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *UTTARO,
> >>>>>> JAMES
> >>>>>> *Sent:* Tuesday, March 15, 2016 8:46 PM
> >>>>>> *To:* Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Ron
> >>>>>> Parker; Stewart Bryant; [email-masked]
> >>>>>> <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> */If we have an MPLS enabled fabric wouldn’t it be simpler to
> >>>>>> weave NSH into it if it all uses MPLS? If not how would the
> >>>>>> interaction between the two environments work?/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> */Jim Uttaro/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> "/This email and any files transmitted with it are AT&T property,
> >>>>>> are confidential, and are intended solely for the use of the
> >>>>>> individual or entity to whom this email is addressed. If you are
> >>>>>> not one of the named recipient(s) or otherwise have reason to
> >>>>>> believe that you have received this message in error, please
> >>>>>> notify the sender and delete this message immediately from your
> >>>>>> computer. Any other use, retention, dissemination, forwarding,
> >>>>>> printing, or copying of this email is strictly prohibited/."*//*
> >>>>>>
> >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Dolganow,
> >>>>>> Andrew (Nokia - SG)
> >>>>>> *Sent:* Monday, March 14, 2016 11:52 PM
> >>>>>> *To:* EXT Bottorff, Paul
> >>>>>> <<mailto:[email-masked]>[email-masked]>; Ron
> Parker
> >>>>>> <[email-masked]
> >>>>>> <mailto:[email-masked]>>; Stewart Bryant
> >>>>>> <[email-masked] <mailto:[email-masked]>>;
> >>>>>> [email-masked] <mailto:[email-masked]>
> >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>> *Subject:* Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>>>> type of NSH
> >>>>>>
> >>>>>> Following “next header” approach  is simple and the NSH header is
> >>>>>> already built like that. Introducing MPLS like approach would add
> >>>>>> yet another mechanism to traverse the headers, which would make
> >>>>>> h/w more complex.
> >>>>>>
> >>>>>> It is true that h/w can only look at X Bytes (X depending on h/w).
> >>>>>> This is true for many headers not only this and even today
> >>>>>> (without
> >>>>>> NSH) you can end-up with payload being very deep in a packet. At
> >>>>>> the end we need to have a flexible mechanism which NSH nesting
> >>>>>> would provide. If someone “abuses it” this can lead to various
> >>>>>> issues. It is probably worth noting that in the draft including
> >>>>>> security considerations (by adding large headers it will be
> >>>>>> harder to perform payload based ACL DDoS protection in routers for
> example).
> >>>>>>
> >>>>>> Andrew
> >>>>>>
> >>>>>> On 2016-03-15, 3:03 AM, "sfc on behalf of EXT Bottorff, Paul" wrote:
> >>>>>>
> >>>>>>    Just one more concern about the stack is how deep it will nest.
> >>>>>>    Hardware switch implementations are typically limited in the
> >>>> depth
> >>>>>>    they look into the packet. If the hardware needs to look at the
> >>>>>>    original packet headers, then hardware would need to skip over
> >>>> the
> >>>>>>    stack of NSH headers to reach the original packet. If the NSH
> >>>>>>    stack is too deep it may exceed the hardware depth limits.
> >>>>>>
> >>>>>>    Cheers,
> >>>>>>
> >>>>>>
> >>>>>>    Paul
> >>>>>>
> >>>>>>    *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ron
> >>>> Parker
> >>>>>>    *Sent:* Monday, March 14, 2016 11:45 AM
> >>>>>>    *To:* Stewart Bryant
> >>>>>>
> <<mailto:[email-masked]>[email-masked]>;
> >>>>>>    [email-masked] <mailto:[email-masked]>
> >>>>>>    *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>>    *Subject:* Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header
> >>>> type
> >>>>>>    of NSH
> >>>>>>
> >>>>>>    I like the self describing stack of NSH headers and I like the
> >>>>>>    first one being the “current” scoping.   But, one difference
> >>>>>>    between MPLS and NSH…   MPLS forwarding is generally handled
> >> by
> >>>>>>    looking only at the MPLS labels that are “in scope” for the
> >>>>>>    current node (i.e., starting at the top-of-stack) and not needing
> >>>>>>    to locate and process the “payload” beyond the bottom-of-stack.
> >>>>>>    But, in NSH, most processing will require location of the
> >>>>>>    “payload” beyond the last NSH header.   It is inefficient to have
> >>>>>>    to walk the stack of NSH headers in order to locate that
> >>>>>>    payload.    If each NSH header that was pushed onto the stack
> >>>> also
> >>>>>>    included an offset to directly locate the payload (each new one
> >>>>>>    simply adds its own byte size), then this processing inefficiency
> >>>>>>    would be mitigated.
> >>>>>>
> >>>>>>    Ron
> >>>>>>
> >>>>>>    *From:*sfc [mailto:[email-masked]] *On Behalf Of
> >>>>>> *Stewart
> >>>> Bryant
> >>>>>>    *Sent:* Monday, March 14, 2016 5:40 AM
> >>>>>>    *To:* [email-masked] <mailto:[email-masked]>
> >>>>>>    *Cc:* [email-masked] <mailto:[email-masked]>
> >>>>>>    *Subject:* [GRAYMAIL] Re: [sfc] Adding an NSH.next-header type
> >>>>>> of NSH
> >>>>>>
> >>>>>>
> >>>>>>    Having reminded myself of the NSH header structure, I see that
> >>>> this
> >>>>>>    is not strictly needed since this naturally fits with the next
> >>>>>>    protocol component of the base header. Thus stating that the
> >>>> there
> >>>>>>    is no architectural limit on the number of SFH headers in a
> >>>> packet
> >>>>>>    is the necessary and sufficient requirement to allow an arbitatry
> >>>>>>    stack of NSH headers. Stating that new NSH headers are added at
> >>>>>>    the front
> >>>>>>    of the packet, and processed first and discarded first is
> >>>> sufficient
> >>>>>>    to remove any processing ambiguity. Processing would also be
> >>>> simpler
> >>>>>>    is you followed the MPLS rule that the outer header is the
> >>>>>> only
> >>>> one
> >>>>>>    in scope until that header is discarded (popped).
> >>>>>>
> >>>>>>    I do however wonder whether the IETF's architetural preference
> >>>> for
> >>>>>>    self describing packets (MPLS being the exception) leads us to
> >>>> more
> >>>>>>    complex and thus less efficent dataplane designs than we could
> >>>>>>    otherwise
> >>>>>>    achieve.
> >>>>>>
> >>>>>>    - Stewart
> >>>>>>
> >>>>>>    On 14/03/2016 01:44, [email-masked]
> >>>>>>    <mailto:[email-masked]> wrote:
> >>>>>>
> >>>>>>        Stewart,
> >>>>>>
> >>>>>>        Thanks.
> >>>>>>
> >>>>>>        Do you mean we should add an indicator for the nested NSH?
> >> I
> >>>>>>        agree anything new should be considered carefully. And that's
> >>>>>>        what we are doing right now.:)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>        发件人: Stewart Bryant <[email-masked]>
> >>>>>>        <mailto:[email-masked]>
> >>>>>>        收件人:
> >>>>>>
> >>>>>> <mailto:[email-masked]>"[email-masked]"<mailto:[email-masked]><sfc@ietf.
> >>>>>> org
> >>>>>>> ,
> >>>>>>
> >>>>>>        日期: 2016/03/11 17:25
> >>>>>>        主题: Re: [sfc] Adding an NSH.next-header type of NSH
> >>>>>>        发件人: "sfc" <[email-masked]>
> >>>>>> <mailto:[email-masked]>
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> -
> >>>>>> ---
> >>>>>> ---
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>        The protocol that chose the most elegant approach to layering
> >>>>>>        one header on another was MPLS, with its stacking approach
> >>>>>>        and one bit end of stack indicator.
> >>>>>>
> >>>>>>        Such a simple general approach has much to commend it
> >>>>>>        and you might think seriously about applying it here.
> >>>>>>
> >>>>>>        Stewart
> >>>>>>
> >>>>>>        _______________________________________________
> >>>>>>        sfc mailing list
> >>>>>>        [email-masked] <mailto:[email-masked]>
> >>>>>>
> >>>>>> <https://www.ietf.org/mailman/listinfo/sfc>https://www.ietf.org/m
> >>>>>> a
> >>>>>> ilm
> >>>>>> an/listinfo/sfc
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> sfc mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/sfc
> >>>>>
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sfc
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 5 Apr 2016 13:32:18 +0000

I fully agree that a matrix of data plane encaps currently in use and what functions required by SFC are supported should be a must before designing a new data plane.

Best regards,
Xiaohu

________________________________________
发件人: UTTARO, JAMES [[email-masked]]
发送时间: 2016年4月5日 3:44
收件人: Xuxiaohu; Carlos Pignataro (cpignata)
抄送: Jim Guichard (jguichar); Joel M. Halpern; Stewart Bryant; Ron Parker; Dave Dolson; Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; [email-masked]; [email-masked]
主题: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

 Examples

Jim Uttaro

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]]
Sent: Tuesday, March 22, 2016 9:59 PM
To: Carlos Pignataro (cpignata) <[email-masked]>
Cc: Jim Guichard (jguichar) <[email-masked]>; Joel M. Halpern <[email-masked]>; Stewart Bryant <[email-masked]>; UTTARO, JAMES <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Best regards,
Xiaohu