Subject: [Rtg-ooam-dt] Identifying OAM in NSH

From: Gregory Mirsky <[email-masked]>
Date: Thu, 21 Jul 2016 07:01:09 +0000

Dear All,
we had very good discussion on OAM this week. We've touched on Active, Passive and Something-in-between OAM. But can NSH indicate which OAM type, if any, associated with a packet? I think that the current version of draft-ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and applicability description of the O(AM) flag and allocation of the new protocol type to be used in the Next Protocol field.

RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed solely for monitoring, measuring network's metric and should not leave given domain. And, I believe, such packets should be identified by the protocol type of their own. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM appended to data packet either at the domain's edge or on-the-fly, identified by the protocol type of the data packet carried in NSH.
Below are changes I'd like to propose:
Section 3.2 O-bit:
OLD
   O bit: when set to 0x1 indicates that this packet is an Operations,
   Administration and Maintenance (OAM) message.  The receiving SFF and
   SFs nodes MUST examine the payload and take appropriate action (e.g.
   return status information).  OAM message specifics and handling
   details are outside the scope of this document.
END
NEW
O bit: when set to 0x1 indicates that data packet identified by the Next
Protocol type has OAM metadata appended. Definition of the format(s)
used by OAM metadata is outside the scope of this document.
END

At the end of Section 3.2:
OLD
   This draft defines the following Next Protocol values:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW
   This draft defines the following Next Protocol values:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

And, consequently, section 13.2.5 in IANA Considerations section will request allocation of value 0x6 to be assigned to Active OAM protocols.

Greatly appreciate your consideration and comments.

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Thu, 21 Jul 2016 07:58:02 +0000

Greg,
This answers some of the questions I had after your presentations.

However, regarding appending OAM after the packet, NSH header doesn't have a length field that could indicate where the appended portion begins.
The current Length field is regarding the header size.

-Dave

From: Gregory Mirsky
Sent: Thursday, July 21, 2016 9:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Identifying OAM in NSH

Dear All,
we had very good discussion on OAM this week. We’ve touched on Active, Passive and Something-in-between OAM. But can NSH indicate which OAM type, if any, associated with a packet? I think that the current version of draft-ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and applicability description of the O(AM) flag and allocation of the new protocol type to be used in the Next Protocol field.

Thus, regardless of encapsulation used by OAM, it is the packet constructed solely for monitoring, measuring network’s metric and should not leave given domain. And, I believe, such packets should be identified by the protocol type of their own. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM appended to data packet either at the domain’s edge or on-the-fly, identified by the protocol type of the data packet carried in NSH.
Below are changes I’d like to propose:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 21 Jul 2016 08:48:39 +0000

Hi Dave,
thank you for the clarification. You point to the very important issue that has implication onto applicability of methods that add, prepend or append, OAM-specific information to a data packet. One way to address, I assume, is to introduce Length field that equals number of octets in Next Protocol.

	Regards,
		Greg

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, July 21, 2016 9:58 AM
To: Gregory Mirsky <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] Identifying OAM in NSH

Greg,

-Dave

From: Gregory Mirsky

Dear All,

O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. Definition of the format(s) used by OAM metadata is outside the scope of this document.
END

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

                Regards,
                                Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Jul 2016 08:10:23 +0000

Greg,

Please find some comments inline.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Jul 21, 2016, at 09:01, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,

Active, passive and something-in-between are not OAM protocol types but rather they are measuring methods. Active OAM can include a plurality of OAM protocols, including BFD, S-BFD, something-over-ip, etc.

I also believe that the current OAM text in NSH is not ambiguous and allows enough processing of the header to understand something is OAM, without going the specifics of an OAM handler.

Therefore, I oppose this change.

RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed solely for monitoring, measuring network's metric and should not leave given domain. And, I believe, such packets should be identified by the protocol type of their own.

Seems you are advocating for a single "OAM" protocol type for OAM packets. The functionality of identifying something as OAM is in the O-bit, so no need to waste bits in duplication.

Then, at some point, you have to differentiate if an OAM is, say, IP or "raw BFD" or something else. That's what the Protocol field is for. I do not see a need to add an indirection here to then have to have a protocol field inside the OAM.

OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM appended to data packet either at the domain's edge or on-the-fly, identified by the protocol type of the data packet carried in NSH.

