Subject: [sfc] NSH base header length

From: James N Guichard <[email-masked]>
Date: Tue, 7 Feb 2017 19:02:29 +0000

Greetings WG,

At the recent interim meeting we discussed the current text around the length field in the NSH base header. The last sentence of this text in section 3.2 of draft-ietf-sfc-nsh-10 reads:

"The length field indicates the "end" of NSH and where the original packet/frame begins."

A proposed rework of this text is as follows:

"The length field indicates the beginning of the packet/frame of the next protocol reflected in the NSH base header".

Please provide comments to the mailing list for this change.

Thanks!

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Feb 2017 19:34:52 +0000

I approve.

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Tuesday, February 07, 2017 2:02 PM
To: [email-masked]
Subject: [sfc] NSH base header length

Greetings WG,

Thanks!

Jim & Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 7 Feb 2017 20:25:47 +0000

Jim, Joel,

The proposed rewording would not fully work with a potential future NULL next protocol, if that were to ever exist. But regardless, the only thing we know is that it is the end of the NSH.

For forward compatibility, I recommend something like “the end of *this* NSH.” and be done. Or just removing the sentence all together, since the definition is prescriptive enough.

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 Feb 7, 2017, at 2:02 PM, James N Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Greetings WG,

“The length field indicates the “end” of NSH and where the original packet/frame begins.”

“The length field indicates the beginning of the packet/frame of the next protocol reflected in the NSH base header”.

Thanks!

Jim & Joel

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

---

From: James N Guichard <[email-masked]>
Date: Tue, 7 Feb 2017 21:27:48 +0000

Hi Carlos,

[chair hat off …] .. Given that the previous text describes that the total length includes the base header, the service path header, and context headers/TLVs, I tend to agree that the last sentence is somewhat redundant and removing it is certainly an option the WG should consider.

Jim

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 3:26 PM
To: James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] NSH base header length

Jim, Joel,

Thanks,

—

Greetings WG,

Thanks!

Jim & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Feb 2017 14:53:59 -0800

Dear All,
the preceding text explains clearly what must be included in Length field
value. I agree that the last sentence of the paragraph, i.e. "The length
field indicates ..." is redundant. (It should be s/length/Length/)

Regards,
Greg

On Tue, Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Jim, Joel,
>
> The proposed rewording would not fully work with a potential future NULL
> next protocol, if that were to ever exist. But regardless, the only thing
> we know is that it is the end of the NSH.
>
> For forward compatibility, I recommend something like “the end of *this*
> NSH.” and be done. Or just removing the sentence all together, since the
> definition is prescriptive enough.
>
> Thanks,
>
> —
> Carlos Pignataro, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> On Feb 7, 2017, at 2:02 PM, James N Guichard <[email-masked]>
> wrote:
>
> Greetings WG,
>
> At the recent interim meeting we discussed the current text around the
> length field in the NSH base header. The last sentence of this text in
> section 3.2 of draft-ietf-sfc-nsh-10 reads:
>
> “The length field indicates the beginning of the packet/frame of the next
> protocol reflected in the NSH base header”.
>
> [email-masked]
> [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 10:37:32 -0000

All,
 
Can't we describe the length field as a length field not as some form of pointer to this or that?
 
Thus, just strike that last sentence: it is redundant and polishing it will not change that.
 
Thus:
 
   Length: total length, in 4-byte words, of NSH including the Base
   Header, the Service Path Header and the context headers or optional
   variable length metadata.  The Length MUST be of value 0x6 for MD
   Type equal to 0x1 and MUST be of value 0x2 or greater for MD Type
   equal to 0x2.  The NSH header length MUST be an integer number of 4
   bytes.
 
Then we can focus on polishing *this* text!
 
How about...
 
   Length: The total length, in 4-byte words, of the NSH including the 
   Base Header, the Service Path Header, and any Context Headers or
   optional variable length metadata that is present.  The Length MUST
   be of value 0x6 for MD Type equal to 0x1, and MUST be of value 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.
 
Cordially,
Adrian
 
From: sfc [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 07 February 2017 22:54
To: Carlos Pignataro (cpignata)
Cc: [email-masked]; James N Guichard
Subject: Re: [sfc] NSH base header length
 
Dear All,
the preceding text explains clearly what must be included in Length field value. I agree that the last sentence of the paragraph, i.e. "The length field indicates ..." is redundant. (It should be s/length/Length/)
 
Regards,
Greg
 
On Tue, Feb 7, 2017 at 12:25 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
Jim, Joel, 

 
Thanks,
 
—

On Feb 7, 2017, at 2:02 PM, James N Guichard <[email-masked]> wrote:
 
Greetings WG,

 

 
Thanks!
 
Jim & Joel

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