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:56 AM, Greg Mirsky <[e-mail]> wrote:
> Hi Tom,
> I've read a proposal to apply timestamps to data packets on a fly, I believe
> submitted in the SFC WG. I cannot characterize such method as passive as,
> per my understanding, it will increase the size of the packet to accommodate
> the timestamps. The advantage of the Alternate Marking method is that once
> marker applied the measurements of packet loss and delay/delay variation
> could be performed at numerous test points along the path or even within a
> node without any changes to the packet itself. To achieve the same with
> direct timestamping, I think, would require collection of N+1 64 bits-long
> timestamps.
>
I was thinking more that only the sender would place a time stamp in
the packet. Any device on the path that sees the timestamp can
determine the one way latency from the sender as the difference of
time packet is received and the timestamp assuming the clocks are
synchronized. The timestamp allows measurements to be taken for each
packet at the cost of overhead of timestamp in packet which could be
as little four bytes. Alternatively, the timestamp could also be used
to measure RTT if it is reflected by the destination end point (like
how TCP timestamp is used)

Tom


> Regards, Greg
>
> On Tue, Aug 9, 2016 at 9:28 AM, 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. 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
>> >> >
>> >
>> >
>
>