Subject: [sfc] Responses to NSH open tickets

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 6 Nov 2015 16:05:26 +0000

Hi,

Below is my analysis and responses to the NSH tracking tickets and my suggested actions/next steps.

Thanks
Paul

------------
Ticket #1: Add a new field to include the SFC Identifier
http://trac.tools.ietf.org/wg/sfc/trac/ticket/1

Reply:
The current NSH draft specifies a pathID, this has proven simple and viable to implement.  Implementation may (and do) utilize that pathID to represent an abstract or specific path.  If further specificty is desired, the NSH metadata may be used to carry other path information.  I do not plan to update the draft, given that there is no WG consensus for any changes.

Ticket #2: Remove "MD Type" field and the companion "MD-type 1"
http://trac.tools.ietf.org/wg/sfc/trac/ticket/2

Reply: Having the ability specify formats for NSH has proven very useful.  This was raised on on list and there was no consensus for change, I recommend this item be marked as resolved in the tracker.

Ticket #3: Critical Metadata
http://trac.tools.ietf.org/wg/sfc/trac/ticket/3

Reply:  it is unclear what suggested action is being requested.  If further clarification of critical metadata in required, text can be added to the draft, subject to WG review.

Ticket #4: Reuse the IPFIX registry for identifying context types
http://trac.tools.ietf.org/wg/sfc/trac/ticket/4

Reply:  The 400+ IPFIX information elements were created for a protocol for IP Flow Information Export, and thus it would not be optimal to reuse
as there are many unneeded things. Consensus seems to want to prioritize precision over blind reuse.  I do not plan to update the draft and suggest that this item be marked as resolved in the tracker.

Ticket #5: Support of SF Spirals
http://trac.tools.ietf.org/wg/sfc/trac/ticket/5

Reply: This was answered on the list: http://www.ietf.org/mail-archive/web/sfc/current/msg03188.html and therefore no changes are needed.  Given that, this item can be marked as resolved.

Ticket #6: Version Handling
https://tools.ietf.org/wg/sfc/trac/ticket/6

Reply: Discussed on list: http://www.ietf.org/mail-archive/web/sfc/current/msg03149.html.  There was no consensus to changed the adopted format, in fact the value of version bits seems well accepted and therefore no changes are needed and the topic should be marked as resolved in the tracker.

Ticket #7: reserved bits
http://trac.tools.ietf.org/wg/sfc/trac/ticket/7

Reply: This text seems like a helpful clarification.  Barring objection, it can be added to the draft.

Ticket #8: 
http://trac.tools.ietf.org/wg/sfc/trac/ticket/8

Reply: NSH and the use case draft seem consistent.  However, it would be helpful for the use case drafts to reference the allocations drafts, and vice versa to provide a consistent view for readers.  

Ticket #9: Remove Section 2.2
http://trac.tools.ietf.org/wg/sfc/trac/ticket/9

Reply: The current version of the draft states:  "A short reference is included below, RFC 7498 [RFC7498], provides a
more comprehensive review of the SFC Problem Statement."  That seems like a reasonable approach, and propose marking this item as resolved.

Ticket #10: O bit
http://trac.tools.ietf.org/wg/sfc/trac/ticket/10

Reply: Reserving a bit for OAM is acceptable, and done in other protocol specifications.  OAM-specific drafts exist and will leverage the presence of the bit.   Further, over time new OAM uses may arise, having the explicit ability to support them day-0 is key. The O bit was agreed upon by the WG during adoption, and there is no consensus to remove it.  I propose that a reference be added to the OAM framework draft.

---------------

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 10:00:21 +0000

Hi Paul,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Paul Quinn (paulq)
> Envoyé : vendredi 6 novembre 2015 17:05
> À : [email-masked]
> Objet : [sfc] Responses to NSH open tickets
> 
> Hi,
> 
> The current NSH draft specifies a pathID, this has proven simple and
> viable to implement.  Implementation may (and do) utilize that pathID to
> represent an abstract or specific path.  If further specificty is desired,
> the NSH metadata may be used to carry other path information.  I do not
> plan to update the draft, given that there is no WG consensus for any
> changes.
> 

[Med] It would be good to add a clarification to the document to be aligned with the discussion we had for the control plane draft. Having this text included is really helpful to increase clarity: 

"The SFP Identifier (SFP-id) is used as a lookup key to
      determine forwarding action regardless of whether the SFC is fully
      constrained, partially constrained, or not constrained at all.
      Additional information such as a flow identifier and/or other
      characteristics (e.g., the 5-tuple transport coordinates of the
      original packet) may be used for lookup purposes.  The set of
      information to use for lookup purposes may be instructed by the
      control plane."

> Reply: Having the ability specify formats for NSH has proven very useful.
> This was raised on on list and there was no consensus for change, I
> recommend this item be marked as resolved in the tracker.
> 
> 

[Med] I'm following that discussion but I still don't get the answer about why mandating 4 context headers. Why not 2, 3, 5, 10, etc.? For me, this one is not resolved.

> Reply:  it is unclear what suggested action is being requested.  If
> further clarification of critical metadata in required, text can be added
> to the draft, subject to WG review.
> 

[Med] the issue is that a metadata cane be critical for a given chain but not for another one. It can be critical for a deployment but not for another one it. Whether a metadata is critical or not should be left to the taste of the operators. My suggestion is to let that flag a configurable parameter and have one single registry instead of two as currently defined. 

