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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Aug 2016 00:31:06 +0000

Dave,

[Apologies for the delay in responding — I was on vacation]

I appreciate the healthy tension between over- and under-specifying. I do not think however that the behavior is undefined in this particular case.

To me, the specification is: “when O=1, then the packet is an OAM packet processed by an OAM module” with the corollaries regarding the OAM handing: (with the OAM module processing defined in a separate place) and (if the OAM module is NULL (does not exist), then the packet goes to the bit-bucket)

O=1 does not mean an OAM header follows. It means it’s an OAM packet. And OAM is not a protocol type, it’s a set of functionalities realized by various protocols potentially.

Thanks!

— Carlos.

On Jul 24, 2016, at 2:25 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi, Dave,

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

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.

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 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.

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,

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?

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,

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,
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.

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.

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.

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

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

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

   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.

My €0.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: Tue, 9 Aug 2016 00:31:06 +0000

Hi Dave,

With apologies for the much belated response; please find one clarification inline:

> On Jul 24, 2016, at 1:44 PM, Dave Dolson <[email-masked]> wrote:
> 
> 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

This might be the source of the confusion — if O=1, that’s not a data packet. The idea with piggyback OAM is to disturb the packet the least. If we flag a data packet as OAM, it takes a completely different processing path. 

Piggyback OAM is a data packet, O=0, with embedded instrumentation, as in draft-brockners-inband-oam-transport.

> 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.

Sorry but there seems to be a lot of unnecessary complexity in that. Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM packet in IPv4 (as for example an ICMPv4 packet, or for example a BFDoUDPoIPv4 packet.

Thanks,

— Carlos.

> 
> 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]
>     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
> 
> On 7/23/16 7:34 PM, Carlos Pignataro (cpignata) wrote:
>> 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
>>> 
>>> 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
>>>> 
>> 
>> 
> 
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Tue, 9 Aug 2016 07:25:06 +0000

I guess the confusion is that piggyback OAM is not using the OAM bit.

  Original Message
From: Carlos Pignataro (cpignata)
Sent: Tuesday, August 9, 2016 1:31 AM
To: Dave Dolson
Cc: Joel M. Halpern; Gregory Mirsky; [email-masked]; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hi Dave,

Thanks,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Aug 2016 12:03:06 +0000

“Piggyback OAM” piggybacks on a data packet, not an OAM packet.

Thanks,

— Carlos.

> On Aug 9, 2016, at 3:25 AM, Dave Dolson <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Aug 2016 09:30:43 -0400

