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

From: Dave Dolson <[email-masked]>
Date: Thu, 10 Mar 2016 20:33:35 +0000

Originally in draft-ao-sfc-for-dc-interconnect-01,
and now in draft-dolson-sfc-hierarchical-05, 
there is the concept of nesting on NSH header within another NSH header.

Is there any objection to allocating another "Next Protocol" value for NSH in draft-ietf-sfc-nsh ?

So in section 3.2, would read:
This draft defines the following Next Protocol values:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4 : NSH                  <----- proposal
   0xFE-0xFF: Experimental

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Mar 2016 20:39:07 +0000

Hi, Dave.

Is this approach to facilitate the border SFF's operation?   That instead of storing/restoring its own NSH (with all of the problems that arise from that), it can keep it in place and just add the next level NSH for the nested SFC domain?   Does this imply than any entity other than the border SFF only acts on the last one and ignores any preceding NSH instances?    

What about for packets created in the nested SFC domain (as opposed to forwarded by)?   Should such packets replicate the NSH stack from the "trigger" packet that caused the creation of the new packet (if such a trigger exists)?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, March 10, 2016 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Adding an NSH.next-header type of NSH

Originally in draft-ao-sfc-for-dc-interconnect-01,
and now in draft-dolson-sfc-hierarchical-05, there is the concept of nesting on NSH header within another NSH header.

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet

David Dolson

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Thu, 10 Mar 2016 20:48:57 +0000

Ron,

Described in this section,
https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-05#section-3.1.4
Yes, the idea is to simply nest the upper-level NSH headers within the lower-level NSH headers.

The switching would be based exclusively on the outer (first) header.

And yes, a down-side is that SFs need to understand that stack of headers, with injected packets replicating the stack.
(This is mentioned in draft-dolson-sfc-hierarchical-05)

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:39 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Hi, Dave.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, March 10, 2016 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Adding an NSH.next-header type of NSH

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Mar 2016 20:52:31 +0000

Thanks, Dave.

I was thinking of a LIFO model rather than FIFO model, but both are logically equivalent and perhaps not very different from an efficiency perspective, either -- you still need to locate the actual payload frame or packet.

I would suggest that with this approach the SF's need to understand there is a stack of NSH, too.   This would be to address the same goal of reducing or eliminating the need to do any NSH store/restore, this time at the nested SFF (lower level, if I interpret your terminology correctly).

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:49 PM
To: Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Ron,

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:39 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Hi, Dave.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, March 10, 2016 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Adding an NSH.next-header type of NSH

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Thu, 10 Mar 2016 21:01:00 +0000

Ron,
I think you've got it.
If you can suggest a way to improve the wording of section 3.1.4, or highlight what confused you, I would appreciate it.

And from the tone of your message, I gather you find the new Next Protocol assignment to be useful?

Thanks,
-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:53 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Thanks, Dave.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:49 PM
To: Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Ron,

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:39 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Hi, Dave.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, March 10, 2016 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Adding an NSH.next-header type of NSH

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet

David Dolson

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Mar 2016 21:05:28 +0000

Yes, I think this is a useful approach (and I think nested SFC is a useful concept).   However, I think some thought needs to go into whether this is mandatory or optional capability at the SFF?   At the SF?   And if it is optional, what are the procedures when nested NSH is encountered by an entity that doesn't support it?

    Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 4:01 PM
To: Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Ron,
I think you've got it.

Thanks,
-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:53 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Thanks, Dave.

   Ron

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:49 PM
To: Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Ron,

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 3:39 PM
To: Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: Adding an NSH.next-header type of NSH

Hi, Dave.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, March 10, 2016 3:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Adding an NSH.next-header type of NSH

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet

David Dolson

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Mar 2016 16:38:30 -0500

The power of this capability is attractive.  There are several places 
that would be affected.

1) SF - It seems to me that if we are going to do this, we better make 
sure that all NSH supporting SF can handle it.  So either we avoid it or 
we make support mandatory at the SF.
1') This implies that SFC-Proxies have to handle it.

2) Ingress and egress - Given that one will want to be able to nest 
using existing equipment, it looks like these need to be able to handle 
packets that have NSH on the outside of what the ingress / egress thinks 
of as the service chaining domain.

3) Classifiers - Given that a classifier in a domain may encounter 
packets with this nesting, it seems like support needs to be mandatory.

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Mar 2016 09:26:00 +0000

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 11 Mar 2016 13:02:29 +0000

+1

"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: sfc [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, March 11, 2016 4:26 AM
To: [email-masked]
Subject: Re: [sfc] Adding an NSH.next-header type of NSH

Stewart

---

From: [email-masked]
Date: Mon, 14 Mar 2016 09:38:38 +0800

Joel 

Yes, Classifier is required to support such kind of nested NSH, and we'd 
better add a NSH next protocol type for it.

Thanks!

Ting.

发件人:         "Joel M. Halpern" <[email-masked]>收件人:  Ron Parker 
<[email-masked]>, Dave Dolson <[email-masked]>, 
"[email-masked]" <[email-masked]>, 
抄送:   "[email-masked]" <[email-masked]>
日期:   2016/03/11 05:38
主题:   Re: [sfc] Adding an NSH.next-header type of NSH
发件人: "sfc" <[email-masked]>

Yours,
Joel

On 3/10/16 4:05 PM, Ron Parker wrote:
> Yes, I think this is a useful approach (and I think nested SFC is a 
useful concept).   However, I think some thought needs to go into whether 
this is mandatory or optional capability at the SFF?   At the SF?   And if 
it is optional, what are the procedures when nested NSH is encountered by 
an entity that doesn't support it?
> If you can suggest a way to improve the wording of section 3.1.4, or 
highlight what confused you, I would appreciate it.
> I was thinking of a LIFO model rather than FIFO model, but both are 
logically equivalent and perhaps not very different from an efficiency 
perspective, either -- you still need to locate the actual payload frame 
or packet.
>
> I would suggest that with this approach the SF's need to understand 
there is a stack of NSH, too.   This would be to address the same goal of 
reducing or eliminating the need to do any NSH store/restore, this time at 
the nested SFF (lower level, if I interpret your terminology correctly).
> And yes, a down-side is that SFs need to understand that stack of 
headers, with injected packets replicating the stack.
> Is this approach to facilitate the border SFF's operation?   That 
instead of storing/restoring its own NSH (with all of the problems that 
arise from that), it can keep it in place and just add the next level NSH 
for the nested SFC domain?   Does this imply than any entity other than 
the border SFF only acts on the last one and ignores any preceding NSH 
instances?
>
> What about for packets created in the nested SFC domain (as opposed to 
forwarded by)?   Should such packets replicate the NSH stack from the 
"trigger" packet that caused the creation of the new packet (if such a 
trigger exists)?
> and now in draft-dolson-sfc-hierarchical-05, there is the concept of 
nesting on NSH header within another NSH header.

---

From: [email-masked]
Date: Mon, 14 Mar 2016 09:44:45 +0800

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]>
收件人:         "[email-masked]" <[email-masked]>, 
日期:   2016/03/11 17:25
主题:   Re: [sfc] Adding an NSH.next-header type of NSH
发件人: "sfc" <[email-masked]>

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Mar 2016 09:40:22 +0000

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] wrote:
> anything new should be considered carefully. And that's what we are 
> doing right now.:)
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Mar 2016 18:45:28 +0000

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]
Cc: [email-masked]
Subject: [GRAYMAIL] Re: [sfc] Adding an NSH.next-header type of NSH

- 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]>
收件人:         "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>,
日期:         2016/03/11 17:25
主题:        Re: [sfc] Adding an NSH.next-header type of NSH
发件人:        "sfc" <[email-masked]><mailto:[email-masked]>
________________________________

Stewart

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 14 Mar 2016 19:03:22 +0000

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 <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

   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

- Stewart

Thanks.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Mar 2016 20:45:37 +0000

An interesting idea.

Stewart

