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

[[e-mail]]

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)" <[e-mail]>
ÊÕ¼þÈË:         "Fedyk, Don" <[e-mail]>, 
³­ËÍ:   "UTTARO, JAMES" <[e-mail]>, Sumandra Majee <[e-mail]>, 
"Stewart Bryant" <[e-mail]>, Xuxiaohu 
<[e-mail]>, Ron Parker <[e-mail]>, Dave 
Dolson <[e-mail]>, "Dolganow, Andrew (Nokia - SG)" 
<[e-mail]>, "Bottorff, Paul" <[e-mail]>, 
"[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
ÈÕÆÚ:   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 <[e-mail]> 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:[e-mail]] On Behalf Of UTTARO, JAMES
Sent: Friday, March 18, 2016 9:22 AM
To: Sumandra Majee <[e-mail]>; Stewart Bryant <
[e-mail]>; Xuxiaohu <[e-mail]>; Ron Parker <
[e-mail]>; Dave Dolson <[e-mail]>; 
Dolganow, Andrew (Nokia - SG) <[e-mail]>; Bottorff, Paul 
<[e-mail]>; [e-mail]
Cc: [e-mail]
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
 
"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:[e-mail]] 
Sent: Thursday, March 17, 2016 5:10 PM
To: UTTARO, JAMES <[e-mail]>; Stewart Bryant <
[e-mail]>; Xuxiaohu <[e-mail]>; Ron Parker <
[e-mail]>; Dave Dolson <[e-mail]>; 
Dolganow, Andrew (Nokia - SG) <[e-mail]>; EXT Bottorff, 
Paul <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
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 <[e-mail]> on behalf of "UTTARO, JAMES" <
[e-mail]>
Date: Thursday, March 17, 2016 at 8:54 AM
To: Stewart Bryant <[e-mail]>, Xuxiaohu <
[e-mail]>, Ron Parker <[e-mail]>, Dave 
Dolson <[e-mail]>, "Dolganow, Andrew (Nokia - SG)" <
[e-mail]>, "EXT Bottorff, Paul" <[e-mail]>, 
"[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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:[e-mail]] 
Sent: Thursday, March 17, 2016 11:31 AM
To: UTTARO, JAMES <[e-mail]>; Xuxiaohu <[e-mail]>; Ron 
Parker <[e-mail]>; Dave Dolson <
[e-mail]>; Dolganow, Andrew (Nokia - SG) <
[e-mail]>; EXT Bottorff, Paul <[e-mail]>; 
[e-mail]
Cc: [e-mail]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
Yes, the MPLS label should be seen as an instruction - which is
exactly what it is, and always has been.

You can trivially carry MPLS over IP.

We do carry MPLS over Ethernet.

In the above cases MPLS is the instruction, and IP and 
Ethernet are the point to point transports.

What is more interesting is how we carry the metadata,
since there may need to be several instances of the
metadata in the packet.

Stewart
On 17/03/2016 12:30, UTTARO, JAMES wrote:
Ron,
 
                Have not been following the SFC WG that closely due to 
other more pressing needs for my network. That being said, it would seem 
that an MPLS label could be used as the basis for what you are looking for 
an thus could be applied to all network types. Using the MPLS label format 
does not force you to have an MPLS enabled network all that is needed is 
the required info to be populated in the label. It seems that the argument 
is for independence of network thus inventing a new label is based on an 
assumption that using MPLS labels imposes an MPLS control plane. Is that 
right?
 
Jim Uttaro
 
"This email and any files transmitted with it are AT&T property, are 
confidential, and are intended solely for the use of the individual or 
entity to whom this email is addressed. If you are not one of the named 
recipient(s) or otherwise have reason to believe that you have received 
this message in error, please notify the sender and delete this message 
immediately from your computer. Any other use, retention, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited."
From: Xuxiaohu [mailto:[e-mail]] 
Sent: Thursday, March 17, 2016 3:47 AM
To: Ron Parker <[e-mail]>; UTTARO, JAMES 
<[e-mail]>; Dave Dolson <[e-mail]>; Dolganow, Andrew 
(Nokia - SG)<[e-mail]>; EXT Bottorff, Paul 
<[e-mail]>; Stewart Bryant <[e-mail]>; 
[e-mail]
Cc: [e-mail]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
Ron,
 
The SFC approach of encoding the SFP information by an MPLS label stack 
can meet the transport-independency requirement very well.
 
Best regards,
Xiaohu
 