I would normally be inclined to agree with your definition Carlos.
However, if there can be "Piggyback OAM" that has to be processed by 
SFF, then we have to make that efficient for the SFF to detect (since it 
has to check every packet for this case.

Note that the meaning of the OAM bit is whatever we say it is.
One definition is "the carried packet is an OAM packet."  But we could 
also define it more similarly to the router alert bit as in "this packet 
needs special checking at each SFF and SF."

Yours,
Joel

---

From: Loa Andersson <[email-masked]>
Date: Tue, 9 Aug 2016 15:36:27 +0200

Folks,

Maybe a naive question.

> needs special checking at each SFF and SF."

During the discussions on MPLS OAM we had as a rule of thumb, that the 
route and processing of OAM packets need to be the same as for payload
packet.

If we postulate "needs special checking at each SFF and SF" are we 
abandoning this for SFC?

/Loa
>>> This might be the source of the confusion — if O=1, that’s not a data
>>> packet. The idea with piggyback OAM is to disturb the packet the
>>> least. If we flag a data packet as OAM, it takes a completely
>>> different processing path.
>>>
>>> Piggyback OAM is a data packet, O=0, with embedded instrumentation,
>>> as in draft-brockners-inband-oam-transport.
>>>
>>> Sorry but there seems to be a lot of unnecessary complexity in that.
>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an OAM
>>> packet in IPv4 (as for example an ICMPv4 packet, or for example a
>>> BFDoUDPoIPv4 packet.
>>>
>>> Thanks,
>>>
>>> — Carlos.
>>>
>>>>
>>>>>> 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.
>>>>>>>> <[email-masked]
>>>>>>>> That's correct, with the O bit cleared; it's a data packet and
>>>>>>>> not an
>>>>>>>> OAM one.
>>>>>>>>
>>>>>>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Aug 2016 13:40:43 +0000

Joel,

> On Aug 9, 2016, at 9:30 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> However, if there can be "Piggyback OAM" that has to be processed by SFF, then we have to make that efficient for the SFF to detect (since it has to check every packet for this case.
> 
> One definition is "the carried packet is an OAM packet."  But we could also define it more similarly to the router alert bit as in "this packet needs special checking at each SFF and SF.”
> 

Indeed, it is for us to define. 

There’s an important corollary in defining an “inspect closely” / RAO-like bit, which is that it will affect processing and punt to a different path, equally for “active OAM” than to “piggy back OAM”.

Personally, I’d feel more future-safe is we do not conflate both approaches on the same bit, as there are other options for intercepting iOAM potentially, and keep an O bit to mean “OAM packet, OAM-process it”.

Do you see drawbacks with that?

Thanks,

Carlos.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Aug 2016 10:07:46 -0400

What would you suggest for intercepting iOAM?
I do think being clear about the difference in meaning, and the 
semantics of what we are defining, is quite important and helpful.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 9 Aug 2016 12:19:16 -0400

Clearly, we would like as much fate sharing as possible.

I believe most of the MPLS OAM cases where such that intermediate MPLS 
LSPs do not have to do any OAM processing.

In contrast, there are proposed SFC OAM behaviors that require 
processing at intermediate SFF.
MPLS uses TTL mechanisms to cover the few cases where it needs that. 
NSH can not do that, because the service index (which alos provides loop 
suppression) is part of the forwarding logic.  So constructing initial 
packets with different SIs will break forwarding.

Yours,
Joel

---

From: Loa Andersson <[email-masked]>
Date: Wed, 10 Aug 2016 13:19:05 +0200

Joel,

Yes I see the problem, you described (high-level) what happens in an
MPLS(-TP), but wouldn't we limit the data plane measurements we could
do if the OAM and payload packets are treated differently by the
data plane? Would it be feasible to look into a mechanism that only
do the OAM treatment at the end-points?

/Loa

On 2016-08-09 18:19, Joel M. Halpern wrote:
> MPLS uses TTL mechanisms to cover the few cases where it needs that. NSH
> can not do that, because the service index (which alos provides loop
>>>>>>>>>>     SFs nodes MUST examine the payload and take appropriate
>>>>>>>>>> action
>>>>>>>>>>  (e.g.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Aug 2016 09:59:52 -0400

There are OAM tasks where only the end-points are involved.  In that 
case, I think we would all like to see as much fate sharing with the 
normal data path as a possible.
But there are a lot of cases where that does not apply.
So we can not simply take the rule of thumb you suggested and run with it.

Yours,
Joel

On 8/10/16 7:19 AM, Loa Andersson wrote:
>>>>>>>>>> And I do not believe there’s underspecification in NSH -> O=1,
>>>>>>>>>> OAM
>>>>>>>>>> treatment, not detailed here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> — Carlos.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>              Regards,
>>>>>>>>>>>                              Greg
>>>>>>>>>>>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 10 Aug 2016 16:11:21 +0200

Hello Joel,

> normal data path as a possible.

Correct!

> But there are a lot of cases where that does not apply.

Note that in these cases the performance of the OAM will be measured,
and *NOT* the performance of the payload.

> So we can not simply take the rule of thumb you suggested and run with it.

Why would you need to measure the performance of the OAM?

Best regards, Huub.

>>>>>>>> 3) And declare that any other packet types are user packets with
>>>>>>>> OAM
>>>>>>>> TLV
>>>>>>>> information.
>>>>>>>>
>>>>>>>>>> On Jul 23, 2016, at 7:45 PM, Joel M. Halpern
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> values for single-hop BFD, multi-hop BFD, multipoint BFD,
>>>>>>>>>>>> S-BFD,
>>>>>>>>>>>> Echo
>>>>>>>>>>>> Protocol value is MPLS and O-bit set to 0x1, should be
>>>>>>>>>>>> viewed as
>>>>>>>>>>>> error
>>>>>>>>>>> an OAM packet. If the data processing does not have a handler
>>>>>>>>>>> for
>>>>>>>>>>> the
>>>>>>>>>>>> I also believe that the current OAM text in NSH is not
>>>>>>>>>>>> ambiguous
>>>>>>>>>>>> and
>>>>>>>>>>>> packets. The functionality of identifying something as OAM
>>>>>>>>>>>> is in
>>>>>>>>>>>> the
>>>>>>>>>>>>     Administration and Maintenance (OAM) message.  The
>>>>>>>>>>>> receiving
>>>>>>>>>>>>  SFF and
>>>>>>>>>>>>  O bit: when set to 0x1 indicates that data packet
>>>>>>>>>>>> identified by
>>>>>>>>>>>>  the Next
>>>>>>>>>>>> The goal is that looking at a single but it can be
>>>>>>>>>>>> understood if
>>>>>>>>>>>> it is

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Aug 2016 11:02:15 -0400

Let me try phrasing this differently.

As a general rule, it is clear that one wants measurement traffic to 
share fate with what you want to measure.  Even pure connectivity 
checking needs to share enough fate that one can reasonably conclude 
from the OAM observations what the likely status is of the underlying 
traffic connectivity.

However, the differences in constraints mean that the degree to which 
this can be done varies from case to case.
In the case of SFC, we want to use the same SPI and SI for OAM as for 
regular traffic, since that helps us hae that confidence.
And where we can, it is nice to have OAM traffic that is only perturbed 
at the end-points.
However the nature of the SFF behaviors, and more importantly the nature 
of the SF behaviors, mean that there are serious limitations on what one 
can do with active mechanisms of this sort.

Yours,
Joel

On 8/10/16 10:11 AM, Huub van Helvoort wrote:
>>>> NSH
>>>>>>>>> 2) And define a (set of) packet types for packets where the
>>>>>>>>> cotnent
>>>>>>>>> is OAM
>>>>>>>>>>> If we are very sure we don't need this, then we should write
>>>>>>>>>>> that
>>>>>>>>>>> down, and move on.
>>>>>>>>>>>
>>>>>>>>>>> Yours,
>>>>>>>>>>> Joel
>>>>>>>>>>>
>>>>>>>>>>>>> thank you for sharing your comments. If I understand
>>>>>>>>>>>>> correctly,
>>>>>>>>>>>>> you
>>>>>>>>>>>>> suggest to expose protocol types of OAM as Next Protocol
>>>>>>>>>>>>> rather
>>>>>>>>>>>>> than
>>>>>>>>>>>> Yes, the protocol field ought to register the OAM protocols
>>>>>>>>>>>> that
>>>>>>>>>>>> will be
>>>>>>>>>>>>>  which OAM type, if any, associated with a packet? I think
>>>>>>>>>>>>> that
>>>>>>>>>>>>> the
>>>>>>>>>>>>>  be ambiguous in some cases. I propose change to
>>>>>>>>>>>>> interpretation
>>>>>>>>>>>>> and
>>>>>>>>>>>>> No. If it is a data packet it does not have the O bit set
>>>>>>>>>>>>> (to 1
>>>>>>>>>>>>> or to

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Aug 2016 16:12:31 +0000

Hi Huub,
when we consider e2e and segment OAM scenarios we include not only performance measurement (PM) but fault management (FM) cases. I believe that for the FM it is important to have fate sharing for segment OAM as much as for e2e OAM. Or have I missed the point of the discussion completely?

	Regards,
		Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Wednesday, August 10, 2016 7:11 AM
To: Joel M. Halpern <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

Hello Joel,

Correct!

> But there are a lot of cases where that does not apply.

Note that in these cases the performance of the OAM will be measured, and *NOT* the performance of the payload.

Best regards, Huub.

>> do if the OAM and payload packets are treated differently by the data 
>> plane? Would it be feasible to look into a mechanism that only do the 
>> OAM treatment at the end-points?
>>
>> /Loa
>>
>>> I believe most of the MPLS OAM cases where such that intermediate 
>>> MPLS LSPs do not have to do any OAM processing.
>>>
>>> suppression) is part of the forwarding logic.  So constructing 
>>> initial packets with different SIs will break forwarding.
>>>
>>> Yours,
>>> Joel
>>>
>>>>> However, if there can be "Piggyback OAM" that has to be processed 
>>>>> by SFF, then we have to make that efficient for the SFF to detect 
>>>>> (since it has to check every packet for this case.
>>>>>
>>>>> One definition is "the carried packet is an OAM packet."  But we 
>>>>> could also define it more similarly to the router alert bit as in 
>>>>> "this packet needs special checking at each SFF and SF."
>>>>
>>>> During the discussions on MPLS OAM we had as a rule of thumb, that 
>>>> the route and processing of OAM packets need to be the same as for 
>>>> payload packet.
>>>>
>>>>>>>>  If the OAM bit O=0, this indicates the SFF MUST forward  the 
>>>>>>>> packet based solely on the SPI and SI fields, without
>>>>>>>>  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
>>>>>>>
>>>>>>> This might be the source of the confusion — if O=1, that’s not a 
>>>>>>> data packet. The idea with piggyback OAM is to disturb the 
>>>>>>> packet the least. If we flag a data packet as OAM, it takes a 
>>>>>>> completely different processing path.
>>>>>>>
>>>>>>> Piggyback OAM is a data packet, O=0, with embedded 
>>>>>>> instrumentation, as in draft-brockners-inband-oam-transport.
>>>>>>>
>>>>>>>> and Next Protocol=IPv4 there may be an OAM header following the 
>>>>>>>> IPv4 packet, located using IPv4 total length.‎ Or we could 
>>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means an 
>>>>>>> OAM packet in IPv4 (as for example an ICMPv4 packet, or for 
>>>>>>> example a
>>>>>>> BFDoUDPoIPv4 packet.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> — Carlos.
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>    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.
>>>>>>>> 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
>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>> that down, and move on.
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> 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?
>>>>>>>>>>>> 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?
>>>>>>>>>>>
>>>>>>>>>>>> *Cc:* [email-masked] <mailto:[email-masked]>; 
>>>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>>>>  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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> receiving  SFF and
>>>>>>>>>>>> action  (e.g.
>>>>>>>>>>>> identified by  the Next  Protocol type has OAM metadata 
>>>>>>>>>>>> appended.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (to 1 or to whichever other possible value for the bit :-)
>>>>>>>>>>>>
>>>>>>>>>>>> understood if it is a data packet (which can be used, 
>>>>>>>>>>>> marked, etc. to be used for OAM purposes, or not).
>>>>>>>>>>>>
>>>>>>>>>>>>  Definition of the format(s)  used by OAM metadata is 
>>>>>>>>>>>> outside the scope of this document.
>>>>>>>>>>>>  END
>>>>>>>>>>>>
>>>>>>>>>>>>     0xFE-0xFF: Experimental  END  NEW
>>>>>>>>>>>>     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.
>>>>>>>>>>>>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Aug 2016 16:28:11 +0000

Hi Joel,
in discussions within OOAM DT we've considered separation of Active OAM for SFC into SFP OAM that includes Classifier and SFFs and SFF to locally mapped SF OAM. Any other active OAM that includes SF, in my view, is more client, i.e. service, OAM than overlay network, which is the server layer, OAM. If an OAM control packet traverses the service represented by an SF, then what really was measured, again per my understanding, is the service performance including performance of the particular SFC. To clear, to separate Service OAM from SFC OAM, when using active OAM, we need to have separate OAM domains.

	Regards,
		Greg

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, August 10, 2016 8:02 AM
To: [email-masked]; Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [sfc] [Rtg-ooam-dt] Identifying OAM in NSH

As a general rule, it is clear that one wants measurement traffic to share fate with what you want to measure.  Even pure connectivity checking needs to share enough fate that one can reasonably conclude from the OAM observations what the likely status is of the underlying traffic connectivity.

However, the differences in constraints mean that the degree to which this can be done varies from case to case.
In the case of SFC, we want to use the same SPI and SI for OAM as for regular traffic, since that helps us hae that confidence.
And where we can, it is nice to have OAM traffic that is only perturbed at the end-points.
However the nature of the SFF behaviors, and more importantly the nature of the SF behaviors, mean that there are serious limitations on what one can do with active mechanisms of this sort.

Yours,
Joel

On 8/10/16 10:11 AM, Huub van Helvoort wrote:
>>> MPLS(-TP), but wouldn't we limit the data plane measurements we 
>>> could do if the OAM and payload packets are treated differently by 
>>> the data plane? Would it be feasible to look into a mechanism that 
>>> only do the OAM treatment at the end-points?
>>>
>>> /Loa
>>>
>>>>>>>>> On Jul 24, 2016, at 1:44 PM, Dave Dolson 
>>>>>>>>> <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Should the doc say,
>>>>>>>>>
>>>>>>>> This might be the source of the confusion — if O=1, that’s not 
>>>>>>>> a data packet. The idea with piggyback OAM is to disturb the 
>>>>>>>>> and Next Protocol=IPv4 there may be an OAM header following 
>>>>>>>>> the IPv4 packet, located using IPv4 total length.‎ Or we could 
>>>>>>>> Why an OAM header? Why a trailer? O=1 with IPv4, to me, means 
>>>>>>>> an OAM packet in IPv4 (as for example an ICMPv4 packet, or for 
>>>>>>>> example a
>>>>>>>> BFDoUDPoIPv4 packet.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> — Carlos.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> of naming it, both for clarity and to raise the point about 
>>>>>>>>> who needs to process the OAM information.
>>>>>>>>>
>>>>>>>>> packet type in order to recognize OAM packets that are not 
>>>>>>>>> user data packets and that it needs to process.
>>>>>>>>> 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 
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>>>> 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 
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>> used to determine whether packet should be processed as 
>>>>>>>>>>>>> OAM or data packet.
>>>>>>>>>>>>> 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?
>>>>>>>>>>>>> under-specified in the current NSH document. My proposal 
>>>>>>>>>>>>> is an attempt to make relationship between OAM and data 
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> understand something is OAM, without going the specifics 
>>>>>>>>>>>>> of an OAM handler.
>>>>>>>>>>>>>
>>>>>>>>>>>>> network’s metric and  should not leave given domain. And, 
>>>>>>>>>>>>> I believe, such packets should  be identified by the 
>>>>>>>>>>>>> protocol type of their own.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> for OAM packets. The functionality of identifying 
>>>>>>>>>>>>> something as OAM is in the O-bit, so no need to waste bits 
>>>>>>>>>>>>> in duplication.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 10 Aug 2016 12:42:49 -0400

I agree that we should keep service function OAM separate from SFP OAM.
This is one of the examples where trying to get perfect fate sharing 
would make life harder instead of easier.

Yours,
Joel

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 10 Aug 2016 18:49:40 +0200

Hello Greg,

You wrote:

> when we consider e2e and segment OAM scenarios we include not
 > only performance measurement (PM) but fault management (FM) cases.

Absolutely!

> I believe that for the FM it is important to have fate sharing
 > for segment OAM as much as for e2e OAM.

Indeed.

> Or have I missed the point of the discussion completely?

I don't thinks so.

Cheers, Huub.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 Aug 2016 17:21:38 +0000

> On Aug 10, 2016, at 12:12 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Huub,
> when we consider e2e and segment OAM scenarios we include not only performance measurement (PM) but fault management (FM) cases. I believe that for the FM it is important to have fate sharing for segment OAM as much as for e2e OAM.

I think there are some subtle distinctions in the context of service chaining, which make fate-sharing not binary.

Within SFC, I do not believe we want OAM to be processed by SFs (e.g., go through the firewall or transcoder). This is a departure from "fate-sharing", but a good one, IMHO.

Thanks,

— Carlos.