On 14/03/2016 18:45, Ron Parker wrote:
>
> 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]
> *Cc:* [email-masked]
> *Subject:* [GRAYMAIL] Re: [sfc] Adding an NSH.next-header type of NSH
>
>
> 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.:)
>
>
>
>
>
>
>     <mailto:[email-masked]>
>     收件人: "[email-masked]" <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>,
>     日期: 2016/03/11 17:25
>     发件人: "sfc" <[email-masked]> <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Mar 2016 20:49:26 +0000

That leads you in the direction of only putting in the NSH headers the 
minimum needed to conduct the opertion, and encoding it in the most 
efficient way. That in turn takes you away from self description and 
moves you in the direction of encoding the informtion as a set of 
references to pre-agreed groups of instructions - which is the MPLS model.

Stewart

On 14/03/2016 19:03, 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 <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
>
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Tue, 15 Mar 2016 03:52:02 +0000

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:

Cheers,

Paul

To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

   Ron

- Stewart

Thanks.

收件人:         "[email-masked]"<mailto:[email-masked]><[email-masked]><mailto:[email-masked]>,

Stewart

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 15 Mar 2016 12:45:57 +0000

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 <[email-masked]>; Ron Parker <[email-masked]>; Stewart Bryant <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Mar 2016 00:20:36 +0000

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]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Jim Uttaro

To: 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]>

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: [email-masked]
Date: Wed, 16 Mar 2016 17:24:23 +0800

I agree in H-SFC next protocol is the better way, while stacked MPLS mode 
can cause some issues, which also needs h/w additional support. 

I suggest we add detail description about the nested NSH header in the 
H-SFC draft according to so many valuable comments, and assign a value for 
next protocol when it is NSH packets. 

发件人:         "Dolganow, Andrew (Nokia - SG)" 
<[email-masked]>
收件人:         "EXT Bottorff, Paul" <[email-masked]>, Ron Parker 
<[email-masked]>, Stewart Bryant 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
抄送:   "[email-masked]" <[email-masked]>
日期:   2016/03/15 11:51
主题:   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

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

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

- Stewart

Thanks. 

发件人:         Stewart Bryant <[email-masked]> 
收件人:         "[email-masked]"<[email-masked]>, 
日期:         2016/03/11 17:25
主题:        Re: [sfc] Adding an NSH.next-header type of NSH 
发件人:        "sfc" <[email-masked]> 

Stewart

---

From: Dave Dolson <[email-masked]>
Date: Wed, 16 Mar 2016 13:48:02 +0000

Recall that draft-homma-sfc-forwarding-methods-analysis compares the different approaches.
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-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]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Best regards,
Xiaohu

To: Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Ron Parker; Stewart Bryant; [email-masked]<mailto:[email-masked]>

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Ron Parker <[email-masked]>
Date: Wed, 16 Mar 2016 14:00:50 +0000

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.

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]>; UTTARO, JAMES <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; Ron Parker <[email-masked]>; Stewart Bryant <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

-Dave

To: UTTARO, JAMES; Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Ron Parker; Stewart Bryant; [email-masked]<mailto:[email-masked]>

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 16 Mar 2016 15:10:31 +0000

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]>; Xuxiaohu <[email-masked]>; UTTARO, JAMES <[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

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.

   Ron

To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[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]>

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Ron Parker <[email-masked]>
Date: Wed, 16 Mar 2016 15:19:56 +0000

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]>; Dave Dolson <[email-masked]>; Xuxiaohu <[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

Comments In-Line

Jim Uttaro

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) <[email-masked]<mailto:[email-masked]>>; EXT Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Mar 2016 16:03:17 +0000

On 16/03/2016 14:00, Ron Parker wrote:
> a stack of labels in the general case represents a set of nested LSPs

No, in the general case it represents a set of instructions to be
applied in sequence.

That is an important distinction without which MPLS losses
much of its power.

The advantage that an NSH header has over a pure MPLS
solution is that it can carry additional data needed by
later processing stages in the chain, although I suppose
it would be interesting to add the ability to carry
interstitial metadata in the MPLS label stack.

Stewart

---

From: Ron Parker <[email-masked]>
Date: Wed, 16 Mar 2016 17:00:34 +0000

Stewart,

Putting aside the discussion around appropriate abstractions for MPLS (and not refuting the abstraction you present), the SFC WG has not embraced, to my knowledge, a paradigm where there is one MPLS label per SF instance within an overall SFP/RSP.

   Ron

From: Stewart Bryant [mailto:[email-masked]]
Sent: Wednesday, March 16, 2016 12:03 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Xuxiaohu <[email-masked]>; UTTARO, JAMES <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 17 Mar 2016 07:46:57 +0000

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]
Cc: [email-masked]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

James,

   Ron

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) <[email-masked]<mailto:[email-masked]>>; EXT Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Mar 2016 06:31:06 -0400

I think this (transport independence) is an important point, so I wish 
to repeat it.
The working group is chartered to produce a "transport" independent SFC 
mechanism.  MPLS is a valid "transport" for SFC.
Phrased differently, SFC has to work over networks that use MPLS, and 
over networks that do not use MPLS.
The working group considered alternatives, and is currently using the 
NSH header as the mechanism to carry path identification and metadata.

We could use a different mechanism which splits path identification from 
metadata, and use some other mechanism that a single domain-wide id for 
the path.  But there are complications and costs associated with doing 
so.  It is a trade-off.

Yours,
Joel

PS: I quoted transport some of the time because there are so many 
different uses of the term "transport".  But I do not have a better word 
handy.

On 3/16/16 11:19 AM, Ron Parker wrote:
> 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]>; Dave Dolson
> <[email-masked]>; Xuxiaohu <[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
>
> */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) <[email-masked] <mailto:[email-masked]>>;
> EXT Bottorff, Paul <[email-masked]
> <mailto:[email-masked]>>; Stewart Bryant
> <[email-masked] <mailto:[email-masked]>>;
> [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) <[email-masked]
> <mailto:[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]>
> *Subject:* RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
>
> The MPLS approach falls into the category discussed in section 3.1.2,
> “Method 2: Forwarding with Stacked Headers”,
>
> *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]>
> 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]>
> */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 <[email-masked]
> <mailto:[email-masked]>>; Ron Parker
> <[email-masked]
> <mailto:[email-masked]>>; Stewart Bryant
> <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>
> 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
> headers it will be harder to perform payload based ACL DDoS protection
> in routers for example).
>
> Andrew
>
>     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
>
>     *To:* Stewart Bryant <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     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
>
>         agree anything new should be considered carefully. And that's
>         what we are doing right now.:)
>
>
>
>
>
>
>         收件人: "[email-masked]" <mailto:[email-masked]><[email-masked]>
>         <mailto:[email-masked]>,
>         日期: 2016/03/11 17:25

---

From: Ron Parker <[email-masked]>
Date: Thu, 17 Mar 2016 13:13:50 +0000

Hi, James.

No problems.   It’s impossible to follow everything in real time.   I don’t think there is much debate that MPLS labels were one viable approach to solve the problem and I think there was recognition that this could be done outside of an “MPLS network” through tunneling and without the traditional MPLS control plane protocols.   But, the WG came to a consensus decision that the NSH header was the chosen solution.   There is lots of discussion on the email archive if you were so inclined.

   Ron

From: UTTARO, JAMES [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 8:30 AM
To: Xuxiaohu <[email-masked]>; Ron Parker <[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,

                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]<mailto:[email-masked]>>; UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[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

Ron,

Best regards,
Xiaohu

To: UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Stewart Bryant; [email-masked]<mailto:[email-masked]>

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 17 Mar 2016 12:30:14 +0000

Ron,

Jim Uttaro

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]

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Dave Dolson <[email-masked]>
Date: Thu, 17 Mar 2016 13:41:38 +0000

Is it necessary to take an all-or-nothing approach in assigning the next-header value? Can support be optional?

Has it even been said that all classifiers and SFs MUST handle IPv4, IPv6 and Ethernet, the other assigned values for NSH.next-header?

And it seems typical for IETF to assign next-header/next-protocol values without making support mandatory.
There are something like 150 protocol values assigned for the IPv4 protocol field (and IPv6 next-header field), but I'm not aware of any requirement that an IP host support all of them.

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 10, 2016 4:39 PM
To: Ron Parker; Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Adding an NSH.next-header type of NSH

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Mar 2016 09:51:58 -0400

In general, no, there is no requirement that all next-header values be 
understood by all devices which understand the base header.

But we are talking about a next-header value specifically for SFC, in an 
SFC space.
If this next header value is needed to support a use case NSH considers 
important, that it seems like we need to call for the necessary support 
to make it work.

I suppose we could define it, with a big caveat that this may not be 
useable in all environments.  It just seems like the failures, when they 
inveitably occur, are going to occur in unexpected and hard to diagnose 
places.

In contrast, if you send IPv6 packets to an SF that only supports IPv4, 
it is pretty clear what has gone wrong.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 17 Mar 2016 14:01:46 +0000

Joel, Dave.

I'll reiterate that I support NSH being able to indicate next protocol is NSH.    The only concern I had is the inefficiency this introduces in locating the frame/packet being carried.    If you do not share the concern, I'm fine with simply defining a next protocol of NSH.   If you do share the concern, then NSH needs some additional field to allow for direct location of the frame/packet by examination of the top-most in-scope NSH, only.    As a counterpoint, in the real world this is unlikely to go more than 2 or 3 levels deep, in my opinion, so maybe it is a non-problem.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 9:52 AM
To: Dave Dolson <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Adding an NSH.next-header type of NSH

In general, no, there is no requirement that all next-header values be understood by all devices which understand the base header.

But we are talking about a next-header value specifically for SFC, in an SFC space.
If this next header value is needed to support a use case NSH considers important, that it seems like we need to call for the necessary support to make it work.

I suppose we could define it, with a big caveat that this may not be useable in all environments.  It just seems like the failures, when they inveitably occur, are going to occur in unexpected and hard to diagnose places.

In contrast, if you send IPv6 packets to an SF that only supports IPv4, it is pretty clear what has gone wrong.

Yours,
Joel

On 3/17/16 9:41 AM, Dave Dolson wrote:
> sure that all NSH supporting SF can handle it.  So either we avoid it 
> or we make support mandatory at the SF.
> using existing equipment, it looks like these need to be able to 
> handle packets that have NSH on the outside of what the ingress / 
> egress thinks of as the service chaining domain.
>
>> https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-05#section-
>> 3.1.4 Yes, the idea is to simply nest the upper-level NSH headers 
>> within the lower-level NSH headers.
>>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 17 Mar 2016 14:45:14 +0000

There are pros and cons to this approach, as with the other approaches to hSFC.
In https://tools.ietf.org/html/draft-dolson-sfc-hierarchical-05#section-3.1.4, 
we say about NSH-within-NSH:

   However, the down-side is it does require SFs in the lower-level
   domain to be able to parse multiple layers of NSH.  If the SF injects
   packets, it must also be able to deal with adding appropriate
   multiple layers of headers to injected packets.

Would you like more to be said?

BTW, I think the authors are interested to know which of the 4 approaches people prefer.
Opinions welcomed, as always.

-Dave

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 10:02 AM
To: Joel M. Halpern; Dave Dolson; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] Adding an NSH.next-header type of NSH

Joel, Dave.

    Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 9:52 AM
To: Dave Dolson <[email-masked]>; Ron Parker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Adding an NSH.next-header type of NSH

Yours,
Joel

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Mar 2016 15:31:19 +0000

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/*
>
> *//*
>
> 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 
> The SFC approach of encoding the SFP information by an MPLS label 
> stack can meet the transport-independency requirement very well.
>
> Best regards,
>
> Xiaohu
>
> *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] 
> 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 
> *To:* Ron Parker <[email-masked] 
> <mailto:[email-masked]>>; Dave Dolson 
> <[email-masked] <mailto:[email-masked]>>; Xuxiaohu 
> <[email-masked] <mailto:[email-masked]>>; Dolganow, Andrew 
> <[email-masked] <mailto:[email-masked]>>; Stewart Bryant 
> 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/."*//*
>
> *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) 
> <[email-masked] <mailto:[email-masked]>>; EXT 
> Bottorff, Paul <[email-masked] <mailto:[email-masked]>>; 
> Stewart Bryant <[email-masked] 
> 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./*
>
> UTTARO, JAMES <[email-masked] <mailto:[email-masked]>>; Dolganow, 
> Andrew (Nokia - SG) <[email-masked] 
> whereas the NSH approach falls into section 3.1.3, “Method3: 
> Forwarding based on Service Chain Identifiers”.
>
> *To:* UTTARO, JAMES; Dolganow, Andrew (Nokia - SG); EXT Bottorff, 
> Paul; Ron Parker; Stewart Bryant; [email-masked] 
> 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 
> */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/*
>
> *//*
>
> 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)
> 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
>
>     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
>
>     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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Mar 2016 11:38:57 -0400

When we started, I looked at the quesiton of carrying metadata in MPLS. 
  All of the answers I could come up with were ugly (not counting the 
ones that didn't work.)

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.
And that means that anything that needed the metadata or inner packet 
would have to parse the label stack.
At which point ...

Yours,
Joel

On 3/17/16 11:31 AM, Stewart Bryant wrote:
>> <<mailto:[email-masked]>[email-masked]>; EXT
>> <<mailto:[email-masked]>[email-masked]>; EXT
>> <<mailto:[email-masked]>[email-masked]>; EXT
>> Ron Parker <[email-masked]
>> <https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-05>https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-05
>>
>> *To:* EXT Bottorff, Paul
>> <<mailto:[email-masked]>[email-masked]>; Ron Parker
>>     *To:* Stewart Bryant
>>     <<mailto:[email-masked]>[email-masked]>;
>>         收件人:
>>         <mailto:[email-masked]>"[email-masked]"<mailto:[email-masked]><[email-masked]>,
>>
>>         日期: 2016/03/11 17:25
>>         <https://www.ietf.org/mailman/listinfo/sfc>https://www.ietf.org/mailman/listinfo/sfc
>>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Mar 2016 15:48:10 +0000

Joel

So anything that needs to look at the metadata is not pure MPLS.

So you could have an MPLS label stack that is used to deliver the packet
to the point where the metadata is needed.

Close the stack at that point and put in any metadata ONLY needed by the
receiving LSR - call this the intermediate point metadata. If the packet
metadata is needed include in the IP metadata a pointer to the
packet metadata. Then reopen the label stack as needed.

For example.

Stewart

On 17/03/2016 15:38, Joel M. Halpern wrote:
> When we started, I looked at the quesiton of carrying metadata in 
> MPLS.  All of the answers I could come up with were ugly (not counting 
> the ones that didn't work.)
>
>>> <mailto:[email-masked]>
>>>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 17 Mar 2016 15:54:48 +0000

So, if I wanted to form simple service chains i.e nailed up, not self-modulating etc…how much meta data would I need?

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: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 11:31 AM
To: UTTARO, JAMES <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Stewart

Jim Uttaro

To: Ron Parker <[email-masked]><mailto:[email-masked]>; UTTARO, JAMES <[email-masked]><mailto:[email-masked]>; Dave Dolson <[email-masked]><mailto:[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]><mailto:[email-masked]>; EXT Bottorff, Paul <[email-masked]><mailto:[email-masked]>; Stewart Bryant <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 17 Mar 2016 16:40:57 +0000

Off the top of my head:

For each hop that did not need to look at the metadata 0.

For each hop that needed to look at a common metadata block further down 
the stack no more than four bytes. That allows a pointer, and some flags 
and a tiny amount of per hop data.

For anything else whatever the size of the metadata needed is.

To put this is context in the length of a v6 header you can get 5 mpls 
labels each with a four byte per hop block.

Stewart

On 17/03/2016 15:54, UTTARO, JAMES wrote:
>
> */So, if I wanted to form simple service chains i.e nailed up, not 
> self-modulating etc…how much meta data would I need? /*
>
> *//*
>
> */Jim Uttaro/*
>
> *//*
>
> *From:*Stewart Bryant [mailto:[email-masked]]
> *Sent:* Thursday, March 17, 2016 11:31 AM
> *To:* UTTARO, JAMES <[email-masked]>; Xuxiaohu <[email-masked]>; 
> Ron Parker <[email-masked]>; Dave Dolson 
> <[email-masked]>; Dolganow, Andrew (Nokia - SG) 
> <[email-masked]>; EXT Bottorff, Paul 
> <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
>     */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/."
>
>     *To:* Ron Parker <[email-masked]>
>     <mailto:[email-masked]>; UTTARO, JAMES
>     <[email-masked]> <mailto:[email-masked]>; Dave Dolson
>     <[email-masked]> <mailto:[email-masked]>; Dolganow,
>     Andrew (Nokia - SG) <[email-masked]>
>     <mailto:[email-masked]>; EXT Bottorff, Paul
>     <[email-masked]> <mailto:[email-masked]>; Stewart
>     Bryant <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     *To:* UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew
>     (Nokia - SG); EXT Bottorff, Paul; Stewart Bryant;
>     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
>
>     <[email-masked] <mailto:[email-masked]>>; Dolganow,
>     <[email-masked] <mailto:[email-masked]>>; Stewart
>     Bryant <[email-masked]
>     "/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/."
>
>     <[email-masked] <mailto:[email-masked]>>;
>     My recollection of the discussion and analysis of MPLS forwarding
>     to support SFC was not oriented around hierarchical SFC domains.  
>     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
>
>     The MPLS approach falls into the category discussed in section
>     3.1.2, “Method 2: Forwarding with Stacked Headers”,
>
>     When applying a particular SFC (i.e., an ordered list of SFs) to
>     the selected traffic, the traffic needs to be steered through 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
>
>     *To:* Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Ron
>     Parker; Stewart Bryant; [email-masked] <mailto:[email-masked]>
>     */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/."
>
>     already built like that. Introducing MPLS like approach would add
>     yet another mechanism to traverse the headers, which would make
>     h/w more complex.
>
>     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
>
>         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
>
>         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
>
>             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.:)
>
>
>
>
>
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 17 Mar 2016 17:38:54 +0000

