Subject: [sfc] TTL field within the NSH base header

From: James N Guichard <[email-masked]>
Date: Thu, 27 Apr 2017 18:54:09 +0000

Dear WG:

Having reviewed all of the email discussion on the mailing list it appears to the chairs that we have consensus to add a TTL field to the NSH base header. We would like to propose the following changes:

Section 3.2:
Update figure 2 as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Ver|O|R|    TTL    |   Length  |R|R|R|R|MD Type| Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Add the following text after figure 2:

TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

Section 3.4:
Update figure 4 to reflect the new base header format as per section 3.2 base header.

Section 3.5:
Update figure 5 to reflect the new base header format as per section 3.2 base header.

Section 12.2.1:
Current text is as follows:

   There are ten bits at the beginning of the NSH Base Header.  New bits
   are assigned via Standards Action [RFC5226].

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Critical TLV (C bit)
   Bits 4-9 - Reserved

Replace entire text as follows:

   There are eight reserved bits in the NSH Base Header. New bits
   are assigned via Standards Action [RFC5226].

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:
Current text has the MD-type as 8-bit values.

Update text for this section and table 1 to reflect 4-bit values *not* 8-bit values.

Please review carefully and indicate support for these changes (or any changes to the suggested text).

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Thu, 27 Apr 2017 19:02:43 +0000

I think that is improved wording. I support it.

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Thursday, April 27, 2017 2:54 PM
To: [email-masked]
Subject: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Apr 2017 19:20:35 +0000

I had to really think about the language around decrementing by 1 from 0 and reaching 63.   This would only occur in an error scenario where a preceding SFF misbehaved, wouldn't it?   Why are we insistent that the test for 0 happen after decrement, thereby creating this problem.     I suspect that this has been already discussed and I apologize if I missed it, but if the language were simplified to say an SFF that receives an NSH with TTL=1 shall not forward it to another SFF (e.g., allowing it to engage its local SF instances, still).   Otherwise, it must decrement by 1 before forwarding to another SFF.

An exact wording along these lines might be something like:

TTL: Service plane time-to-live. An SFF MUST test the TTL before forwarding to another SFF for a given Service Function Chain.  If the received TTL value is 1, the SFF MUST drop packets that would otherwise have been forwarded to another SFF, but SHALL send such packets to attached service functions if the SFF terminates the Service Function Chain.   If the TTL value is greater than 1, the SFF must decrement the TTL by 1 before forwarding to another SFF.   The default for originating an NSH packet is a TTL value of 63.

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Dave Dolson <[email-masked]>
Date: Thu, 27 Apr 2017 20:02:35 +0000

Ron,
Decrementing from zero to reach 63, and checking for zero after decrementing provides a degree of backwards compatibility with the prior header format.
This permits packets on the wire to have 0 in the bits that were previously "reserved".

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, April 27, 2017 3:21 PM
To: James N Guichard; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Thursday, April 27, 2017 2:54 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Apr 2017 20:05:05 +0000

Thanks, Dave.    Do you think it is possible to combine that backward compatibility with the simpler (to me) concept of testing for a packet that arrives with TTL=1 and conditioning behavior on whether the SFF is the terminating SFF of the path?

   Ron

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 27, 2017 4:03 PM
To: Ron Parker <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]
Subject: RE: TTL field within the NSH base header

Ron,

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, April 27, 2017 3:21 PM
To: James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Apr 2017 16:20:26 -0400

Jim,

The replacement text says:

There are now actually five reserved bits.

Cheers,
Andy

On Thu, Apr 27, 2017 at 2:54 PM, James N Guichard <
[email-masked]> wrote:

> Dear WG:
>
>
>
> Having reviewed all of the email discussion on the mailing list it appears
> to the chairs that we have consensus to add a TTL field to the NSH base
> header. We would like to propose the following changes:
>
>
>
> Section 3.2:
>
> TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value
> of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0
> shall result in a TTL value of 63. The default for originating an NSH
> packet is a TTL value of 63. The decrement SHALL occur before testing for
> 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.
>
>
>
> Section 3.4:
>
> *Please review carefully and indicate support for these changes (or any
> changes to the suggested text).*
>
>
>
> Thanks,
>
>
>
> Jim & Joel
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: Jim Guichard <[email-masked]>
Date: Thu, 27 Apr 2017 20:37:23 +0000