> Reply:  The 400+ IPFIX information elements were created for a protocol
> for IP Flow Information Export, and thus it would not be optimal to reuse
> as there are many unneeded things. Consensus seems to want to prioritize
> precision over blind reuse.  I do not plan to update the draft and suggest
> that this item be marked as resolved in the tracker.
> 

[Med] The advantage I see in reusing an existing registry is to avoid waiting for codepoint assignments for NEW metadata needed for a given service deployment. My proposal is to define a dedicated field in the context header "Registry ID":  

==
      Registry ID:  In order to foster service innovation, this field
         allows to inherit from existing code point registries that are
         likely to be useful in a SFC context.  The following value is
         reserved by this specification:
         0:  None.
         1:  IPFIX [IPFIX].
==

Some bits of the current TLV class can be grabbed for the Registry ID. 

> Reply: This was answered on the list: http://www.ietf.org/mail-
> archive/web/sfc/current/msg03188.html and therefore no changes are needed.
> Given that, this item can be marked as resolved.
> 

[Med] Adding some text to clarify spiral is supported would be helpful, IMO. This is much better than looking in an email thread.

> Reply: Discussed on list: http://www.ietf.org/mail-
> archive/web/sfc/current/msg03149.html.  There was no consensus to changed
> the adopted format, in fact the value of version bits seems well accepted
> and therefore no changes are needed and the topic should be marked as
> resolved in the tracker.
> 

[Med] Wouldn't you plan to update the text to describe the behavior when several versions are supported by an SFC-aware node or when it receives a version it does not support? I thought that was part of the points discussed in that thread.

> it can be added to the draft.
[Med] OK, thanks.

> Reply: NSH and the use case draft seem consistent.  However, it would be
> helpful for the use case drafts to reference the allocations drafts, and
> vice versa to provide a consistent view for readers.
> 
> 

[Med] One of the comments is to cite the SFC use cases already adopted by the working group.

> Reply: The current version of the draft states:  "A short reference is
> included below, RFC 7498 [RFC7498], provides a
> more comprehensive review of the SFC Problem Statement."  That seems like
> a reasonable approach, and propose marking this item as resolved.
> 
> 

[Med] IMHO, a pointer to RFC7498 would be enough ; no need to reproduce here what was already covered in section 2 of RFC7498. 

> Reply: Reserving a bit for OAM is acceptable, and done in other protocol
> specifications.  OAM-specific drafts exist and will leverage the presence
> of the bit.   Further, over time new OAM uses may arise, having the
> explicit ability to support them day-0 is key. The O bit was agreed upon
> by the WG during adoption, and there is no consensus to remove it.  I
> propose that a reference be added to the OAM framework draft.
> 

[Med] I do think it is odd to define a bit without specifying the associated behavior. Giving a name to a flag does not mean associate a meaning with that flag. A flag name is not helpful for an implementer if the behavior associated with it is not present in the spec. 

The following text is underspecified as it is not clear what is meant by "MUST examine the payload and take appropriate action". 

===
   O bit: when set to 0x1 indicates that this packet is an operations
   and management (OAM) packet.  The receiving SFF and SFs nodes MUST
   examine the payload and take appropriate action (e.g. return status
   information).

   OAM message specifics and handling details are outside the scope of
   this document.
====

Adding a reference to the OAM framework draft would be OK if the OAM reference is cited as a NORMATIVE one. I don't think this is what you have in mind when you said "a reference be added to the OAM framework draft".

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

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 26 Nov 2015 18:11:00 +0000

Inline.

Surendra.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 26, 2015 2:00 AM
To: Paul Quinn (paulq) <[email-masked]>; [email-masked]
Subject: Re: [sfc] Responses to NSH open tickets

Hi Paul,

Please see inline.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Paul Quinn 
> (paulq) Envoyé : vendredi 6 novembre 2015 17:05 À : [email-masked] Objet 
> : [sfc] Responses to NSH open tickets
> 
> Hi,
> 
> viable to implement.  Implementation may (and do) utilize that pathID 
> to represent an abstract or specific path.  If further specificty is 
> desired, the NSH metadata may be used to carry other path information.  
> I do not plan to update the draft, given that there is no WG consensus 
> for any changes.
> 

SK> It is not SFP-id alone. It is SFP+SI, to be correct, that leads to the forwarding action.

> further clarification of critical metadata in required, text can be 
> added to the draft, subject to WG review.
> 

> Reply:  The 400+ IPFIX information elements were created for a 
> protocol for IP Flow Information Export, and thus it would not be 
> optimal to reuse as there are many unneeded things. Consensus seems to 
> want to prioritize precision over blind reuse.  I do not plan to 
> update the draft and suggest that this item be marked as resolved in the tracker.
> 

==

> archive/web/sfc/current/msg03149.html.  There was no consensus to 
> changed the adopted format, in fact the value of version bits seems 
> well accepted and therefore no changes are needed and the topic should 
> be marked as resolved in the tracker.
> 

[Med] OK, thanks.

> Reply: NSH and the use case draft seem consistent.  However, it would 
> be helpful for the use case drafts to reference the allocations 
> drafts, and vice versa to provide a consistent view for readers.
> 
> 

> included below, RFC 7498 [RFC7498], provides a more comprehensive 
> review of the SFC Problem Statement."  That seems like a reasonable 
> approach, and propose marking this item as resolved.
> 
> 

> Reply: Reserving a bit for OAM is acceptable, and done in other 
> protocol specifications.  OAM-specific drafts exist and will leverage the presence
> explicit ability to support them day-0 is key. The O bit was agreed 
> upon by the WG during adoption, and there is no consensus to remove 
> it.  I propose that a reference be added to the OAM framework draft.
> 

===