Yes. That would seem to be the right approach.

Jim Uttaro

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 11:48 AM
To: Joel M. Halpern <[email-masked]>; UTTARO, JAMES <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Joel

For example.

Stewart

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 17 Mar 2016 21:10:25 +0000

For a nailed down service chain without metadata once can use vlan stitching, mac based, heck it can be HTTP header based if we want to. So yes neither NSH not metadata is required. But it is often do not interoperate.

I am bit lost on how this discussion fits in with NSH protocol in general?

Sumandra

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 17, 2016 at 8:54 AM
To: Stewart Bryant <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "Dolganow, Andrew (Nokia - SG)" <[email-masked]<mailto:[email-masked]>>, "EXT Bottorff, Paul" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Jim Uttaro

To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>>; EXT Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "Dolganow, Andrew (Nokia - SG)" <[email-masked]>
Date: Fri, 18 Mar 2016 01:44:54 +0000

Agree with Stewart, this would make most sense. It may make sense to
continue this discussion under different subject - to me this is
orthogonal to next-header type which originally was covered here.

Andrew

On 2016-03-18, 1:38 AM, "EXT UTTARO, JAMES" wrote:

>"This email and any files transmitted with it are AT&T property, are
>forwarding, printing, or copying of this email is strictly prohibited."
>
>To: Joel M. Halpern <[email-masked]>; UTTARO, JAMES
><[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker
><[email-masked]>; Dave Dolson <[email-masked]>;
>Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff,
>Paul <[email-masked]>; [email-masked]
>Cc: [email-masked]
>>>><https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysi
>>>>s-05>https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-ana
>>>>lysis-05 
>>>>
>>>>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Mar 2016 06:46:25 +0000

Hi Joel,

> Sent: Thursday, March 17, 2016 11:39 PM
> To: Stewart Bryant; UTTARO, JAMES; Xuxiaohu; Ron Parker; Dave Dolson;
> Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; [email-masked]
> Cc: [email-masked]
>   All of the answers I could come up with were ugly (not counting the ones that
> didn't work.)

Could you please illustrate those answers that you thought ugly?

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

> 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

> > 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
> >
> >> label is based on an assumption that using MPLS labels imposes an
> >> MPLS control plane. Is that right?/*
> >>
> >> *//*
> >>
> >> */Jim Uttaro/*
> >>
> >> *//*
> >>
> >> 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
> >> this message immediately from your computer. Any other use,
> >> retention, dissemination, forwarding, printing, or copying of this
> >> email is strictly prohibited/."*//*
> >>
> >> <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow,
> >> Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul
> >> Bottorff, Paul <[email-masked]
> >> 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
> >> this message immediately from your computer. Any other use,
> >> retention, dissemination, forwarding, printing, or copying of this
> >> email is strictly prohibited/."*//*
> >>
> >> Bottorff, Paul <[email-masked]
> >> Bottorff, Paul <[email-masked]
> >> <https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analy
> >> sis-05>https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods
> >> -analysis-05
> >>
> >> 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).
> >> 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
> >> this message immediately from your computer. Any other use,
> >> retention, dissemination, forwarding, printing, or copying of this
> >> email is strictly prohibited/."*//*
> >>
> >> provide. If someone “abuses it” this can lead to various issues. It
> >> is probably worth noting that in the draft including security
> >> <mailto:[email-masked]>"[email-masked]"<mailto:[email-masked]><[email-masked]
> >> >,
> >>
> >>         日期: 2016/03/11 17:25

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Mar 2016 06:59:43 +0000

Hi Joel,

> Sent: Thursday, March 17, 2016 6:31 PM
> To: Ron Parker; UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew
> (Nokia - SG); EXT Bottorff, Paul; Stewart Bryant; [email-masked]
> Cc: [email-masked]
> I think this (transport independence) is an important point, so I wish to repeat it.

> Phrased differently, SFC has to work over networks that use MPLS, and over
> networks that do not use MPLS.

When implementing an SFC encapsulation header in the form of an MPLS label stack, that SFC encapsulation header is still transport-independent since MPLS packets can be transported over non-MPLS networks (e.g., IP networks)

> The working group considered alternatives, and is currently using the NSH
> header as the mechanism to carry path identification and metadata.
> 
> metadata, and use some other mechanism that a single domain-wide id for the
> path.  But there are complications and costs associated with doing so.  It is a
> trade-off.

When implementing an SFC encapsulation header in the form of an MPLS label stack, SFFs could be built on the existing MPLS switches. In this way, there is no need of introducing a new forwarding paradigm.

Best regards,
Xiaohu

> Yours,
> Joel
> 
> PS: I quoted transport some of the time because there are so many different
> uses of the term "transport".  But I do not have a better word handy.
> 
> > <[email-masked]>; Xuxiaohu <[email-masked]>; Dolganow,
> > named
> > recipient(s) or otherwise have reason to believe that you have
> > <mailto:[email-masked]>>; Dolganow, Andrew (Nokia
> > correct
> > named
> > recipient(s) or otherwise have reason to believe that you have
> >     On 14/03/2016 01:44, [email-masked]
> >     wrote:

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 18 Mar 2016 13:22:10 +0000

The use of MPLS labels would facilitate SDN control of service chains. We could use anything but VLAN stitching etc.. is not scalable or realistic to operate in a large network composed of many smaller data centers. I guess where I get hung up in this discussion is why overload the NSH header object with both path info and metadata? Is there a notion that they are intrinsically tied together if so, could folks provide an example? That would be helpful.

Thanks,
                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: Sumandra Majee [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 5:10 PM
To: UTTARO, JAMES <[email-masked]>; Stewart Bryant <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "Bottorff, Paul" <[email-masked]>
Date: Fri, 18 Mar 2016 16:58:32 +0000

Hi James:

I believe the NSH header path forwarding information should be and optional part of the NSH header. The reason for this is it appears there are a variety of chain forwarding methods which make sense for different applications.

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
Sent: Friday, March 18, 2016 6:22 AM
To: Sumandra Majee <[email-masked]>; Stewart Bryant <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Thanks,
                Jim Uttaro

To: UTTARO, JAMES <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>>; EXT Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Joel Halpern <[email-masked]>
Date: Fri, 18 Mar 2016 13:42:38 -0400

One of the points of having the path identification in the NSH header is 
to enable interoperability.  There are indeed a whole lot of transport 
mechanisms.  Several of which can convey path information (which is why 
the architecture allows for making use of that information.)

If we do not have the NSH path information, then in order to have 
itneroperability between two solutions, there has to be a box at the 
boundary which not only understands the two transports, but understand 
the path information structure well enough to convert it.
With the NSH path information, there is no conversion.  Instead of an 
N^2 conversion and translation task, you proess incoming, use NSH, and 
produce outgoing.

Giving up that critical interoperability seems like a very bad design 
selection.

Yours,
Joel

On 3/18/16 12:58 PM, Bottorff, Paul wrote:
> Hi James:
>
> I believe the NSH header path forwarding information should be and
> optional part of the NSH header. The reason for this is it appears there
> are a variety of chain forwarding methods which make sense for different
> applications.
>
>
> Cheers,
>
> Paul
>
> *Sent:* Friday, March 18, 2016 6:22 AM
> *To:* Sumandra Majee <[email-masked]>; Stewart Bryant
> <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker
> Dolganow, Andrew (Nokia - SG) <[email-masked]>; Bottorff,
> */The use of MPLS labels would facilitate SDN control of service chains.
> We could use anything but VLAN stitching etc.. is not scalable or
> realistic to operate in a large network composed of many smaller data
> centers. I guess where I get hung up in this discussion is why overload
> the NSH header object with both path info and metadata? Is there a
> notion that they are intrinsically tied together if so, could folks
> provide an example? That would be helpful./*
>
> *//*
>
> */Thanks,/*
>
> */                Jim Uttaro/*
>
> *//*
>
> *From:*Sumandra Majee [mailto:[email-masked]]
> *Sent:* Thursday, March 17, 2016 5:10 PM
> *To:* UTTARO, JAMES <[email-masked] <mailto:[email-masked]>>; Stewart
> Bryant <[email-masked] <mailto:[email-masked]>>;
> Xuxiaohu <[email-masked] <mailto:[email-masked]>>; Ron Parker
> <[email-masked] <mailto:[email-masked]>>; Dolganow, Andrew
> <[email-masked] <mailto:[email-masked]>>;
> For a nailed down service chain without metadata once can use vlan
> stitching, mac based, heck it can be HTTP header based if we want to. So
> yes neither NSH not metadata is required. But it is often do not
> interoperate.
>
> *From: *sfc <[email-masked] <mailto:[email-masked]>> on
> behalf of "UTTARO, JAMES" <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, March 17, 2016 at 8:54 AM
> *To: *Stewart Bryant <[email-masked]
> <mailto:[email-masked]>>, Xuxiaohu <[email-masked]
> <mailto:[email-masked]>>, Ron Parker
> <mailto:[email-masked]>>, Dave Dolson
> <[email-masked] <mailto:[email-masked]>>, "Dolganow, Andrew
> (Nokia - SG)" <[email-masked]
> <mailto:[email-masked]>>, "EXT Bottorff, Paul"
> <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Subject: *Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
>
> forwarding, printing, or copying of this email is strictly prohibited/."
>
> *To:* UTTARO, JAMES <[email-masked] <mailto:[email-masked]>>; Xuxiaohu
> <[email-masked] <mailto:[email-masked]>>; Ron Parker
> <[email-masked] <mailto:[email-masked]>>; Dolganow, Andrew
> <[email-masked] <mailto:[email-masked]>>;
>     */                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/*
>
>     *//*
>
>     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/."
>
>     Bryant <[email-masked]> <mailto:[email-masked]>;
>     *To:* UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew (Nokia
>     - SG); EXT Bottorff, Paul; Stewart Bryant; [email-masked]
>     not to standardize on MPLS as the forwarding paradigm was to make
>     SFC broader such that it could utilize MAC based networks, IP based
>     Bryant <[email-masked] <mailto:[email-masked]>>;
>     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/."
>
>     description.    An elegant approach, for sure, but not one adopted
>     by the WG.
>
>     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
>     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
>
>     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/."
>
>     yet another mechanism to traverse the headers, which would make h/w
>     more complex.
>
>         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
>
>         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
>         <mailto:[email-masked]> wrote:
>
>             Stewart,
>
>             Thanks.
>

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 18 Mar 2016 19:44:27 +0000

Hi Joel

Well if you had NSH path information as a way to interoperate other transport schemes only need to carry or generate NSH compatible information if they need to interoperate.  That is N to 1 not N^2.   

I like the idea that SFF and classifiers manipulate path information as in  https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-forwarding/ and that means that you can interface to Service functions with other transports as well.  

I think it is OK to have an NSH path model for interoperability but for reasons of performance and scale existing hardware and mechanisms can be easily leveraged.   So perhaps it is a standard NSH and published informational specs on ways that support a standard or perhaps we don't have to publish the alternatives at all. But I still think looking at the problem with various transports provides clarity of what we are doing.

Cheers
Don 

> From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern
> Sent: Friday, March 18, 2016 1:43 PM
> To: Bottorff, Paul <[email-masked]>
> Cc: [email-masked]
> One of the points of having the path identification in the NSH header is to
> enable interoperability.  There are indeed a whole lot of transport
> Giving up that critical interoperability seems like a very bad design selection.
> 
> Yours,
> Joel
> 
> > optional part of the NSH header. The reason for this is it appears
> > there are a variety of chain forwarding methods which make sense for
> > different applications.
> >
> >
> > Cheers,
> >
> > Paul
> >
> > centers. I guess where I get hung up in this discussion is why
> > overload the NSH header object with both path info and metadata? Is
> > there a notion that they are intrinsically tied together if so, could
> > folks provide an example? That would be helpful./*
> >
> > *//*
> >
> > */Thanks,/*
> >
> > */                Jim Uttaro/*
> >
> > *//*
> >
> > Xuxiaohu <[email-masked] <mailto:[email-masked]>>; Ron
> > Parker <[email-masked]
> > stitching, mac based, heck it can be HTTP header based if we want to.
> > So yes neither NSH not metadata is required. But it is often do not
> > interoperate.
> >
> > <[email-masked] <mailto:[email-masked]>>, "Dolganow,
> > Andrew (Nokia - SG)" <[email-masked]
> > dissemination, forwarding, printing, or copying of this email is strictly
> prohibited/."
> >
> <mailto:[email-masked]>;
> (Nokia
> <mailto:[email-masked]>>;

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 18 Mar 2016 15:44:21 +0000

The fact that the work group is not officially chartered to cover forwarding methods has caused forwarding aspects to creep in other headers like NSH in my opinion. I think only by drafting out a set of forwarding technologies with NSH (or other similar headers) in toe can you get a sense of what belongs where.  We analyzed this aspect in our draft on MAC chaining. We believe IP tunnels, MPLS or segment routing would be have similarities with respect to NSH.  I think we will have a variety of forwarding technologies in various environments.

Cheers
Don

From: sfc [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
Sent: Friday, March 18, 2016 9:22 AM
To: Sumandra Majee <[email-masked]>; Stewart Bryant <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Thanks,
                Jim Uttaro

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2016 13:41:16 -0400

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:09:10 +0000

Hi Jim,

The ability to carry just path information in NSH is already there; if you use MD-type 2 with length 0x2 you essentially carry NSH path information with no TLVs.

From the NSH specification:

3.5.  NSH MD-type 2

   When the base header specifies MD Type= 0x2, zero or more Variable
   Length Context Headers MAY be added, immediately following the
   Service Path Header.  Therefore, Length = 0x2, indicates that only
   the Base Header followed by the Service Path Header are present.  The
   optional Variable Length Context Headers MUST be of an integer number
   of 4-bytes.

Jim

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 18, 2016 at 8:22 AM
To: Sumandra Majee <[email-masked]<mailto:[email-masked]>>, Stewart Bryant <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "Dolganow, Andrew (Nokia - SG)" <[email-masked]<mailto:[email-masked]>>, "EXT Bottorff, Paul" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Thanks,
                Jim Uttaro

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:14:39 +0000

>>as far as I
>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.

Jim

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:17:27 +0000

>When implementing an SFC encapsulation header in the form of an MPLS
>label stack, that SFC encapsulation header is still transport-independent
>since MPLS packets can be transported over non-MPLS networks (e.g., IP
>networks)

And what do you do if the non-MPLS network actually hosts one or more of
the services? By implementing a service plane (aka. NSH) you get the best
of both worlds; you can deploy services in the MPLS and non-MPLS parts of
the network using the same encapsulation and rely upon the underlying
transport (MPLS or otherwise) to deliver packets to the services.

Jim

>>NSH
>>the
>When implementing an SFC encapsulation header in the form of an MPLS
>label stack, SFFs could be built on the existing MPLS switches. In this
>way, there is no need of introducing a new forwarding paradigm.
>
>Best regards,
>Xiaohu
>
>> Yours,
>> Joel
>> 
>>different
>>Instead,
>>stack
>>first
>> >     stack of NSH headers. Stating that new NSH headers are added at
>>the
>> >     front

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:47:03 +0000

Don,

It's always great to hear opinions but they should be considered in the context of the architecture we agreed on shortly after working group formation.  NSH does not provide _network_ forwarding information and to label it (no pun intended) as such is not only misleading but conveys an architectural misunderstanding.  The NSH path-ID is simply an identifier for the service path.  Nothing more.  Using that indirection, NSH provides several keys benefits at the _service plane_, most notably (but not exclusively) the ability to avoid per-hop reclassification and the ability to be transport independent.  Both of those attributes haven proven themselves as implementations have evolved.

So, to your point, NSH only identities the service path and the network transport (MPLS, IP, VXLAN, etc.) provide the forwarding.

Paul

On Mar 18, 2016, at 11:44 AM, Fedyk, Don <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
Don

To: Sumandra Majee <[email-masked]<mailto:[email-masked]>>; Stewart Bryant <[email-masked]<mailto:[email-masked]>>; Xuxiaohu <[email-masked]<mailto:[email-masked]>>; Ron Parker <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG) <[email-masked]<mailto:[email-masked]>>; Bottorff, Paul <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Thanks,
                Jim Uttaro

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

To: Ron Parker <[email-masked]><mailto:[email-masked]>; UTTARO, JAMES <[email-masked]><mailto:[email-masked]>; Dave Dolson <[email-masked]><mailto:[email-masked]>; Dolganow, Andrew (Nokia - SG)<[email-masked]><mailto:[email-masked]>; EXT Bottorff, Paul <[email-masked]><mailto:[email-masked]>; Stewart Bryant <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 22 Mar 2016 01:56:26 +0000

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

What about if we just want the NSH to act as a metadata container?

Best regards,
Xiaohu

> >> > 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
> >> >
> >> >> printing, or copying of this email is strictly prohibited/."*//*
> >> >>
> >> >> Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff,
> >> >> Paul <[email-masked]>; Stewart Bryant
> >> >> <[email-masked]>; [email-masked]
> >> >> *Cc:* [email-masked]
> >> >> printing, or copying of this email is strictly prohibited/."*//*
> >> >>
> >> >> – 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
> >> >> sis-05>https://tools.ietf.org/html/draft-homma-sfc-forwarding-meth
> >> >> sis-05>ods
> >> >> -analysis-05
> >> >>
> >> >> labels with each indicating a particular
> >>SFF or SF).
> >> >> 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
> >> >>
> >> >> printing, or copying of this email is strictly prohibited/."*//*
> >> >>
> >> >> (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
> >> >>
> by
> >> >>     *From:*sfc [mailto:[email-masked]] *On Behalf Of
> >> >> *Stewart
> >> Bryant
> >> >>     the front
> >> >>     is you followed the MPLS rule that the outer header is the
> >> >> only
> >>one
> I
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> ---
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> <https://www.ietf.org/mailman/listinfo/sfc>https://www.ietf.org/ma
> >> >> ilm
> >> >> an/listinfo/sfc
> >> >>
> >> >
> >> >
> >> >

---

From: "Fedyk, Don" <[email-masked]>
Date: Tue, 22 Mar 2016 12:54:10 +0000

Hi Paul Q.

I re- read the architecture and I’m OK with it.

It states

“If there is another non-local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path.

~

SFP forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation.  These platforms may opt to use existing transport information, if it can be arranged, to provide explicit service path information.”

In our efforts to do the above in MAC chaining we have found that using the existing L2 transport, the forwarding context information is related to Service Paths IDs (It is each local MAC chain ID  to a Service path IDs per chain). It would seem to be advantageous have the same authority (control in SFC architecture terms) administer both I think.  What I have surmised from discussion on the list is that others that have used other transport techniques and found similar relationships.   So in our case the Service path ID is more than just an independent identifier bearing a relationship to SFP forwarding identifiers both in implementation and administration.   I agree both Service Path and MAC chain have no relationship to the underlay or the original packet transports but they are both SPF context based identifiers.

Cheers
Don

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Monday, March 21, 2016 12:47 PM
To: Fedyk, Don <[email-masked]>
Cc: UTTARO, JAMES <[email-masked]>; Sumandra Majee <[email-masked]>; Stewart Bryant <[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; Dolganow, Andrew (Nokia - SG) <[email-masked]>; Bottorff, Paul <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Don,

Paul

Cheers
Don

Thanks,
                Jim Uttaro

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 22 Mar 2016 02:03:20 +0000

> Sent: Tuesday, March 22, 2016 12:17 AM
> To: Xuxiaohu; Joel M. Halpern; Ron Parker; UTTARO, JAMES; Dave Dolson;
> Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Stewart Bryant;
> [email-masked]
> Cc: [email-masked]
> >label stack, that SFC encapsulation header is still
> >transport-independent since MPLS packets can be transported over
> >non-MPLS networks (e.g., IP
> >networks)
> 
> And what do you do if the non-MPLS network actually hosts one or more of the
> services? By implementing a service plane (aka. NSH) you get the best of both
> worlds; you can deploy services in the MPLS and non-MPLS parts of the network
> using the same encapsulation and rely upon the underlying transport (MPLS or
> otherwise) to deliver packets to the services.

By implementing a service plane (i.e., an SFC encapsulation header) in the form of an MPLS label stack, you are allowed to deploy services in the MPLS and non-MPLS networks as well. In addition, it allows the non-MPLS network hosts one or more services. In other words, the SFC encapsulation header which is implemented in the form of an MPLS label stack is transport-independent.

Best regards,
Xiaohu

> >> We could use a different mechanism which splits path identification
> >>from  metadata, and use some other mechanism that a single domain-wide
> >>id for the  path.  But there are complications and costs associated
> >>with doing so.
> >>It is a
> >> trade-off.
> >
> >>different  uses of the term "transport".  But I do not have a better
> >>word handy.
> >>
> >> > not one of the named
> >> > 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.
> >> > a stack of labels in the general case represents a set of nested LSPs.
> >> > 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
> >> >
> >> > https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-anal
> >> > ysi
> >> > s-05
> >> >
> >> > information as an MPLS label stack (i.e., an ordered list of labels with each
> indicating a particular SFF or SF).
> >> > of recognizing MPLS packets.  As pointed out by somebody else, it’s
> >> > the SFC encapsulation is implemented in the form of an MPLS label stack.
> >> >
> >> > Best regards,
> >> >
> >> > Xiaohu
> >> >
> >> > not one of the named
> >> > -------------------------------------------------------------------
> >> > ---
> >> > --
> >> >
> >> >
> >> >
> >> >
> >> >

---

From: [email-masked]
Date: Tue, 22 Mar 2016 17:21:17 +0800

Hi Paul，

I agree that the NSH should only be the SFC path identifier which is used 
for forwarding alone the SFC path. But SFF as a forwarder should give some 
network forwarding information to the network device. One exmaple is 
described in https://tools.ietf.org/html/draft-ao-sfc-overlay-00.txt, in 
which SFF is required to carry network forwarding information when it 
forwards packets to network edge device, so that network device can 
provide correct network transport.

Ting.

发件人:         "Paul Quinn (paulq)" <[email-masked]>
收件人:         "Fedyk, Don" <[email-masked]>, 
抄送:   "UTTARO, JAMES" <[email-masked]>, Sumandra Majee <[email-masked]>, 
"Stewart Bryant" <[email-masked]>, Xuxiaohu 
<[email-masked]>, Ron Parker <[email-masked]>, Dave 
Dolson <[email-masked]>, "Dolganow, Andrew (Nokia - SG)" 
<[email-masked]>, "Bottorff, Paul" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
日期:   2016/03/22 00:46
主题:   Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Don, 

It's always great to hear opinions but they should be considered in the 
context of the architecture we agreed on shortly after working group 
formation.  NSH does not provide _network_ forwarding information and to 
label it (no pun intended) as such is not only misleading but conveys an 
architectural misunderstanding.  The NSH path-ID is simply an identifier 
for the service path.  Nothing more.  Using that indirection, NSH provides 
several keys benefits at the _service plane_, most notably (but not 
exclusively) the ability to avoid per-hop reclassification and the ability 
to be transport independent.  Both of those attributes haven proven 
themselves as implementations have evolved.

So, to your point, NSH only identities the service path and the network 
transport (MPLS, IP, VXLAN, etc.) provide the forwarding. 

Paul

On Mar 18, 2016, at 11:44 AM, Fedyk, Don <[email-masked]> wrote:

The fact that the work group is not officially chartered to cover 
forwarding methods has caused forwarding aspects to creep in other headers 
like NSH in my opinion. I think only by drafting out a set of forwarding 
technologies with NSH (or other similar headers) in toe can you get a 
sense of what belongs where.  We analyzed this aspect in our draft on MAC 
chaining. We believe IP tunnels, MPLS or segment routing would be have 
similarities with respect to NSH.  I think we will have a variety of 
forwarding technologies in various environments.
 
Cheers
Don

From: sfc [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
Sent: Friday, March 18, 2016 9:22 AM
To: Sumandra Majee <[email-masked]>; Stewart Bryant <
[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <
[email-masked]>; Dave Dolson <[email-masked]>; 
Dolganow, Andrew (Nokia - SG) <[email-masked]>; Bottorff, Paul 
<[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
The use of MPLS labels would facilitate SDN control of service chains. We 
could use anything but VLAN stitching etc.. is not scalable or realistic 
to operate in a large network composed of many smaller data centers. I 
guess where I get hung up in this discussion is why overload the NSH 
header object with both path info and metadata? Is there a notion that 
they are intrinsically tied together if so, could folks provide an 
example? That would be helpful.
 
Thanks,
                Jim Uttaro
 
To: UTTARO, JAMES <[email-masked]>; Stewart Bryant <
[email-masked]>; Xuxiaohu <[email-masked]>; Ron Parker <
[email-masked]>; Dave Dolson <[email-masked]>; 

Sumandra
 
From: sfc <[email-masked]> on behalf of "UTTARO, JAMES" <
[email-masked]>
Date: Thursday, March 17, 2016 at 8:54 AM
To: Stewart Bryant <[email-masked]>, Xuxiaohu <
[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]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
So, if I wanted to form simple service chains i.e nailed up, not 
self-modulating etc…how much meta data would I need?
 
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: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 11:31 AM
To: UTTARO, JAMES <[email-masked]>; Xuxiaohu <[email-masked]>; Ron 
Parker <[email-masked]>; Dave Dolson <
[email-masked]>; Dolganow, Andrew (Nokia - SG) <
[email-masked]>; EXT Bottorff, Paul <[email-masked]>; 
[email-masked]
Cc: [email-masked]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Stewart
 
                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
 
To: Ron Parker <[email-masked]>; UTTARO, JAMES 
(Nokia - SG)<[email-masked]>; EXT Bottorff, Paul 
 
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]
Cc: [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]>; Dave Dolson <
[email-masked]>; Xuxiaohu <[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
 
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]>; Xuxiaohu <[email-masked]>; 
UTTARO, JAMES <[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
 
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]>; UTTARO, JAMES <[email-masked]>; 
Dolganow, Andrew (Nokia - SG) <[email-masked]>; EXT Bottorff, 
Paul <[email-masked]>; Ron Parker <[email-masked]
>; Stewart Bryant <[email-masked]>; [email-masked]
Cc: [email-masked]
 
Recall that draft-homma-sfc-forwarding-methods-analysis compares the 
different approaches.
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-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]
Cc: [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]
Cc: [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 <[email-masked]>; Ron Parker <
[email-masked]>; Stewart Bryant <[email-masked]
>; [email-masked]
Cc: [email-masked]

 
Andrew

 
Cheers,

Paul

 
   Ron

- Stewart

Thanks. 

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Mar 2016 12:34:11 +0000

Jim

I worry that you are de-facto constructing a new network layer rather 
than picking one
of the existing network layers and tunnelling over the the others.

So long as the transition note and the service node knows what is 
happening picking
a default network layer will work.

Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 22 Mar 2016 13:54:22 +0000

> On Mar 21, 2016, at 9:56 PM, Xuxiaohu <[email-masked]> wrote:
> 
> 
> 

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.

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 22 Mar 2016 13:58:53 +0000

> On Mar 21, 2016, at 10:03 PM, Xuxiaohu <[email-masked]> wrote:
> 
> 
> 
> By implementing a service plane (i.e., an SFC encapsulation header) in the form of an MPLS label stack, you are allowed to deploy services in the MPLS and non-MPLS networks as well.

Just trying to understand…

Which non-MPLS networks understand MPLS label stacks?

> In addition, it allows the non-MPLS network hosts one or more services. In other words, the SFC encapsulation header which is implemented in the form of an MPLS label stack is transport-independent.
> 

Still trying to understand… how’s a label stack (where pop operations happen) transport independent?

Thanks,

— Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 22 Mar 2016 12:41:00 -0400

Carlos,

We’ve been doing MPLS-header-enabled services carried over non-MPLS
networks (for example, IP-only) for years and years now. For example,
here’s a talk from NANOG 30 (in 2004!) that talks about how to offer MPLS
VPN services between PEs that are interconnected by an IP-only network.

https://www.nanog.org/meetings/nanog30/presentations/townsley.pdf

Also see RFC 4023.

This, of course, could be used for SFC as well. It would just be another
MPLS-header-enabled service.

Cheers,
Andy

> By implementing a service plane (i.e., an SFC encapsulation header) in
> the form of an MPLS label stack, you are allowed to deploy services in the
> MPLS and non-MPLS networks as well.
>
> > In addition, it allows the non-MPLS network hosts one or more services.
> In other words, the SFC encapsulation header which is implemented in the
> form of an MPLS label stack is transport-independent.
>

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 22 Mar 2016 16:41:37 +0000

Hi Carlos:

An MPLS label stack can be just as opaque to an NVO3 transport as NSH as long as the MPLS stack is inside the encapsulation. This is also the case for MAC chaining where the chaining MACs are within the NVO3 encapsulation.

Cheers,

Paul

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

>> To: Xuxiaohu; Joel M. Halpern; Ron Parker; UTTARO, JAMES; Dave 
>> Dolson; Dolganow, Andrew (Nokia - SG); EXT Bottorff, Paul; Stewart 
>>>> Phrased differently, SFC has to work over networks that use MPLS, 
>>>> and over  networks that do not use MPLS.
>>> 
>> And what do you do if the non-MPLS network actually hosts one or more 
>> of the services? By implementing a service plane (aka. NSH) you get 
>> the best of both worlds; you can deploy services in the MPLS and 
>> non-MPLS parts of the network using the same encapsulation and rely 
>> upon the underlying transport (MPLS or

Thanks,

— Carlos.

> Best regards,
> Xiaohu
> 
>> Jim
>> 
>>> 
>>>> The working group considered alternatives, and is currently using 
>>>> the NSH  header as the mechanism to carry path identification and 
>>>> metadata.
>>>> 
>>>> from  metadata, and use some other mechanism that a single 
>>>> domain-wide id for the  path.  But there are complications and 
>>>> costs associated with doing so.
>>>> It is a
>>>> trade-off.
>>> 
>>> label stack, SFFs could be built on the existing MPLS switches. In 
>>> this way, there is no need of introducing a new forwarding paradigm.
>>> 
>>> Best regards,
>>> Xiaohu
>>> 
>>>> Yours,
>>>> Joel
>>>> 
>>>> different  uses of the term "transport".  But I do not have a 
>>>> better word handy.
>>>> 
>>>>> received this message in error, please notify the sender and 
>>>>> delete this message immediately from your computer. Any other use, 
>>>>> labels with each
>>>>> encapsulations if the SFC encapsulation is implemented in the form of an MPLS label stack.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Xiaohu
>>>>> 
>>>>> received this message in error, please notify the sender and 
>>>>> delete this message immediately from your computer. Any other use, 
>>>>> -

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 22 Mar 2016 16:52:05 +0000

Hi Andy,

Thanks for the response.

Yes, of course — I co-authored RFC 4817 [1] as well, which is another variant of RFC 4023 MPLS-over-IP_something. RFC 4817 (or the I-D that because that RFC) is also used in the NANOG 30 presentation you point to.

The question still stands, however. There’s a difference between “services in a non-MPLS network” versus “services over a non-MPLS network”. The text below says “in”, not “through”. How can a node processing an MPLS LSE be non-MPLS-enabled?

The second question is also, if a service is part of a label stack, are there parts of the stack (i.e., LSEs) that are transport, for a non-MPLS network?

In any case, to be honest, I think this discussion largely became outside the scope of this mailing list. Feel free to reply moving to MPLS or other list within scope.

Thanks,

— Carlos.

[1] http://tools.ietf.org/html/rfc4817

> On Mar 22, 2016, at 12:41 PM, Andrew G. Malis <[email-masked]> wrote:
> 
> Carlos,
> 
> We’ve been doing MPLS-header-enabled services carried over non-MPLS networks (for example, IP-only) for years and years now. For example, here’s a talk from NANOG 30 (in 2004!) that talks about how to offer MPLS VPN services between PEs that are interconnected by an IP-only network.
> 
> https://www.nanog.org/meetings/nanog30/presentations/townsley.pdf <https://www.nanog.org/meetings/nanog30/presentations/townsley.pdf>
> 
> Also see RFC 4023.
> 
> This, of course, could be used for SFC as well. It would just be another MPLS-header-enabled service.
> 
> Cheers,
> Andy
>

---

From: "Bottorff, Paul" <[email-masked]>
Date: Tue, 22 Mar 2016 17:58:09 +0000

Hi Ting:

As you point out in https://tools.ietf.org/html/draft-ao-sfc-overlay-00.txt  the IP Destination (and IP Source addresses) of the service frame does not address the SFs or SFFs of interest nor direct the frame property through the chain. In your draft you describe a NAT mechanism using meta-data to restore the original IP addresses at the end of the chain.

Though this method may work in many cases there may be some SFs which use the DIP for part of their processing, therefore it seems preferable to consider methods which don’t require NATing addresses.

An observation we made in building MAC Chaining https://datatracker.ietf.org/doc/draft-fedyk-sfc-mac-chain/ was the chain represents a peer dialog which is below the end-to-end IP forwarding and therefore is an L2 something peer dialog. In addition, we observe MAC addresses are mostly free in the overlay architectures and therefore can be manipulated to hop between the SFs and SFFs without losing any information in the original service frame (i.e. DIP).

MPLS implementations also seem reasonable for the same reasons, though we prefer MACs simply because they are compatible with almost every datacenter server and switch.

Cheers,

Paul

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 22, 2016 2:21 AM
To: Paul Quinn (paulq) <[email-masked]>
Cc: Dolganow, Andrew (Nokia - SG) <[email-masked]>; Dave Dolson <[email-masked]>; Fedyk, Don <[email-masked]>; UTTARO, JAMES <[email-masked]>; Bottorff, Paul <[email-masked]>; Ron Parker <[email-masked]>; Sumandra Majee <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>; Xuxiaohu <[email-masked]>
Subject: Re: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Hi Paul，

I agree that the NSH should only be the SFC path identifier which is used for forwarding alone the SFC path. But SFF as a forwarder should give some network forwarding information to the network device. One exmaple is described in https://tools.ietf.org/html/draft-ao-sfc-overlay-00.txt, in which SFF is required to carry network forwarding information when it forwards packets to network edge device, so that network device can provide correct network transport.

Ting.

发件人:         "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
收件人:         "Fedyk, Don" <[email-masked]<mailto:[email-masked]>>,
抄送:        "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, Sumandra Majee <[email-masked]<mailto:[email-masked]>>, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "Dolganow, Andrew (Nokia - SG)" <[email-masked]<mailto:[email-masked]>>, "Bottorff, Paul" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
日期:         2016/03/22 00:46
主题:        Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
________________________________

Don,

Paul

Cheers
Don

Thanks,
                Jim Uttaro

Sumandra

Jim Uttaro

Stewart

Jim Uttaro

Ron,

Best regards,
Xiaohu

James,

   Ron

Comments In-Line

Jim Uttaro

   Ron

-Dave

Best regards,
Xiaohu

Jim Uttaro

Andrew

Cheers,

Paul

   Ron

- Stewart

Thanks.

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 23 Mar 2016 01:59:00 +0000

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

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 ...
> >>>
> >>>>> In the above cases MPLS is the instruction, and IP and Ethernet
> >>>>> are the point to point transports.
> >>>>>
> >>>>>> 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.
> >>>>>> assumption that using MPLS labels imposes an MPLS control plane.
> >>>>>> Is that right?/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> */Jim Uttaro/*
> >>>>>>
> >>>>>> *//*
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>> <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
> >>>>>>
> >>>>>> type of NSH
> >>>>>> 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
> >>>>>> type of NSH
> >>>>>> type of NSH
> >>>>>> security considerations (by adding large headers it will be
> >>>>>> harder to perform payload based ACL DDoS protection in routers for
> example).
> >>>>>>
> >>>>>> Andrew
> >>>>>>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 23 Mar 2016 02:15:49 +0000

Hi Carlos,

The SFC WG charter said clearly that “…The WG will examine existing identifier schemes,
  if there is a need for such identifiers in the context of the Generic SFC
  encapsulation, before defining any new identifier scheme.”

Hence, before jumping into defining any new identifier scheme (and corresponding new forwarding paradigm),  shouldn’t we calm down and carefully examine whether the SFP identification can be implemented by using any existing identifier scheme. In this way, we can avoid reinventing a new forwarding paradigm which may be found unnecessary later.

Best regards,
Xiaohu

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, March 23, 2016 12:52 AM
To: Andrew G. Malis
Cc: Xuxiaohu; Dolganow, Andrew (Nokia - SG); [email-masked]; EXT Bottorff, Paul; Jim Guichard (jguichar); Ron Parker; [email-masked]; Stewart Bryant; Joel M. Halpern; UTTARO, JAMES; Dave Dolson
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH

Hi Andy,

Thanks for the response.

Thanks,

— Carlos.

On Mar 22, 2016, at 12:41 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Also see RFC 4023.

Cheers,
Andy

Thanks,

— Carlos.