Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

[Tom Herbert <[e-mail]>]

On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata)
<[e-mail]> wrote:
>
>> On Aug 9, 2016, at 12:28 PM, Tom Herbert <[e-mail]> wrote:
>>
>> On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky <[e-mail]> wrote:
>>> Hi Tom,
>>> many thanks for the most informative response. I've added mu notes in-line
>>> under tag GIM>>.
>>>
>>> Regards, Greg
>>>
>>> On Mon, Aug 8, 2016 at 5:44 PM, Tom Herbert <[e-mail]> wrote:
>>>>
>>>> On Sun, Aug 7, 2016 at 7:02 PM, Greg Mirsky <[e-mail]> wrote:
>>>>> Dear Authors of the VxLAN-GPE, GUE, and GENEVE,
>>>>> all protocols under consideration use a bit flag rather than explicit
>>>>> protocol type to indicate that payload is a test packet, i.e. active
>>>>> OAM.
>>>>> I'm trying to understand the rationale of such decision. Does use of the
>>>>> bit
>>>>> flag rather than protocol type produce more efficient implementation, is
>>>>> more HW friendly? In GUE, the the field to indicate type of the payload
>>>>> even
>>>>> tagged Proto/ctype as its interpretation depends upon value of the C
>>>>> bit.
>>>>
>>>> The C-bit in GUE distinguishes data messages from control
>>>> messages.Data messages are considered to be the payload of
>>>> encapsulation, whereas control messages are about the encapsulation
>>>> itself. OAM might be one type of control message in GUE, however there
>>>> could be others. For instance if we wanted some sort of negotiation
>>>> between two endpoints to exchange capabilities or supported features
>>>> this would fit well into a control message.
>>>
>>> GIM>> Yes, what I've proposed is clearly more than just OAM channel. In
>>> fact, it is Associated Channel (ACh) that may be used by control, management
>>> and OAM. And as I've used term "Associated Channel" you'll easily recognize
>>> that I have MPLS background and draw on MPLS/MPLS-TP OAM experience. And as
>>> Generic ACh (G-ACh) is used to advertise capabilities of an LSR in RFC 7212,
>>> AC-h in NVO3 can support similar functionalities as well.
>>>>
>>>>
>>>>> But wouldn't it be simpler if all proposals used protocol type to
>>>>> identify
>>>>> OAM payload? And if the protocol type is OAM, then after the protocol
>>>>> header
>>>>> have OOAM Header, e.g. as proposed in . Then
>>>>
>>>> Each of the three protocols has a protocol next header field, however
>>>> the field is defined differently among them. The next header in GUE is
>>>> an IP protocol number, in Geneve it is an Ethertype, and VXLAN-GPE
>>>> uses a new number space. In GUE we could probably use ICMP protocol
>>>> for OAM by defining the appropriate types (that might have the
>>>> advantage of allow OAM to be generic instead of restricted to only
>>>> encapsulation). Presumably, VXLAN-GPE could define some value in the
>>>> number space for for OAM. For Geneve maybe there is an appropriate
>>>> Ethertype?
>>>>
>>>>> NVO3 protocols would be able to have common Active OAM (Fault Management
>>>>> and
>>>>> Performance Measurement) that can be used in BIER and SFC. And the bit,
>>>>> the
>>>>> bit I'd propose to redefine to be used for passive performance
>>>>> measurement
>>>>> as described in draft-ietf-bier-pmmm-oam. (Allocating two bits-long
>>>>> field
>>>>> would enable more accurate measurements using the Alternate Marking
>>>>> method).
>>>>> And these steps will enable us to develop common Active OAM and use
>>>>> passive
>>>>> performance measurement regardless, almost, of the data plane protocol
>>>>> used
>>>>> in NVO layer.
>>>>
>>>> The problem I see with trying to constrain the solution to only one or
>>>> two bits of information is that this substantially limits the
>>>> functionality. With an extensible protocol we should be able more
>>>> information to get more accurate measurement. For instance, I might
>>>> want to measure the latency of individual packets to get feedback on
>>>> path selection, correlate performance to packet loss, etc. Has the OAM
>>>> DT considered the requirements and solutions for passive performance
>>>> measurement?
>>>
>>> GIM>> Indeed, the OAM DT had considered the requirements to enable use of
>>> performance measurement methods as passive OAM. Should note that we use term
>>> "passive method" somewhat differently from the definition in RFC 7799. Such
>>> interpretation was discussed in the IPPM WG and we've agreed that if a
>>> measurement method does not change treatment of a data packet by the network
>>> (e.g. doesn't change its CoS, length or else), then the method behaves as
>>> close as passive and may be characterized as such. Measurements for a single
>>> packet are possible using the Alternate Marking method with two bits-long
>>> marker. The draft in BIER WG has such example. I've attached the
>>> presentation slides. Will be glad to answer any further questions.
>>
>> Yes, but number of specific packets I could measure is still limited
>> in some time quantum with the two bit method. Alternatively, if every
>> packet contained a timestamp for instance, then we can measure every
>> packet and filter or aggregate the measurements with arbitrary
>> granularity of our choosing.
>
> Indeed, as for example at draft-brockners-inband-oam-data-01. This is a measurement that is neither “active” nor “passive” based on the IETF definitions (where active means a probe, and passive means no change whatsoever to a packet).
>
Carlos,

Thanks for the pointer, that looks like a good basis for an extensible
and generic OAM inband measurement mechanism. I assume for IPv6 this
would be appropriate as options in HBH extension headers, have you
defined the formats for that?

Thanks,
Tom

>> BIER may have been defined with as a
>> fixed length header so that a couple of bits are all that could
>> feasibly be allocated to OAM, but this is not necessarily true for
>> other encapsulation protocols that are purposely extensible to support
>> a richer set of features.
>
> Agreed as well.
>
> Thanks,
>
> — Carlos.
>
>>
>> Tom
>>
>>>>
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>>>
>>>>> Regards, Greg
>>>>>
>>>>> On Fri, Jul 29, 2016 at 8:13 AM, Alia Atlas <[e-mail]> wrote:
>>>>>>
>>>>>> I'd like to have people focus on the key point of this thread.
>>>>>>
>>>>>> Are there serious technical objections (and specifically what are they)
>>>>>> to
>>>>>> moving forward with VXLAN-GPE as the standards-track protocol?
>>>>>>
>>>>>> Are there serious technical objections (and specifically what are they)
>>>>>> to
>>>>>> moving forward with GENEVE as the standards-track protocol?
>>>>>>
>>>>>> Are there serious technical objections (and specifically what are they)
>>>>>> to
>>>>>> moving forward with GUE as the standards-track protocol?
>>>>>>
>>>>>> We need to capture any relevant objections.  So far, there's been some
>>>>>> discussion on extensibility - with Tom Herbert providing concrete
>>>>>> concerns.
>>>>>>
>>>>>> I have concluded that almost all the authors would prefer to have no
>>>>>> standards track solution if they can't guarantee that theirs is that
>>>>>> standard.
>>>>>>
>>>>>> I do hear concerns about whether a decision will be too late.   I think
>>>>>> that a decision can only be helpful.   It goes back to when is the best
>>>>>> time
>>>>>> to plant a tree - with the answer of 20 years ago or now.
>>>>>>
>>>>>> Regards,
>>>>>> Alia
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira
>>>>>> <[e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote:
>>>>>>>>
>>>>>>>> WG
>>>>>>>>
>>>>>>>> There was a discussion in the NVO3 WG meeting in Berlin following
>>>>>>>> strong
>>>>>>>> advice from our Area Director that we need to come to a consensus on
>>>>>>>> converging on a common encapsulation. Two sets of questions were
>>>>>>>> asked:
>>>>>>>> (1) Should the WG move forward with one standards track encap?
>>>>>>>> (2) For a given encap, do you have significant technical objections?
>>>>>>>
>>>>>>>
>>>>>>> I want to inform to this mailing list that I proposed ME6E-FP and
>>>>>>> ME6E-PR
>>>>>>> at the yokohama meeting. I also have proposal M46E-FP and M46E-PR
>>>>>>> (past
>>>>>>> called SA46T).
>>>>>>>
>>>>>>> These encapsulation technologies are based on address mapping. ME6E
>>>>>>> use
>>>>>>> IPv6 address which mapping MAC address, and M46E use IPv6 address
>>>>>>> which
>>>>>>> mapping IPv4 address.
>>>>>>>
>>>>>>> I understand too many encapsulation technologies, however these my
>>>>>>> proposal are simple, and may contribute to the Internet.
>>>>>>>
>>>>>>> I believe address mapping approach is unique, so I want to propose
>>>>>>> again.
>>>>>>>
>>>>>>> sorry not the answer to the question.
>>>>>>>
>>>>>>> Naoki Matsuhira
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> nvo3 mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> nvo3 mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nvo3 mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>>>
>>>
>>>
>>
>> _______________________________________________
>> Rtg-ooam-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt
>