Yes but I also counted the other 3 bits that were reserved and are now
allocated..

On Thu, Apr 27, 2017 at 4:25 PM Andrew G. Malis <[email-masked]> wrote:

>> Having reviewed all of the email discussion on the mailing list it
>> appears to the chairs that we have consensus to add a TTL field to the NSH
>> base header. We would like to propose the following changes:
>>
>>
>>
>>
>>
>> Section 3.2:
>>
>>
>> packet is a TTL value
>> of 63. The decrement SHALL occur before testing for 0. After decrement,
>> if the TTL is 0, the NSH packet MUST NOT be forwarded.
>>
>>
>>
>>
>>
>> Section 3.4:
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Apr 2017 16:37:37 -0400

That alternative was discussed.  It also works.
However, with that alternative, if the Initial classifier is an old 
system (not RFC compliant), we will not get any protection from the TTL.
If we take this (admittedly slightly odd) approach to decrementing the 
TTL, then even though we do not recommend it, things still work with an 
initial classifier that generates a TTL of 0.

It is thus more robust, so the WG selected it in discussion atht 
einterim adn on the list.

Yours,
Joel

On 4/27/17 4:05 PM, Ron Parker wrote:
> Thanks, Dave.    Do you think it is possible to combine that backward
> compatibility with the simpler (to me) concept of testing for a packet
> that arrives with TTL=1 and conditioning behavior on whether the SFF is
> the terminating SFF of the path?
>
>
>
>    Ron
>
>
>
>
>
> *From:* Dave Dolson [mailto:[email-masked]]
> *Sent:* Thursday, April 27, 2017 4:03 PM
> *To:* Ron Parker <[email-masked]>; James N Guichard
> <[email-masked]>; [email-masked]
> *Subject:* RE: TTL field within the NSH base header
>
>
>
> Ron,
>
> Decrementing from zero to reach 63, and checking for zero after
> decrementing provides a degree of backwards compatibility with the prior
> header format.
>
> This permits packets on the wire to have 0 in the bits that were
> previously “reserved”.
>
>
>
> -Dave
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ron Parker
> *Sent:* Thursday, April 27, 2017 3:21 PM
> *To:* James N Guichard; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] TTL field within the NSH base header
>
>
>
> I had to really think about the language around decrementing by 1 from 0
> and reaching 63.   This would only occur in an error scenario where a
> preceding SFF misbehaved, wouldn’t it?   Why are we insistent that the
> test for 0 happen after decrement, thereby creating this problem.     I
> suspect that this has been already discussed and I apologize if I missed
> it, but if the language were simplified to say an SFF that receives an
> NSH with TTL=1 shall not forward it to another SFF (e.g., allowing it to
> engage its local SF instances, still).   Otherwise, it must decrement by
> 1 before forwarding to another SFF.
>
>
>
> TTL: Service plane time-to-live. An SFF MUST test the TTL before
> forwarding to another SFF for a given Service Function Chain.  If the
> received TTL value is 1, the SFF MUST drop packets that would otherwise
> have been forwarded to another SFF, but SHALL send such packets to
> attached service functions if the SFF terminates the Service Function
> Chain.   If the TTL value is greater than 1, the SFF must decrement the
> TTL by 1 before forwarding to another SFF.   The default for originating
> an NSH packet is a TTL value of 63.
>
>
>
>
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
> *Sent:* Thursday, April 27, 2017 2:54 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] TTL field within the NSH base header
>
>
>
> Dear WG:
>
>
>
> appears to the chairs that we have consensus to add a TTL field to the
> NSH base header. We would like to propose the following changes:
>
>
>
> Section 3.2:
>
> TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a
> value of 1 for all NSH packets it receives. Decrementing by a value of 1
> from 0 shall result in a TTL value of 63. The default for originating an
> NSH packet is a TTL value of 63. The decrement SHALL occur before
> testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT
> be forwarded.
>
>
>
> Section 3.4:
>
> * *

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Apr 2017 20:47:06 +0000

Thanks for the explanation, Joel.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, April 27, 2017 4:38 PM
To: Ron Parker <[email-masked]>; Dave Dolson <[email-masked]>; James N Guichard <[email-masked]>; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

