Subject: Re: [sfc] Responses to NSH open tickets

From: "Elzur, Uri" <[email-masked]>
Date: Fri, 1 Jan 2016 18:20:26 +0000

Few additional comments
Sorry for the delay
>> Ticket #4: Reuse the IPFIX registry for identifying context types
[UE] Can you pls provide examples of using the IPFIX format, that are contained in a reasonable size (to me that means few bytes).

Ticket #5: Support of SF Spirals
[UE] text in Service Index (SI) paragraph already provides that explanation

Ticket #6: Version Handling
[UE] version handling should be left to a future version of the draft when NSH moves beyond this very first version. It will be confusing to have text about version handling where only one version is available

Ticket #9: Remove Section 2.2
[UE] it is a question of style. We think the text is useful

Ticket #10: O bit
[UE] at this point in the development of SFC the data plane is ahead of the Control plane and work going on in the IETF on handling OAM in general. Stabilized/standardized Data plane is essential for those who develop Silicon and/or write code, so NSH draft offers the minimal support so that later more functionality will be added, and anyhow it is expected that will be in software in the lion share of cases. If removed, it will be harder to add after SFC is deployed

We are working on the other items too

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----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]
Subject: Re: [sfc] Responses to NSH open tickets

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]<mailto:[email-masked]> Objet
> : [sfc] Responses to NSH open tickets
>
> 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.
>

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

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

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

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

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

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

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

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

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

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

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

>
> 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.
>
>
[Med] OK, thanks.

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

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

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

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

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

[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]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Jan 2016 14:56:35 -0500

Actually, on version numbers we do need to say a little more.  We need 
to state here what an NSH implementation should do if it receives a 
packet with a version number it does not understand.
It seems to me that the obvious handling is that it should drop such 
packets.  We just need to say so.

Yours,
Joel

On 1/1/16 1:20 PM, Elzur, Uri wrote:
> [UE] Can you pls provide examples of using the IPFIX format, that are
> contained in a reasonable size (to me that means few bytes).
> [UE] version handling should be left to a future version of the draft
> when NSH moves beyond this very first version. It will be confusing to
> have text about version handling where only one version is available
> [UE] at this point in the development of SFC the data plane is ahead of
> the Control plane and work going on in the IETF on handling OAM in
> general. Stabilized/standardized Data plane is essential for those who
> develop Silicon and/or write code, so NSH draft offers the minimal
> support so that later more functionality will be added, and anyhow it is
> expected that will be in software in the lion share of cases. If
> removed, it will be harder to add after SFC is deployed
> Uri (“Oo-Ree”)
>> (paulq) Envoyé : vendredi 6 novembre 2015 17:05 À :[email-masked] <mailto:[email-masked]> Objet
> [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:
> [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.
> [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.
>>
> [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":
> ==
>> Reply: This was answered on the list:http://www.ietf.org/mail-
> [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-
> [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.
>>
>> Ticket #7: reserved bits
> [Med] IMHO, a pointer to RFC7498 would be enough ; no need to reproduce
> here what was already covered in section 2 of RFC7498.
>> Ticket #10: O bit
> [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".
> ===
> 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".
>> ---------------
>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "Elzur, Uri" <[email-masked]>
Date: Sat, 2 Jan 2016 01:08:20 +0000

Can be added, anticipating some future version. Not a biggy

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, January 1, 2016 11:57 AM
To: Elzur, Uri; [email-masked]; Paul Quinn (paulq); [email-masked]
Subject: Re: [sfc] Responses to NSH open tickets

Actually, on version numbers we do need to say a little more.  We need to state here what an NSH implementation should do if it receives a packet with a version number it does not understand.
It seems to me that the obvious handling is that it should drop such packets.  We just need to say so.

Yours,
Joel

On 1/1/16 1:20 PM, Elzur, Uri wrote:
> [UE] text in Service Index (SI) paragraph already provides that 
> explanation Ticket #6: Version Handling [UE] version handling should 
> be left to a future version of the draft when NSH moves beyond this 
> very first version. It will be confusing to have text about version 
> handling where only one version is available Ticket #9: Remove Section 
> 2.2 [UE] it is a question of style. We think the text is useful Ticket 
> #10: O bit [UE] at this point in the development of SFC the data plane 
> is ahead of the Control plane and work going on in the IETF on 
> handling OAM in general. Stabilized/standardized Data plane is 
> essential for those who develop Silicon and/or write code, so NSH 
> draft offers the minimal support so that later more functionality will 
> be added, and anyhow it is expected that will be in software in the 
> lion share of cases. If removed, it will be harder to add after SFC is 
> deployed We are working on the other items too Thx Uri ("Oo-Ree")
> C: 949-378-7568
> Subject: Re: [sfc] Responses to NSH open tickets Hi Paul, Please see 
> inline.
> Cheers,
> Med
>> I do not plan to update the draft, given that there is no WG 
>> consensus for any changes.
>>
> 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.
>>
>> optimal to reuse as there are many unneeded things. Consensus seems 
>> to want to prioritize precision over blind reuse.  I do not plan to 
> [Med] Adding some text to clarify spiral is supported would be 
> helpful, IMO. This is much better than looking in an email thread.
>> 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.
>>
>> Ticket #7: reserved bits
>> Reply: The current version of the draft states:  "A short reference 
>> is included below, RFC 7498 [RFC7498], provides a more comprehensive 
> [Med] IMHO, a pointer to RFC7498 would be enough ; no need to 
> reproduce here what was already covered in section 2 of RFC7498.
>> Ticket #10: O bit
> 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".
> ===

---

From: <[email-masked]>
Date: Thu, 21 Jan 2016 13:00:53 +0000

Hi Uri,

Please see inline.

Cheers,
Med

De : Elzur, Uri [mailto:[email-masked]]
Envoyé : vendredi 1 janvier 2016 19:20
À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq); [email-masked]
Objet : RE: Responses to NSH open tickets

Few additional comments
Sorry for the delay
[UE] Can you pls provide examples of using the IPFIX format, that are contained in a reasonable size (to me that means few bytes).
[Med] The proposal is not about reusing the IPFIX format, but IPFIX registry. The TLV format as described in the nsh draft will be used. With the approach I'm proposing here:

·         if you need to include a FlowID, you just need to set the registry ID to 1, and the type to 14.

·         If you need to include a vlandID, you just need to set the registry ID to 1, and the type to 58.

·         ..

The advantage of this approach is that you don't need to for IANA to assign a code point. You just make you shop form the existing (rich) registry. Other Registries can be defined in the specification, if needed.

Ticket #6: Version Handling
[UE] version handling should be left to a future version of the draft when NSH moves beyond this very first version. It will be confusing to have text about version handling where only one version is available
[Med] Future versions may be defined in the future, so including a behavior to manage distinct version will help for better interoperability.

Ticket #10: O bit

[Med] The issue is not giving a name to a flag but about the behavior associated with it. What's an implementer has to do for making use of the O bit is not defined in the nsh draft. The draft says: "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).".

What is this "appropriate action"? The draft does not specify it.

[Med] Ok, thank you.

Thx

Uri ("Oo-Ree")
C: 949-378-7568

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

Hi Paul,

Please see inline.

Cheers,
Med

==

[Med] OK, thanks.

===