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

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