Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

From: Xuxiaohu <[email-masked]>
Date: Mon, 2 Mar 2015 01:24:10 +0000

Hi Myo,

Thanks for your response. It's great that the NSH is allowed to contain only the metadata by ignoring the service path header (e.g., set the SPID to zero). That's what I had expected. Thanks again for your explanation.

Best regards,
Xiaohu

From: Zarny, Myo [mailto:[email-masked]]
Sent: Saturday, February 28, 2015 10:42 PM
To: Xuxiaohu; 'Jim Guichard (jguichar)'; [email-masked]'
Subject: RE: WG call for adoption of draft-quinn-sfc-nsh

Hi Xiaohu,

Currently, the draft certainly supports two of your three scenarios: (1) SFC path only and (3) SFC path info and metadata.

As for the scenario of carrying just the metadata, can you clarify your ask? I take that you're not mandating that the base header not contain a service path header; but rather that the NSH be used to carry just the metadata only, correct? If it's the latter, the NSH does support your scenario. Yes, the Service Path Header is a required component of the header. But you can choose an implementation method to ignore the SP header values (SPID and SPI). (Implementation methods could range from zeroing the fields out to instructing NSH-aware devices to ignore them; etc.) If that meets your expectations, then, the header supports all three scenarios.

Now, to be precise and for full disclosure, all three scenarios are supported through MD-Type 2, which the draft currently recommends as a "SHOULD" implementation [Section 3.2].

Myo

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: 28 February 2015 4:52 AM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Support.

By the way, I hope the NSH could be capable of: 1) containing the service chain/path info only; 2) containing the metadata only ;3) containing both service chain/path info and the metadata. Otherwise, we may need to design a separate header for containing the metadata in the case where the service chain/path info has been embodied by other means than the NSH itself. In this way, it's aligned with the following statement in the SFC architecture draft:

"4.3.1<https://tools.ietf.org/html/draft-ietf-sfc-architecture-04#section-4.3.1>.  Transport Derived SFF

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

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

"

Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 26, 2015 8:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that the WG can focus on a single encapsulation document going forward. This new version of NSH includes an open items section based on discussion between co-authors and members of the list. The WG will work through this list (and any other issues that need to be added) over the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 weeks ending 3/12/2015.

Please note that this is a call for adoption, and not a last call for content of the document. Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issues you have with the current document itself can also be raised, but they should be raised in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Jim & Thomas

---

From: <[email-masked]>
Date: Mon, 2 Mar 2015 16:42:18 +0100

Hi,

support.

  Regards

     Nic

Von: sfc [mailto:[email-masked]] Im Auftrag von Jim Guichard (jguichar)
Gesendet: Donnerstag, 26. Februar 2015 13:47
An: [email-masked]
Betreff: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

Jim & Thomas

---

From: "Weixinpeng (Jackie)" <[email-masked]>
Date: Mon, 9 Mar 2015 03:58:31 +0000

Hi,
It is would be great to have merged document to speed up the process of SFC Header definition, and I agree that the WG use the joint document as the
basis for further work. But for the document, there are some of my comments.

1. As said in the document, 'C' bit is defined in NSH base header as an indication for the existence of critical metadata. But I don't think this bit is necessary: from my perspective, when receiving a
NSH encapsulated packet, the service function checks all the metadata to get what it needs, and it can learn about whether the metadata is critical from 'C' bit within
the TLV Type field. No matter whether a critical metadata exists, the service function will check all the metadata.
2. The document defines "MD-Type=0x01", which contains metadata in NSH, as mandatory and "MD-Type=0x02", which means metadata in NSH is optional, as optional. What I think is that metadata in
NSH should be optional, because metadata is not used in every case.
3. The draft defines a new list of "Next Protocol" values, such as 0x1 for IPv4, 0x2 for IPv6, 0x3 for Ethernet. But I think it's better to use the Protocol Number values that have been defined by IETF for consistence and no need to define
a list of new ones.

Regards,
-Xinpeng

To: [email-masked]

Greetings WG:

Jim & Thomas