That's correct, with the O bit cleared; it's a data packet and not an OAM one.

Protocol type has OAM metadata appended.

No. If it is a data packet it does not have the O bit set (to 1 or to whichever other possible value for the bit :-)

The goal is that looking at a single but it can be understood if it is a data packet (which can be used, marked, etc. to be used for OAM purposes, or not).

We do not want OAM direct exception processing for data packets.

Definition of the format(s)
used by OAM metadata is outside the scope of this document.
END

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

As per above I do not believe there's a single OAM protocol.

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My EUR0.02.

Thanks,

Carlos.

                Regards,
                                Greg

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Jul 2016 08:12:04 +0000

Dear Greg,

Please see inline. 

> On Jul 21, 2016, at 10:49, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Dave,

I believe an approach like, coupled with the other proposal, this would add unnecessary complexity. 

Best,

-- Carlos. 

> [email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Fri, 22 Jul 2016 08:55:44 +0000

Carlos, do you suggest so-called "piggy-back" OAM should not be provided?

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Friday, July 22, 2016 10:12 AM
To: Gregory Mirsky
Cc: Dave Dolson; [email-masked]; [email-masked]
Subject: Re: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH

Dear Greg,

Please see inline. 

Best,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Jul 2016 09:02:25 +0000

Hi Dave,

No, that's not what I am suggesting. On the contrary. 

The piggy-back OAM (let's call it iOAM without expanding the "i" for now so as to not have tangential nomenclature discussions) is being carried along for the ride in a data packet. The packet is data, not OAM. 

Much like I recall discussions about carrying time stamps in the MD, this provides you with a more generic mechanism. 

See https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#section-5

What I am suggesting is that for an OAM packet, not iOAM, O=1 and the protocol field specifies the OAM protocol. 

Thanks!

> On Jul 22, 2016, at 10:55, Dave Dolson <[email-masked]> wrote:
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 22 Jul 2016 09:24:35 +0000

Hi Carlos,
thank you for sharing your comments. If I understand correctly, you suggest to expose protocol types of OAM as Next Protocol rather than to use single Active OAM protocol type and use OOAM Header to demux OOAM type. Then, the Next Protocol registry will have to allocate values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo Request/Reply, AIS protocol, Active Performance Measurement protocol, and I’ve only listed some of AOM protocols that may be used to operate, administer and maintain SFP.
Additionally, you’ve suggested that only O-bit value to be used to determine whether packet should be processed as OAM or data packet. Hence should I expect that O-bit is set for BFD, AIS, and Echo Request/Reply payload and should not be set if the Next Protocol is neither of protocols listed above? Should such situation, i.e. Next Protocol value is MPLS and O-bit set to 0x1, should be viewed as error and the packet dropped? Or you propose that the Next Protocol takes precedence and the packet treated as data? Or packet viewed as OAM and passed to the local OAM entity? Or how to interpret situation when O-bit is cleared and the Next Protocol value is one of OAM protocols? This is the situation that, in my view, is ambiguous and under-specified in the current NSH document. My proposal is an attempt to make relationship between OAM and data packets more deterministic.

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Friday, July 22, 2016 10:10 AM
To: Gregory Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH

Greg,

RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed solely for monitoring, measuring network’s metric and should not leave given domain. And, I believe, such packets should be identified by the protocol type of their own.

OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM appended to data packet either at the domain’s edge or on-the-fly, identified by the protocol type of the data packet carried in NSH.

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My €0.02.

Thanks,

Carlos.

                Regards,
                                Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Jul 2016 16:24:54 +0000

Hi, Greg,

On Jul 22, 2016, at 10:24 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Yes, the protocol field ought to register the OAM protocols that will be used and implemented and deployed — of course not all potential variations and permutations of possible OAMs (what is AIS protocol?)

Answering all those questions (which are really slight permutations of the same question) in one shot: to me, O=0 is a data packet and O=1 is an OAM packet. If the data processing does not have a handler for the protocol in the PID, or it’s an undefined, drops to the bit bucket. Equally, if the OAM handler does not support the protocol ID carried as OAM, puff. IP can carry data or OAM for example by the way.

It does not get any simpler and unambiguous than that. What’s the advantage of moving the OAM PID further inside?

And I do not believe there’s underspecification in NSH -> O=1, OAM treatment, not detailed here.

Thanks,

— Carlos.

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Friday, July 22, 2016 10:10 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rtg-ooam-dt] Identifying OAM in NSH

Greg,

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My €0.02.

Thanks,

Carlos.

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Sat, 23 Jul 2016 17:38:50 +0000

Carlos,
I think some of what is being said in emails needs to be clarified in the document.
It still isn't crystal clear to me.

If O=1, and next protocol is IPv4, can there be an OAM header piggy-backed with the IPv4? If so, before or after?
Some drafts imply this is possible but nothing says how.

-Dave

From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 12:25 PM
To: Gregory Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Greg,

Hi Carlos,

Thanks,

— Carlos.

                Regards,
                                Greg

Greg,

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My €0.02.

Thanks,

Carlos.

                Regards,
                                Greg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 23 Jul 2016 14:45:07 -0400

There is one situation that folks are asking for that seems not to be 
clearly covered in the spec, and appears to me to be clarified by Greg's 
proposal.

We have had a couple of requests for the ability to put OAM marking on 
user data packets.  The most obvious use is to monitor how long it takes 
NSH-aware service functions to process the user packets.

If the only case where we will need this is for service function 
processing, the putting it in the TLVs, without additional markings, and 
allowing the service functions which understand the TLV to work with it 
seems sufficient.

But it is not clear to me that there is not a desire (whether it is a 
requirement is probably an important open question) for similar 
capability at SFF.  If we have situations where SFF, in passing user 
data packets, also need to perform OAM operations, then it seems to me 
that we need the OAM bit to tell the SFF to look at this.
Efforts with routers to do this with router alert options have been a 
mess. If we need the capability, it seems to me that we really want it 
in a standardized and efficient place.
If we are very sure we don't need this, then we should write that down, 
and move on.

Yours,
Joel

On 7/23/16 12:24 PM, Carlos Pignataro (cpignata) wrote:
> Hi, Greg,
>
>> On Jul 22, 2016, at 10:24 AM, Gregory Mirsky
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Carlos,
>> thank you for sharing your comments. If I understand correctly, you
>> suggest to expose protocol types of OAM as Next Protocol rather than
>> to use single Active OAM protocol type and use OOAM Header to demux
>> OOAM type. Then, the Next Protocol registry will have to allocate
>> values for single-hop BFD, multi-hop BFD, multipoint BFD, S-BFD, Echo
>> Request/Reply, AIS protocol, Active Performance Measurement protocol,
>> and I’ve only listed some of AOM protocols that may be used to
>> operate, administer and maintain SFP.
>
> Yes, the protocol field ought to register the OAM protocols that will be
> used and implemented and deployed — of course not all potential
> variations and permutations of possible OAMs (what is AIS protocol?)
>
>> Additionally, you’ve suggested that only O-bit value to be used to
>> determine whether packet should be processed as OAM or data packet.
>> Hence should I expect that O-bit is set for BFD, AIS, and Echo
>> Request/Reply payload and should not be set if the Next Protocol is
>> neither of protocols listed above? Should such situation, i.e. Next
>> Protocol value is MPLS and O-bit set to 0x1, should be viewed as error
>> and the packet dropped? Or you propose that the Next Protocol takes
>> precedence and the packet treated as data? Or packet viewed as OAM and
>> passed to the local OAM entity? Or how to interpret situation when
>> O-bit is cleared and the Next Protocol value is one of OAM protocols?
>> This is the situation that, in my view, is ambiguous and
>> under-specified in the current NSH document. My proposal is an attempt
>> to make relationship between OAM and data packets more deterministic.
>
> Answering all those questions (which are really slight permutations of
> the same question) in one shot: to me, O=0 is a data packet and O=1 is
> an OAM packet. If the data processing does not have a handler for the
> protocol in the PID, or it’s an undefined, drops to the bit bucket.
> Equally, if the OAM handler does not support the protocol ID carried as
> OAM, puff. IP can carry data or OAM for example by the way.
>
> It does not get any simpler and unambiguous than that. What’s the
> advantage of moving the OAM PID further inside?
>
>> *From:* Carlos Pignataro (cpignata) [mailto:[email-masked]]
>> *Sent:* Friday, July 22, 2016 10:10 AM
>> *To:* Gregory Mirsky <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>> <mailto:[email-masked]>
>> *Subject:* Re: [Rtg-ooam-dt] Identifying OAM in NSH
>>
>> Greg,
>>
>>
>> On Jul 21, 2016, at 09:01, Gregory Mirsky <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Dear All,
>>     we had very good discussion on OAM this week. We’ve touched on
>>     Active, Passive and Something-in-between OAM. But can NSH indicate
>>     which OAM type, if any, associated with a packet? I think that the
>>     current version of draft-ietf-sfc-nsh does not allow that and may
>>     be ambiguous in some cases. I propose change to interpretation and
>>     applicability description of the O(AM) flag and allocation of the
>>     new protocol type to be used in the Next Protocol field.
>>
>>
>>
>> Active, passive and something-in-between are not OAM protocol types
>> but rather they are measuring methods. Active OAM can include a
>> plurality of OAM protocols, including BFD, S-BFD, something-over-ip, etc.
>>
>> I also believe that the current OAM text in NSH is not ambiguous and
>> allows enough processing of the header to understand something is OAM,
>> without going the specifics of an OAM handler.
>>
>>     An Active Metric or Method depends on a dedicated measurement
>>     packet stream and observations of the stream.
>>     Thus, regardless of encapsulation used by OAM, it is the packet
>>     constructed solely for monitoring, measuring network’s metric and
>>     should not leave given domain. And, I believe, such packets should
>>     be identified by the protocol type of their own.
>>
>>
>> Seems you are advocating for a single "OAM" protocol type for OAM
>> packets. The functionality of identifying something as OAM is in the
>> O-bit, so no need to waste bits in duplication.
>>
>> Then, at some point, you have to differentiate if an OAM is, say, IP
>> or "raw BFD" or something else. That's what the Protocol field is for.
>> I do not see a need to add an indirection here to then have to have a
>> protocol field inside the OAM.
>>
>>
>>     OAM which behaves as much as Passive OAM or Something-in-between,
>>     e.g. OAM appended to data packet either at the domain’s edge or
>>     on-the-fly, identified by the protocol type of the data packet
>>     carried in NSH.
>>
>>
>> No. If it is a data packet it does not have the O bit set (to 1 or to
>> whichever other possible value for the bit :-)
>>
>> The goal is that looking at a single but it can be understood if it is
>> a data packet (which can be used, marked, etc. to be used for OAM
>> purposes, or not).
>>
>>     And, consequently, section 13.2.5 in IANA Considerations section
>>     will request allocation of value 0x6 to be assigned to Active OAM
>>     protocols.
>>
>>     [email-masked] <mailto:[email-masked]>
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Jul 2016 23:28:58 +0000

Hi, Dave,

On Jul 23, 2016, at 6:38 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

I agree that it needs to be clarified, with diagrams, and specs. However, when you say “in the document”, I do not think those details belong in the NSH document itself. The NSH, in my humble opinion, needs to say how to identify an OAM packet.

If O=1 and the next protocol is IPv4, I’d expect an IPv4 packet encapsulating the OAM (either UDP-> BFD, or ICMP, for example). With “OAM header”, do you mean the OOAM DT header? What would be the use for those extra bytes in this case?

Thanks,

— Carlos.

-Dave

From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 12:25 PM
To: Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Greg,

Hi Carlos,

Thanks,

— Carlos.

                Regards,
                                Greg

Greg,

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My €0.02.

Thanks,

Carlos.

                Regards,
                                Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Jul 2016 23:34:09 +0000

Hi, Joel,

> On Jul 23, 2016, at 7:45 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> There is one situation that folks are asking for that seems not to be clearly covered in the spec, and appears to me to be clarified by Greg's proposal.
> 
> We have had a couple of requests for the ability to put OAM marking on user data packets.  The most obvious use is to monitor how long it takes NSH-aware service functions to process the user packets.
> 

Just to make sure I understand, you are talking about the case of “piggy-back OAM”, correct?

> If the only case where we will need this is for service function processing, the putting it in the TLVs, without additional markings, and allowing the service functions which understand the TLV to work with it seems sufficient.
> 
> But it is not clear to me that there is not a desire (whether it is a requirement is probably an important open question) for similar capability at SFF.  If we have situations where SFF, in passing user data packets, also need to perform OAM operations, then it seems to me that we need the OAM bit to tell the SFF to look at this.

If you set the O bit in a user data packet, how would a system infer that’s not an OAM packet?

Thanks,

— Carlos.

> Efforts with routers to do this with router alert options have been a mess. If we need the capability, it seems to me that we really want it in a standardized and efficient place.
> If we are very sure we don't need this, then we should write that down, and move on.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 23 Jul 2016 20:01:43 -0400

Carlos,
     Yesx, I am talking about the same case that other folks are calling 
piggy-back OAM.  I wanted to describe the case instead of naming it, 
both for clarity and to raise the point about who needs to process the 
OAM information.

You ask how the SF (or even if the SFF if that applies_ will know there 
is a user packet.  I think the proposal is to use the OAM bit 
specifically to indicate that.
The result of that usage is that the SFF needs to check the packet type 
in order to recognize OAM packets that are not user data packets and 
that it needs to process.
That is an unfortunate complexity in a critical processing path.

I suspect it is this efficiency that is driving you.
Which suggests another possible interpretation.
What if
1) we set the OAM bit for any packet that needs OAM processing
2) And define a (set of) packet types for packets where the cotnent is OAM
3) And declare that any other packet types are user packets with OAM TLV 
information.

