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

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!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On Jul 22, 2016, at 10:55, Dave Dolson <ddolson@sandvine.com> wrote:
> 
> Carlos, do you suggest so-called "piggy-back" OAM should not be provided?
> 
> 
> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] 
> Sent: Friday, July 22, 2016 10:12 AM
> To: Gregory Mirsky
> Cc: Dave Dolson; sfc@ietf.org; rtg-ooam-dt@ietf.org
> Subject: Re: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH
> 
> Dear Greg,
> 
> Please see inline. 
> 
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
> 
>> On Jul 21, 2016, at 10:49, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
>> 
>> 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.
> 
> I believe an approach like, coupled with the other proposal, this would add unnecessary complexity. 
> 
> Best,
> 
> -- Carlos. 
> 
>> 
>>   Regards,
>>       Greg
>> 
>> -----Original Message-----
>> From: Dave Dolson [mailto:ddolson@sandvine.com] 
>> Sent: Thursday, July 21, 2016 9:58 AM
>> To: Gregory Mirsky <gregory.mirsky@ericsson.com>; sfc@ietf.org
>> Cc: rtg-ooam-dt@ietf.org
>> Subject: Re: [sfc] Identifying OAM in NSH
>> 
>> 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: sfc@ietf.org
>> Cc: rtg-ooam-dt@ietf.org
>> 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.
>> 
>> 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
>> 
>> _______________________________________________
>> Rtg-ooam-dt mailing list
>> Rtg-ooam-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt