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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Joel,

> On Jul 23, 2016, at 7:45 PM, Joel M. Halpern <[e-mail]> 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
>>> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]]
>>> *Sent:* Friday, July 22, 2016 10:10 AM
>>> *To:* Gregory Mirsky <[e-mail]
>>> <mailto:[e-mail]>>
>>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *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 <[e-mail]
>>> <mailto:[e-mail]>> 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
>>>    [e-mail] <mailto:[e-mail]>
>>>    https://www.ietf.org/mailman/listinfo/rtg-ooam-dt
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>