This is slightly simpler if we declare a single OAM packet type in the 
NSH header, as that avoids any ambiguity.  (Whether the device can 
actually do the OAM still depends upon it understanding the OAM packets, 
but that is true of all structures.)  This does avoid creating any 
confusion between the use of the OAM flag and the packet type.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Sun, 24 Jul 2016 11:44:01 +0000

Should the doc say,

   If the OAM bit O=0, this indicates the SFF MUST forward
   the packet based solely on the SPI and SI fields, without
    regard to next protocol or further payload headers.

   If the OAM bit O=1, this indicates the SFF ‎MUST NOT
   process the packet solely by SPI/SI forwarding but
   instead by the semantics specified by the ‎OAM
   protocol named in the Next Protocol field.

I think these paragraphs get to the optimization for SFFs,
and I think provide precise language without defining
OAM protocols.

‎Without further language, it is not specified how
to handle *any* next-protocol values when O=1.

And when specified...

As for so-called piggyback OAM, we could define
that if O=1 and Next Protocol=IPv4 there may be
an OAM header following the IPv4 packet,
located using IPv4 total length.‎ Or we could
define a new number for IPv4-with-OAM-trailer.

Note that for Next Protocol of MPLS, Ethernet or
NSH, these do not have total-length fields that
would allow trailing OAM.

