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

From: <[email-masked]>
Date: Tue, 4 Oct 2016 08:31:38 +0000

Hi Jim, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Jim Guichard (jguichar) [mailto:[email-masked]]
> Envoyé : mercredi 28 septembre 2016 18:20
> À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq)
> Cc : [email-masked]
> Objet : Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt
> 
> Hi Med,
> 
> Please see inline...
> 
> 
> 
> 
> 
> On 9/27/16, 8:50 AM, "[email-masked]"
> <[email-masked]> wrote:
> 
> >
> >
> >>
> >> >
> >> > (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.
> >
> >[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?

[Med] My comment is to change "The initial SI value SHOULD default to 255" to "If no initial value is set, the initial SI value MUST default to 255.".

> Jim

---

From: <[email-masked]>
Date: Tue, 4 Oct 2016 08:41:29 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : mercredi 28 septembre 2016 19:06
> Inline on the MD MUST/SHOULD question.
> 
> 
> 
> 
> >
> >>
> >> >
> >> > (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.
> >>
> >
> >[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.

[Med] You may be right but I remember there were many voices asking for having MD#2 as mandatory. I do still think the current statement will lead to an interoperability issue as distinct implementations will not expose the same behavior with regards to MD#2 support. For example, MD#2 is more optimal for the following deployments: 
* No additional metadata is supplied at all: compact NSH header. 
* Longer metadata is to be supplied: not limited to four 
* Rich metadata is to be supplied: metadata that is not enclosed in 32  bits

Thank you.