From: Ron Parker [mailto:[e-mail]] 
Sent: Wednesday, March 16, 2016 11:20 PM
To: UTTARO, JAMES; Dave Dolson; Xuxiaohu; Dolganow, Andrew (Nokia - SG); 
EXT Bottorff, Paul; Stewart Bryant; [e-mail]
Cc: [e-mail]
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:[e-mail]] 
Sent: Wednesday, March 16, 2016 11:11 AM
To: Ron Parker <[e-mail]>; Dave Dolson <
[e-mail]>; Xuxiaohu <[e-mail]>; Dolganow, Andrew 
(Nokia - SG) <[e-mail]>; EXT Bottorff, Paul <
[e-mail]>; Stewart Bryant <[e-mail]>; 
[e-mail]
Cc: [e-mail]
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:[e-mail]] 
Sent: Wednesday, March 16, 2016 10:01 AM
To: Dave Dolson <[e-mail]>; Xuxiaohu <[e-mail]>; 
UTTARO, JAMES <[e-mail]>; Dolganow, Andrew (Nokia - SG) <
[e-mail]>; EXT Bottorff, Paul <[e-mail]>; 
Stewart Bryant <[e-mail]>; [e-mail]
Cc: [e-mail]
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 ¨C 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:[e-mail]] 
Sent: Wednesday, March 16, 2016 9:48 AM
To: Xuxiaohu <[e-mail]>; UTTARO, JAMES <[e-mail]>; 
Dolganow, Andrew (Nokia - SG) <[e-mail]>; EXT Bottorff, 
Paul <[e-mail]>; Ron Parker <[e-mail]
>; Stewart Bryant <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
Recall that draft-homma-sfc-forwarding-methods-analysis compares the 
different approaches.
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-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:[e-mail]] 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; [e-mail]
Cc: [e-mail]
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:[e-mail]] 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; [e-mail]
Cc: [e-mail]
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:[e-mail]] On Behalf Of Dolganow, Andrew 
(Nokia - SG)
Sent: Monday, March 14, 2016 11:52 PM
To: EXT Bottorff, Paul <[e-mail]>; Ron Parker <
[e-mail]>; Stewart Bryant <[e-mail]
>; [e-mail]
Cc: [e-mail]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
Following ¡°next header¡± approach  is simple and the NSH header is 
already built like that. Introducing MPLS like approach would add yet 
another mechanism to traverse the headers, which would make h/w more 
complex.
 
It is true that h/w can only look at X Bytes (X depending on h/w). This is 
true for many headers not only this and even today (without NSH) you can 
end-up with payload being very deep in a packet. At the end we need to 
have a flexible mechanism which NSH nesting would provide. If someone ¡°
abuses it¡± this can lead to various issues. It is probably worth noting 
that in the draft including security considerations (by adding large 
headers it will be harder to perform payload based ACL DDoS protection in 
routers for example).
 
Andrew
 
On 2016-03-15, 3:03 AM, "sfc on behalf of EXT Bottorff, Paul" wrote:
 
Just one more concern about the stack is how deep it will nest. Hardware 
switch implementations are typically limited in the depth they look into 
the packet. If the hardware needs to look at the original packet headers, 
then hardware would need to skip over the stack of NSH headers to reach 
the original packet. If the NSH stack is too deep it may exceed the 
hardware depth limits.
 
Cheers,

Paul
 
From: sfc [mailto:[e-mail]] On Behalf Of Ron Parker
Sent: Monday, March 14, 2016 11:45 AM
To: Stewart Bryant <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH
 
I like the self describing stack of NSH headers and I like the first one 
being the ¡°current¡± scoping.   But, one difference between MPLS and NSH
¡­   MPLS forwarding is generally handled by looking only at the MPLS 
labels that are ¡°in scope¡± for the current node (i.e., starting at the 
top-of-stack) and not needing to locate and process the ¡°payload¡± beyond 
the bottom-of-stack.    But, in NSH, most processing will require location 
of the ¡°payload¡± beyond the last NSH header.   It is inefficient to have 
to walk the stack of NSH headers in order to locate that payload.    If 
each NSH header that was pushed onto the stack also included an offset to 
directly locate the payload (each new one simply adds its own byte size), 
then this processing inefficiency would be mitigated.
 
   Ron
 
 
From: sfc [mailto:[e-mail]] On Behalf Of Stewart Bryant
Sent: Monday, March 14, 2016 5:40 AM
To: [e-mail]
Cc: [e-mail]
Subject: [GRAYMAIL] Re: [sfc] Adding an NSH.next-header type of NSH
 

Having reminded myself of the NSH header structure, I see that this
is not strictly needed since this naturally fits with the next
protocol component of the base header. Thus stating that the there
is no architectural limit on the number of SFH headers in a packet
is the necessary and sufficient requirement to allow an arbitatry
stack of NSH headers. Stating that new NSH headers are added at the front
of the packet, and processed first and discarded first is sufficient
to remove any processing ambiguity. Processing would also be simpler
is you followed the MPLS rule that the outer header is the only one
in scope until that header is discarded (popped).

I do however wonder whether the IETF's architetural preference for
self describing packets (MPLS being the exception) leads us to more
complex and thus less efficent dataplane designs than we could otherwise 
achieve.

- Stewart
On 14/03/2016 01:44, [e-mail] 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 <[e-mail]>
ÊÕ¼þÈË:         "[e-mail]"<[e-mail]>, 
ÈÕÆÚ:         2016/03/11 17:25
Ö÷Ìâ:        Re: [sfc] Adding an NSH.next-header type of NSH
·¢¼þÈË:        "sfc" <[e-mail]>





The protocol that chose the most elegant approach to layering
one header on another was MPLS, with its stacking approach
and one bit end of stack indicator.

Such a simple general approach has much to commend it
and you might think seriously about applying it here.

Stewart

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