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

["Bottorff, Paul" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, March 22, 2016 2:21 AM
To: Paul Quinn (paulq) <[e-mail]>
Cc: Dolganow, Andrew (Nokia - SG) <[e-mail]>; Dave Dolson <[e-mail]>; Fedyk, Don <[e-mail]>; UTTARO, JAMES <[e-mail]>; Bottorff, Paul <[e-mail]>; Ron Parker <[e-mail]>; Sumandra Majee <[e-mail]>; [e-mail]; Stewart Bryant <[e-mail]>; Xuxiaohu <[e-mail]>
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)" <[e-mail]<mailto:[e-mail]>>
ÊÕ¼þÈË:         "Fedyk, Don" <[e-mail]<mailto:[e-mail]>>,
³­ËÍ:        "UTTARO, JAMES" <[e-mail]<mailto:[e-mail]>>, Sumandra Majee <[e-mail]<mailto:[e-mail]>>, "Stewart Bryant" <[e-mail]<mailto:[e-mail]>>, Xuxiaohu <[e-mail]<mailto:[e-mail]>>, Ron Parker <[e-mail]<mailto:[e-mail]>>, Dave Dolson <[e-mail]<mailto:[e-mail]>>, "Dolganow, Andrew (Nokia - SG)" <[e-mail]<mailto:[e-mail]>>, "Bottorff, Paul" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Xuxiaohu <[e-mail]<mailto:[e-mail]>>; Ron Parker <[e-mail]<mailto:[e-mail]>>; Dave Dolson <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Xuxiaohu <[e-mail]<mailto:[e-mail]>>; Ron Parker <[e-mail]<mailto:[e-mail]>>; Dave Dolson <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; EXT Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of "UTTARO, JAMES" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 17, 2016 at 8:54 AM
To: Stewart Bryant <[e-mail]<mailto:[e-mail]>>, Xuxiaohu <[e-mail]<mailto:[e-mail]>>, Ron Parker <[e-mail]<mailto:[e-mail]>>, Dave Dolson <[e-mail]<mailto:[e-mail]>>, "Dolganow, Andrew (Nokia - SG)" <[e-mail]<mailto:[e-mail]>>, "EXT Bottorff, Paul" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>; Xuxiaohu <[e-mail]<mailto:[e-mail]>>; Ron Parker <[e-mail]<mailto:[e-mail]>>; Dave Dolson <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; EXT Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]><mailto:[e-mail]>; UTTARO, JAMES <[e-mail]><mailto:[e-mail]>; Dave Dolson <[e-mail]><mailto:[e-mail]>; Dolganow, Andrew (Nokia - SG)<[e-mail]><mailto:[e-mail]>; EXT Bottorff, Paul <[e-mail]><mailto:[e-mail]>; Stewart Bryant <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; Dave Dolson <[e-mail]<mailto:[e-mail]>>; Xuxiaohu <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; EXT Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; Xuxiaohu <[e-mail]<mailto:[e-mail]>>; UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; EXT Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; UTTARO, JAMES <[e-mail]<mailto:[e-mail]>>; Dolganow, Andrew (Nokia - SG) <[e-mail]<mailto:[e-mail]>>; EXT Bottorff, Paul <[e-mail]<mailto:[e-mail]>>; Ron Parker <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; Ron Parker <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[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]><mailto:[e-mail]>
ÊÕ¼þÈË:         "[e-mail]"<mailto:[e-mail]><[e-mail]><mailto:[e-mail]>,
ÈÕÆÚ:         2016/03/11 17:25
Ö÷Ìâ:        Re: [sfc] Adding an NSH.next-header type of NSH
·¢¼þÈË:        "sfc" <[e-mail]><mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc


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