Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

From: Shunsuke Homma <[email-masked]>
Date: Tue, 6 Sep 2016 19:50:24 +0900

Hi Jim and editors,

I've read the latest nsh draft, and I have a comment for the section 4.
I think that "Update NSH" would be correct as sub-title of the third 
action in this section because the sentence includes an action related 
with update of context headers. Also, "Update NSH" is used in Figure 8.

Best regards,
Shunsuke

On 2016/08/24 1:48, Jim Guichard (jguichar) wrote:
> Dear WG:
>
> Please review this new version of the SFC encapsulation to make sure that your comments from the previous WGLC have been addressed.
>
> Any comments and/or concerns please post to the mailing list within the next two weeks so that this work can be progressed.
>
> As a heads up, if there are still substantive comments we plan to hold an interim meeting on September 15th to address any outstanding issues
>
>
> Thanks!
>
> Jim, Martin, & Thomas
>
>
>
>
> On 8/23/16, 11:47 AM, "sfc on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Service Function Chaining of the IETF.
>>
>>        Title           : Network Service Header
>>        Authors         : Paul Quinn
>>                          Uri Elzur
>> 	Filename        : draft-ietf-sfc-nsh-07.txt
>> 	Pages           : 37
>> 	Date            : 2016-08-23
>>
>> Abstract:
>>   This document describes a Network Service Header (NSH) inserted onto
>>   packets or frames to realize service function paths.  NSH also
>>   provides a mechanism for metadata exchange along the instantiated
>>   service path.  NSH is the SFC encapsulation required to support the
>>   Service Function Chaining (SFC) Architecture (defined in RFC7665).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-07
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Dave Dolson <[email-masked]>
Date: Tue, 6 Sep 2016 18:21:02 +0000

I have a comment on the specification of Service Index (SI).
The document says, 
    The initial classifier for a given SFP SHOULD set the SI to 255, however the	
    control plane MAY configure the initial value of SI as appropriate...

If you read this literally, it seems to say that the classifier SHOULD set the initial SI to 255 regardless of what the control plane tells it to do.
It is perhaps implied that the classifier MAY do what the control plane tells it to, but that's not what the words say.

I think wording like this might help:
    The initial classifier MUST set the SI to the value specified by configuration for the classification outcome. The initial SI configuration SHOULD default to 255. However, the classifier MUST allow configuration of other SI values.

Similar wording should apply to the SPI; nothing is said about the classifier in the paragraph about SPI. I suggest:
    The initial classifier MUST set the SPI to the value specified by configuration for the classification outcome.

Note, I've said "configuration" instead of "control plane". I'm assuming a control plane will do configuration. If you just want to talk about control plane, then there is no need for any default, just "The classifier MUST set the SET to the value specified by the control plane for the classification."

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 23, 2016 12:48 PM
To: [email-masked]
Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

Dear WG:

Thanks!

Jim, Martin, & Thomas

---

From: "Duarte Cardoso, Igor" <[email-masked]>
Date: Wed, 7 Sep 2016 16:31:39 +0000

Hi SFC WG,

I have some comments and trivial corrections to provide to draft-ietf-sfc-nsh-07.

- "confidentially" should be "confidentiality" in both of its occurrences;

- At the end of section 9:
	- "describe in" should be "described in"
	- "MD-2" should be "MD-Type 2"

- Also consider converging to either "MD Type" or "MD-Type", as both seem to be used throughout the draft;

- Section 3.3:

- "SI SHOULD be used in conjunction with SPI for SFP selection and for determining the next SFF/SF in the path":

	Two comments:

		- The statement (and the rest of the paragraph) seems to be about the forwarding side of NSH (forwarding/SFFs) However, it also seems to be about the classification side of NSH (classification/Classifiers) as they are the logical elements which, with the influence of different SPI+SI, choose the next SFP (specifically, the next SPI). Can this perhaps be clarified?

		- Assuming SFP is the concrete network path that will be taken to reach the next SF, which may be 1 of many possible SFPs for the same SPI/SI combination, then the statement seems to imply that SI+SPI allow for SFP selection AND determining the next SFF/SF. However, the latter is a consequence of the former. I believe the following would better reflect the intended objective of  the original statement:

		"SI SHOULD be used in conjunction with SPI for SFP selection and, consequently, determining the next SFF/SF in the path".

- "When an SPI and SI do not correspond to a valid next Service Function path"

	If my above assumption regarding 1 of many possible SFPs being possible for the same SPI/SI combination is incorrect, then this statement seems to imply that SPI and SIs together map to a SFP, but in reality they together map to a SF.
	If so, I believe that the following would better reflect the intended objective of the original statement:

	"When an SPI and SI do not correspond to a valid next hop of a Service Function".

Any questions or requests for clarifications, just ask.

Best regards,
Igor.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, September 6, 2016 7:21 PM
To: Jim Guichard (jguichar) <[email-masked]>; [email-masked]
Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 23, 2016 12:48 PM
To: [email-masked]
Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

Dear WG:

Thanks!

Jim, Martin, & Thomas

On 8/23/16, 11:47 AM, "sfc on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Sat, 10 Sep 2016 17:29:44 +0000

Med,

Med, as always, thank you for your review.

> On Aug 26, 2016, at 5:31 AM, [email-masked] wrote:
> 
> Hi Jim, all,
> 
> Likewise, I would like to see this document progress as well. 
> 
> In addition to the comment raised in a separate message about the C-bit of TLVs, I have the following comments:
> 
> (1) Section 2: I suggest to delete the following sentence: 
> 
>   NSH is designed to be easy to implement across a range of devices,
>   both physical and virtual, including hardware platforms.
> 
> Reason: the use of "easy to implement" should be justified if that text is maintained. Otherwise, this is subjective. 
> 
> or to reword it as follows: 
> 
>   "NSH can be implemented in both physical and virtual platforms."

PQ>  The "easy to implement" is a reference to the nature of type-1 and how, as noted by hardware implementors, this vastly simplifies implementation.  Further, the language is widely used in RFCs (e.g. 7321, 3160, etc.).

> 
> (2) Section 2.3: I suggest to change this OLD text:
> 
> The semantics of
>       the shared metadata is communicated via a control plane, which is
>       outside the scope of this document, to participating nodes.
> 
> NEW:
> 
> The semantics of 
> the shared metadata is communicated via a control plane (Section 3.3 of [I-D.ietf-sfc-control-plane]).
> 

PQ>  Proposed text: "The semantics of the shared metadata is communicated via a control plane, which is outside the scope of this document, to participating nodes.  [ietf-sfc-control-plane] provides an example of such in section 3.3.

> (3) Section 2.3- Not sure I would maintain this text: 
> 
>   5.  NSH offers a common and standards-based header for service
>       chaining to all network and service nodes.
> 
> "to all" is not accurate as "legacy" nodes are still there.  
> 

PQ>  Given that "legacy" nodes are supported via proxy, this is indeed true.

> (4) Section 2.3:
> 
> OLD:
> Transport Agnostic: NSH is transport independent and is often
>       carried via a network transport protocol,
> 
> NEW:
> Transport Agnostic: NSH is transport independent. Any network transport protocol can be used to transport NSH-encapsulated traffic.

PQ>  Proposed text: NSH is transport independent. An appropriate (for a given deployment) network transport protocol can be used to transport NSH-encapsulated traffic.

> 
> (5) Section 3.2:
> 
>   NSH implementations MUST support MD-Type = 0x1, and SHOULD support
>   MD- Type = 0x2.
> 
> Because:
> * of potential interoperability issues.
> * MD#2 is more compact when no metadata is to be supplied
> * MD#2 allows to convey more information compared to MD#1
> 
> I suggest we revisit that sentence to have MD#2 be mandatory to be supported (my favorite option), or at least require that both MDs defined in this spec MUST be supported. 
> 
PQ>  As per the previous discussion, this MUST/SHOULD reflect the practical reality of implementation and helps ensure deployability.  

> (6) Section 3.2:
> 
>   C bit: Indicates that a critical metadata TLV is present.  This bit
>   acts as an indication for hardware implementers to decide how to
>   handle the presence of a critical TLV without necessarily needing to
>   parse all TLVs present.  For an MD Type of 0x1 (i.e. no variable
>   length metadata is present), the C bit MUST be set to 0x0.
> 
> 6.1. What is the behavior of the implementation if C-bit is set but not critical metadata is found in the payload?
> 6.2. What is the behavior of the implementation if C-bit is unset but a critical metadata is found in the payload?
> 6.3. What is the behavior of the implementation with regards to this bit if a critical metadata is added in-path?
> 6.4. What is the behavior of the implementation with regards to this bit if a critical metadata is stripped in-path?   
> 6.5. Should the specification recommend an order of metadata so that critical metadata are always positioned first?

PQ>  

6.1: essentially continue "as is" with an optional warning message
6.2: generate an warning error, possibly set C
6.3: the adder sets C
6.4: the remover clears C
6.5: no, this creates too many limitations/complexity.  An implementation might opt to optimize.  