Furthermore, we could say that if O=1, the SFF
MUST determine if the payload is addressed
to it, e.g., if the next IPv6 packet is addressed
to the SFF's loop-back address.

I think many of us are anxious to get to work
clarifying these things.

-Dave

  Original Message
From: Joel M. Halpern
Sent: Saturday, July 23, 2016 8:02 PM
To: Carlos Pignataro (cpignata)
Cc: Gregory Mirsky; [email-masked]; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Carlos,

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Sun, 24 Jul 2016 12:25:51 +0000

Carlos,
I don't find it satisfying  to define a protocol which says if O=1 the behavior is undefined. (Same outcome as when version!=0)

But, while the NSH draft is mute on the topic, it is fair to speculate on various  schemes.

‎Trailing an OAM header is an alternative to putting piggyback OAM in the metadata. I'm not sure where I heard it mentioned. Perhaps it was in the context of unified Overlay OAM. Logically if O=1, there must be an OAM header, right?

> If O=1 and the next protocol is IPv4, I’d expect an IPv4 packet
> encapsulating the OAM (either UDP-> BFD, or ICMP, for example).
Do you mean check to see if the embedded IPv4 packet is addressed to
the SFF itself? I.e., send the packet up the local ipv4 stack?

From: Carlos Pignataro (cpignata)
Sent: Saturday, July 23, 2016 7:29 PM
To: Dave Dolson
Cc: Gregory Mirsky; [email-masked]; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Dave,

Carlos,

Thanks,

— Carlos.

-Dave

Hi, Greg,

Hi Carlos,

Thanks,

— Carlos.

                Regards,
                                Greg

Greg,

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM

   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

My €0.02.

Thanks,

Carlos.

                Regards,
                                Greg