Subject: Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-nsh-25: (with COMMENT)

From: Benoit Claise <[email-masked]>
Date: Sat, 7 Oct 2017 11:27:30 +0200

Hi Med,
> Hi Benoit,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : sfc [mailto:[email-masked]] De la part de Benoit Claise
>> Envoyé : jeudi 28 septembre 2017 15:56
>> À : The IESG
>> Cc : [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Objet : [sfc] Benoit Claise's No Objection on draft-ietf-sfc-nsh-25: (with
>> COMMENT)
>>
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-sfc-nsh-25: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> - Section 2.5.1., you might want to mention that no metadata are specified
>> at
>> this point in time.
> [Med] Aren't these mentions sufficient?
>
>     This specification does not make any assumption about Context Headers
>     that are mandatory-to-implement or those that are mandatory-to-
>     process.
Now that you stress it, maybe.
I was interested to understand whose responsibility it is to specify those.
Some such as:

    This specification does not make any assumption about Context Headers
    that are mandatory-to-implement or those that are mandatory-to-
    process. These considerations are deployment-specific.
    Those optional variable metadata specifications will be specified by xxx
    for ...

And then, is this for a new service, a new application, a new ...?
I don't know the right terminology.
>
> And
>
>     No initial values are assigned at the creation of the registry.
>
>   Indeed, "New IETF Assigned Optional Variable Length
>> Metadata Type Registry is specified in this doc., but empty
>>
>> - Section 2.3
>> OPS question: SPI must be unique per admin domain? Otherwise, you're
>> looking
>> for trouble, right? This would be typically addressed in an "Operational
>> Considerations" section. Where is my "Operational Considerations"
>> section...?
> [Med] Already covered in the SFC architecture (RFC 7665):
>
>     SFFs maintain the requisite SFP forwarding information.  SFP
>     forwarding information is associated with a service path identifier
>     that is used to uniquely identify an SFP.
I surely missed that when I reviewed the normative references before 
reviewing this document ..., as I always do ...
Any issue to repeat it here?

>
>> - Section 2.4
>> Fixed length metadata.
>>
>>     This specification does not make any assumptions about the content of
>>     the 16 byte Context Header that must be present when the MD Type
>>     field is set to 1, and does not describe the structure or meaning of
>>     the included metadata.
>>
>>     An SFC-aware SF MUST receive the data semantics first in order to
>>     process the data placed in the mandatory context field.  The data
>>     semantics include both the allocation schema and the meaning of the
>>     included data.
>>
>> I understand that the order of the metadata in the Fixed Length Context
>> Header
>> is important, right?
> [Med] The notion of order in the opaque 16-byte block does not make in this spec. How that block is structured is really out of scope.
This is a concept that I missed when reading this spec.
I might not be the only one...
>
>   Should it be mentioned?
>
> [Med] I don't think so.
>
>   I understand that the fixed
>> length
>> metadata are specific per service, and that's the reason why there is no
>> IANA
>> for fixed length. Should this be mentioned?
> [Med] The agreement in the WG is to publish documents specifying MD#1 as informational documents. IANA is not involved in this process, because there is no expected action with regards to MD#1 context headers.

Regards, Benoit
>
>> - if you publish a new version, change the order of these two paragraphs:
>>
>>     Unassigned bits: All other flag fields, marked U, are unassigned and
>>     available for future use, see Section 11.2.1.  Unassigned bits MUST
>>     be set to zero upon origination, and MUST be ignored and preserved
>>     unmodified by other NSH supporting elements.  At reception, all
>>     elements MUST NOT modify their actions based on these unknown bits.
>>
>>     Length: The total length, in 4-byte words, of the NSH including the
>>     Base Header, the Service Path Header, the Fixed Length Context Header
>>     or Variable Length Context Header(s).  The length MUST be 0x6 for MD
>>     Type equal to 0x1, and MUST be 0x2 or greater for MD Type equal to
>>     0x2.  The length of the NSH header MUST be an integer multiple of 4
>>     bytes, thus variable length metadata is always padded out to a
>>     multiple of 4 bytes.
>>
>> Lacking some time before the telechat, but not worth deferring (there are
>> enough DISCUSS'). FYI, I arrived at section 5.
>>
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
> .
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 9 Oct 2017 23:47:14 +0000

Benoit,

I’ll let Med respond, but for completeness, I added a couple editorial clarifications based on your comments below.

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Oct 7, 2017, at 5:27 AM, Benoit Claise (bclaise) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Med,
Hi Benoit,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Benoit Claise
Envoyé : jeudi 28 septembre 2017 15:56
À : The IESG
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : [sfc] Benoit Claise's No Objection on draft-ietf-sfc-nsh-25: (with
COMMENT)

And

- Section 2.3

I surely missed that when I reviewed the normative references before reviewing this document ..., as I always do ...

- Section 2.4
Fixed length metadata.

 Should it be mentioned?

[Med] I don't think so.

Regards, Benoit

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

---

From: <[email-masked]>
Date: Tue, 10 Oct 2017 13:58:42 +0000

Hi Benoit, 

Please see inline. 

Thank you.
Cheers,
Med

> De : Benoit Claise [mailto:[email-masked]]
> Envoyé : samedi 7 octobre 2017 11:27
> À : BOUCADAIR Mohamed IMT/OLN; The IESG
> Objet : Re: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-nsh-25:
> (with COMMENT)
> 
> Hi Med,
> > Hi Benoit,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
[Med] No surprise out there. Like any protocol extension, future documents will be developed to specify key context information.  

> And then, is this for a new service, a new application, a new ...?

[Med] Future specifications that specify context TLVs will specify under which condition a given TLV can be used and so. These considerations are really out of scope of the NSH spec.

> Any issue to repeat it here?

[Med] I do personally see it as redundant, but if you think this is important to implement the NSH spec, then it should be added. 

> > [Med] The notion of order in the opaque 16-byte block does not make in
> this spec. How that block is structured is really out of scope.

[Med] I hear you. Can you please indicate whether this text is not clear enough? 

===
====

> > [Med] The agreement in the WG is to publish documents specifying MD#1 as
> informational documents. IANA is not involved in this process, because
> there is no expected action with regards to MD#1 context headers.
> 
> Regards, Benoit
> >

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Oct 2017 16:14:39 +0200

Fine with me

Regards, B.