> 
> (7) Section 3.3: The following text 
> 
> " ... however the
>   control plane MAY configure the initial value of SI as appropriate
>   (i.e. taking into account the length of the service function path). "
> 
> is not aligned with the outcome of the discussion we had during the WG LC of draft-ietf-sfc-control-plane (https://www.ietf.org/mail-archive/web/sfc/current/msg04594.html):
> 
>   The control plane must instruct the classifier about the initial
>   values of the Service Index (SI).
> 

PQ>  The control plane can assign but NSH provides a default value recommendation, I'm not sure there's a conflict.

> 7.1. I suggest to modify NSH draft accordingly. 

PQ>  I'm not clear what you are suggesting?

> 7.2. Please consider adding a reference to draft-ietf-sfc-control-plane

PQ>  I'll update.

> 
> (8) Section 3.4: I still do think this section is underspecified. E.g., 
> 
> 8.1. The use of "Mandatory Context Header" conflicts with this text in Section 3:
> 
>   A Network Service Header (NSH) contains service path information and
>   optionally metadata that are added to a packet or frame and used to
>   ^^^^^^^^^^^^^^^^^^^
>   create a service plane.
> 
> 8.2. The specification does not forbid that all context headers are set to zero. Otherwise, MD#2 should be used instead.

PQ>  In either care, 1 or 2, no metadata is valid: all zeroes in type 1 or no data in type 2.  

> 8.3. The specification does not specify how these context headers are to be validated. 

PQ>  By validated, so you mean cryptographically asserted, or simply compared to known value?  In either case, that is outside of the scope of this draft.

> 8.4. I still don't understand why four headers are chosen.  

PQ>  As per previous discussions, based experience, use case and implementation, four strikes a balance. The widespread implementations of type 1 support this.

> 
> (9) Section 3.5.1:
> 
> The length of "Metadata Class" is over-dimensioned. I suggest to reduce the length of this field and increase the length of "Type".
> 
> For example, let's consider the proposal in https://tools.ietf.org/html/draft-napper-sfc-nsh-broadband-allocation-00#section-4.2: 
> 
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |     TLV Class = 3GPP          |C|    Type     |R|R|R|   Len   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |    Data ...
>   +-+-+-+-+-+-+-+-+
> 
>                         Figure 5: TLV Allocation
> 
>   The intended use of the header is for TLVs associated with 3GPP Radio
>   Access Networks as described in [TS.29.230].  This TLV can be used by
>   3GPP to extend the metadata as per use cases.  Having this TLV helps
>   to carry more information that does not fit within the MD Type 0x01.
> 
> The list of codes in Table 7.1 of TS.29.230 cannot be conveyed with a "Type" field of 7 bits.

PQ>  At this point, the allocation seems reasonable, provides for a large range of "owners", and the TLV schemes proposed work within this scope.

> 
> (10) Section 4: 
> 
> OLD:
> 
> +---------------+------------------+-------+----------------+---------+
> |                |  Insert         |Select |   Update       |Service  |
> |                |  or remove NSH  |Service|    NSH         |policy   |
> |                |                 |Function|               |selection|
> | Component      +--------+--------+Path   +----------------+         |
> |                |        |        |       | Dec.   |Update |         |
> |                | Insert | Remove |       |Service |Context|         |
> |                |        |        |       | Index  |Header |         |
> +----------------+--------+--------+-------+--------+-------+---------+
> |                |   +    |   +    |       |        |   +   |         |
> |Classifier      |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |Service Function|        |   +    |  +    |        |       |         |
> |Forwarder(SFF)  |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |Service         |        |        |       |   +    |   +   |   +     |
> |Function  (SF)  |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |SFC Proxy       |   +    |   +    |       |   +    |       |         |
> +----------------+--------+--------+-------+--------+-------+---------+
> 
> NEW:
> 
> +---------------+------------------+-------+----------------+---------+
> |                |  Insert         |Select |   Update       |Service  |
> |                |  or remove NSH  |Service|    NSH         |policy   |
> |                |                 |Function|               |selection|
> | Component      +--------+--------+Path   +----------------+         |
> |                |        |        |       | Dec.   |Update |         |
> |                | Insert | Remove |       |Service |Context|         |
> |                |        |        |       | Index  |Header |         |
> +----------------+--------+--------+-------+--------+-------+---------+
> |                |   +    |   +    |       |        |   +   |         |
> |Classifier      |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |Service Function|        |   +    |  +    |        |       |         |
> |Forwarder(SFF)  |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |Service         |        |        |       |   +    |   +   |   +     |
> |Function  (SF)  |        |        |       |        |       |         |
> +--------------- +--------+--------+-------+--------+-------+---------+
> |SFC Proxy       |   +    |   +    |       |   +    |   +   |         |
> +----------------+--------+--------+-------+--------+-------+---------+

PQ>  Just to be clear (formatting was a bit off in the email):

In the last line, SFC Proxy, add "Update Context Header"?

> 
> (11) Section 7.2: Please consider adding an IPv6 example.

PQ>  Happily.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 14 Sep 2016 16:33:47 +0000

Dave,

Thanks for these suggestions/clarifications, I can see how this might be misinterpreted.

My concern is with the work "configuration" in the first sentence since it might imply the need for configuration vs default.  So a minor tweak:

"The initial classifier MUST set the appropriate SPI and SI values for a given classification result.  The initial SI configuration SHOULD default to 255. However, the classifier MUST allow configuration of other SI values."

Paul

> On Sep 6, 2016, at 2:21 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 14 Sep 2016 17:08:07 +0000

Igor,

Thank you for your comments.  Please see inline.

> On Sep 7, 2016, at 12:31 PM, Duarte Cardoso, Igor <[email-masked]> wrote:
> 
> Hi SFC WG,
> 

PQ> Thank you, all of the above have been updated.

> 		"SI SHOULD be used in conjunction with SPI for SFP selection and, consequently, determining the next SFF/SF in the path".

PQ>  I'm fine with this clarification.  

> 	"When an SPI and SI do not correspond to a valid next hop of a Service Function".

PQ>  I think this has a slightly different meaning but I do see your point.  Perhaps:

"When an SPI and SI do not correspond to a valid next hop in a SFP"

---

From: Dave Dolson <[email-masked]>
Date: Wed, 14 Sep 2016 17:15:54 +0000

Yes, that is good. How do you feel about adding another "configured"?

"The initial classifier MUST set the appropriate SPI and SI values configured for a given classification result.  The initial SI configuration SHOULD default to 255. However, the classifier MUST allow configuration of other SI values."

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2016 12:34 PM
To: Dave Dolson
Cc: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

Dave,

Paul

---

From: Dave Dolson <[email-masked]>
Date: Wed, 14 Sep 2016 17:18:17 +0000

Sorry, I see I didn't properly read your concern about "configuration" in the first sentence.  I guess I don't understand your concern. Surely the SPI and SI are configured, although SI may default to 255.

-Dave

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2016 12:34 PM
To: Dave Dolson
Cc: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt

Dave,

Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 14 Sep 2016 17:23:44 +0000

I suggest omitting that "configured" (i.e. the one in the first sentence) since it implies an explicit configuration vs. a default (by which I mean behavior absent of an explicit configuration).  For SPI this isn't true (i.e. you need explicit config) but the point the original text was trying to make was that, for SI, no explicitly config is needed, although it can be supplied.

> On Sep 14, 2016, at 1:18 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 14 Sep 2016 17:28:51 +0000

OK, I see, yes. This is in the paragraph describing the SI.

Will you update the SPI section ?

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 14 Sep 2016 17:34:35 +0000

Yes, I think it's reasonable to add similar text there as well:

"The initial classifier MUST set the appropriate SPI for a given classification result."

I believe that encompasses configured vs. default which is appropriate, IMO, in this section.

> On Sep 14, 2016, at 1:28 PM, Dave Dolson <[email-masked]> wrote:
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 14 Sep 2016 17:37:57 +0000

Thanks

---

From: <[email-masked]>
Date: Tue, 27 Sep 2016 12:50:44 +0000

Hi Paul, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Paul Quinn (paulq) [mailto:[email-masked]]
> Envoyé : samedi 10 septembre 2016 19:30
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Jim Guichard (jguichar); [email-masked]
> Objet : Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt
> 
> Med,
> 
> > Reason: the use of "easy to implement" should be justified if that text
> is maintained. Otherwise, this is subjective.
> >
> PQ>  The "easy to implement" is a reference to the nature of type-1 and
> how, as noted by hardware implementors, this vastly simplifies
> implementation.  Further, the language is widely used in RFCs (e.g. 7321,
> 3160, etc.).

[Med] Unless that statement is backed with citations or arguments, I still consider it as subjective.

> PQ>  Proposed text: "The semantics of the shared metadata is communicated
> via a control plane, which is outside the scope of this document, to
> participating nodes.  [ietf-sfc-control-plane] provides an example of such
> in section 3.3.
> 

[Med] Works for me. 

> PQ>  Given that "legacy" nodes are supported via proxy, this is indeed

[Med] Please update the text to mention the proxy case. Thank you.

> > Transport Agnostic: NSH is transport independent. Any network transport
> protocol can be used to transport NSH-encapsulated traffic.
> 
> 
> PQ>  Proposed text: NSH is transport independent. An appropriate (for a
> given deployment) network transport protocol can be used to transport NSH-
> encapsulated traffic.
> 

[Med] OK. Thanks. 

> > I suggest we revisit that sentence to have MD#2 be mandatory to be
> supported (my favorite option), or at least require that both MDs defined
> in this spec MUST be supported.
> >
> PQ>  As per the previous discussion, this MUST/SHOULD reflect the
> practical reality of implementation and helps ensure deployability.
> 

[Med] the SHOULD for MD#2 does not help interoperability. I reiterate my comment to update the language to use MUST for MD#2.

> > 6.1. What is the behavior of the implementation if C-bit is set but not
> critical metadata is found in the payload?
> > 6.2. What is the behavior of the implementation if C-bit is unset but a
> critical metadata is found in the payload?
> > 6.4. What is the behavior of the implementation with regards to this bit
> if a critical metadata is stripped in-path?
> > 6.5. Should the specification recommend an order of metadata so that
> critical metadata are always positioned first?
> 
> PQ>
> 

[Med] This should be reflected in the specification.

> > is not aligned with the outcome of the discussion we had during the WG
> LC of draft-ietf-sfc-control-plane (https://www.ietf.org/mail-
> archive/web/sfc/current/msg04594.html):
> >
> PQ>  The control plane can assign but NSH provides a default value
> recommendation, I'm not sure there's a conflict.

[Med] The default value in the text is a SHOULD not a MUST.   

> PQ>  I'm not clear what you are suggesting?

[Med] The proposal is to use the same wording proposed by Jim for the CP draft. 

> > 8.2. The specification does not forbid that all context headers are set
> to zero. Otherwise, MD#2 should be used instead.
> 
> 
> PQ>  By validated, so you mean cryptographically asserted, or simply
> compared to known value?  In either case, that is outside of the scope of
> this draft.

[Med] No. My concern is how an implementation will consider that a given mandatory header is conveying what is supposed to include. Some validation checks are required.

> PQ>  As per previous discussions, based experience, use case and
> implementation, four strikes a balance. The widespread implementations of
> type 1 support this.

[Med] I'm not aware of any public use case that requires 4 mandatory context headers. Can you please provide a public link to a document where this is discussed?

> 
> 
> >
> > (9) Section 3.5.1:
> >
> > The length of "Metadata Class" is over-dimensioned. I suggest to reduce
> the length of this field and increase the length of "Type".
> >
> > For example, let's consider the proposal in
> https://tools.ietf.org/html/draft-napper-sfc-nsh-broadband-allocation-
> 00#section-4.2:
> >
> PQ>  At this point, the allocation seems reasonable, provides for a large
> range of "owners", and the TLV schemes proposed work within this scope.

[Med] "reasonable" compared to what? The example I provided above for the 3GPP case shows clearly that 7-bits are not sufficient for TS.29.230. Further, 2^^16 is over dimensioned for owners.

> In the last line, SFC Proxy, add "Update Context Header"?

[Med] Yes.

> > (11) Section 7.2: Please consider adding an IPv6 example.

[Med] Thank you.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 28 Sep 2016 16:19:30 +0000

Hi Med,

Please see inline...

>[Med] The default value in the text is a SHOULD not a MUST.  

Jim> I am not sure what you are asking for here. The current text in section 3.3 is:

Service Index (SI): provides location within the SFP.  The initial
   classifier MUST set the appropriate SI value for a given
   classification result.  The initial SI value SHOULD default to 255.
   However, the classifier MUST allow configuration of other SI values.

Jim> Is there something missing in the above text?

Jim

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 28 Sep 2016 17:05:34 +0000

Hi Med,

Inline on the MD MUST/SHOULD question.

>[Med] the SHOULD for MD#2 does not help interoperability. I reiterate my comment to update the language to use MUST for MD#2.

Jim> as you know there was lots of discussion on this topic but no WG consensus to change the text from SHOULD to MUST. However, text was added as a compromise so that a type-1 implementation MUST be able to parse the length and skip the type-2 metadata if it is unable to process said metadata.

Jim