That alternative was discussed.  It also works.
However, with that alternative, if the Initial classifier is an old system (not RFC compliant), we will not get any protection from the TTL.
If we take this (admittedly slightly odd) approach to decrementing the TTL, then even though we do not recommend it, things still work with an initial classifier that generates a TTL of 0.

It is thus more robust, so the WG selected it in discussion atht einterim adn on the list.

Yours,
Joel

On 4/27/17 4:05 PM, Ron Parker wrote:
> that arrives with TTL=1 and conditioning behavior on whether the SFF 
> is the terminating SFF of the path?
>
>
>
>    Ron
>
>
>
>
>
> decrementing provides a degree of backwards compatibility with the 
> prior header format.
>
> previously "reserved".
> preceding SFF misbehaved, wouldn't it?   Why are we insistent that the
> suspect that this has been already discussed and I apologize if I 
> missed it, but if the language were simplified to say an SFF that 
> receives an NSH with TTL=1 shall not forward it to another SFF (e.g., allowing it to
> received TTL value is 1, the SFF MUST drop packets that would 
> otherwise have been forwarded to another SFF, but SHALL send such 
> packets to attached service functions if the SFF terminates the Service Function
> value of 1 for all NSH packets it receives. Decrementing by a value of 
> 1 from 0 shall result in a TTL value of 63. The default for 
> originating an NSH packet is a TTL value of 63. The decrement SHALL 
> occur before testing for 0. After decrement, if the TTL is 0, the NSH 
> packet MUST NOT be forwarded.
>
>
>
> Section 3.4:
>
> *Please review carefully and indicate support for these changes (or 
> any changes to the suggested text).*
>
> * *
>
> Thanks,
>
>
>
> Jim & Joel
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 27 Apr 2017 16:55:53 -0400

Jim,

In that case, you need to remove the word “reserved” from the replacement
text.

Cheers,
Andy

On Thu, Apr 27, 2017 at 4:37 PM, Jim Guichard <[email-masked]>
wrote:

>>> NSH packet is a TTL value
>>>

---

From: James N Guichard <[email-masked]>
Date: Thu, 27 Apr 2017 20:57:54 +0000

if there are no objections from the WG I will just change the text from 8 to 4 reserved bits ..

Jim

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Thursday, April 27, 2017 4:56 PM
To: Jim Guichard <[email-masked]>
Cc: James N Guichard <[email-masked]>; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

Jim,

In that case, you need to remove the word “reserved” from the replacement text.

Cheers,
Andy

On Thu, Apr 27, 2017 at 4:37 PM, Jim Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Yes but I also counted the other 3 bits that were reserved and are now allocated..

On Thu, Apr 27, 2017 at 4:25 PM Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:
Jim,

Cheers,
Andy

On Thu, Apr 27, 2017 at 2:54 PM, James N Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Section 3.2:

TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value

of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded.

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bits 4-9 - Reserved

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bit 3 - Reserved

   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

sfc mailing list

[email-masked]<mailto:[email-masked]>

sfc mailing list

[email-masked]<mailto:[email-masked]>

---

From: James N Guichard <[email-masked]>
Date: Thu, 27 Apr 2017 20:58:22 +0000

Sorry from 8 to 5 .. geez

Jim,

Cheers,
Andy

Cheers,
Andy

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bits 4-9 - Reserved

   Bits 0-1 - Version

   Bit 2 - OAM (O bit)

   Bit 3 - Reserved

   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

sfc mailing list

sfc mailing list

---

From: Joe Clarke <[email-masked]>
Date: Thu, 27 Apr 2017 17:55:34 -0400

> einterim adn on the list.

Thanks, Joel.  I know it was discussed, but reading the final text, I
wonder if this is just building technical debt into the protocol from
the beginning.

While this makes sense today, will it be as obvious (or as needed) in a
year?  In two?

Ron's text does seem clearer at the expense of the backward compat
explicitness.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Apr 2017 04:28:20 -0400

There are really two separate issues.
First, and most important, what behavior does the working group want?
     The discussion started with a proposal along the lines Ron 
suggests, and moved to what is in the summary Jim provided.  We are 
trying as chairs to reflect the WG agreement, and to bring this to a 
close.  Yes, we are incurring technical debt (of different forms and 
degrees) in any solution that allows backwards compatibility.  So, yes, 
we can still change this if the WG wants, but this was the rough 
consensus Jim and I saw.

Second, there is the question of whether the text is clear.  It is 
always a balancing act between explaining the motivation for everything 
at great length 9and losing the reader), vs just giving the behavior 
with no explanation (and tending to get incorrect implementations.)  We 
need to be somewhere in between.  We may not be in the right place.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Fri, 28 Apr 2017 11:49:59 +0000

