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

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

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

> 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