For the record, I want backwards compatibility.
And also, I think it is wasteful to have a code-point that is prohibited on the wire. I've always felt IP.TTL was bad for this reason.

As for the wording, we could be explicit that TTL=0 is valid on the wire, meaning 64.

David Dolson
‎
  Original Message
From: Joel M. Halpern
Sent: Friday, April 28, 2017 4:28 AM
To: Joe Clarke; Ron Parker; Dave Dolson; James N Guichard; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

Yours,
Joel

---

From: <[email-masked]>
Date: Fri, 28 Apr 2017 13:35:48 +0000

Hi Jim, all,

I have the following comments :

·         Change "TTL" to "SFF Hop Limit (SHL)" because this field is not about a time to live but about a limit of SFF hops to be crossed.

·         I don't understand what is meant by "testing".

·         I suggest to make this change to cover the following points:

o    SHL should be configurable by the control plane.

o    Packets can be forwarded to SFs even if SHL is decremented to 0 for the terminating SFF.

o    I don't think it is a good idea to include "Decrementing by a value of 1 from 0 shall result in a TTL value of 63" because this will lead to a broken mechanism.

OLD:

NEW:
SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service chain. The initial SHL value SHOULD be configurable via the control plane; the configured initial value can be specific to a chain or all chains. If no initial value is explicitly provided, the default initial SHL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement SHL value by 1. The packet MUST NOT be forwarded to a next hop SFF if SHL is decremented to zero. SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0.

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : jeudi 27 avril 2017 20:54
À : [email-masked]
Objet : [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 28 Apr 2017 10:12:49 -0400

Jim,

This looks good to me.

Thanks,
Andy

On Thu, Apr 27, 2017 at 4:58 PM, James N Guichard <
[email-masked]> wrote:

> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Thursday, April 27, 2017 4:56 PM
> *To:* Jim Guichard <[email-masked]>
> *Cc:* James N Guichard <[email-masked]>; [email-masked]
> of 63. The decrement SHALL occur before testing for 0. After decrement, if
> the TTL is 0, the NSH packet MUST NOT be forwarded.
>
>
>
>
>
>
>
> Section 3.4:
>
>
>

---

From: Dave Dolson <[email-masked]>
Date: Fri, 28 Apr 2017 14:29:15 +0000

Med,

"SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0."
I don't think this is right.
If TTL/SHL is decremented to 0, this must not be forwarded as NSH.
I see that *receiving* a packet with SHL=1 can result in chain termination, i.e., NSH decapsulation. But not forwarding as NSH with SHL=0.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, April 28, 2017 9:36 AM
To: James N Guichard; [email-masked]
Subject: Re: [sfc] TTL field within the NSH base header

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de James N Guichard
Envoyé : jeudi 27 avril 2017 20:54
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] TTL field within the NSH base header

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel

---

From: <[email-masked]>
Date: Fri, 28 Apr 2017 14:38:19 +0000

Re-,

I see SHL as a means to prevent SFF loops. There is no value in deleting a packet after an SFF decrement the SHL to 0, but that packet is to be passed to SFs that are attached to this SFF. The packet will be forwarded after stripping the NSH header; no risk for SFF loops out there. No?

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : vendredi 28 avril 2017 16:29
À : BOUCADAIR Mohamed IMT/OLN; James N Guichard; [email-masked]
Objet : RE: TTL field within the NSH base header

Med,

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, April 28, 2017 9:36 AM
To: James N Guichard; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] TTL field within the NSH base header

Hi Jim, all,

OLD:

NEW:

Thank you.

Cheers,
Med

Dear WG:

Section 3.2:

Section 3.4:

Section 3.5:

Section 12.2.1:

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)

   Bits 0-1 - Version
   Bit 2 - OAM (O bit)
   Bit 3 - Reserved
   Bits 16-19 - Reserved

Section 12.2.3:

Thanks,

Jim & Joel