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

[Greg Mirsky <[e-mail]>]

Hi Tom,
agree, single timestamp may be used as a marker too. But without addition
of a sequence number accuracy of your measurement will be  affected by
packet loss, re-ordering and packet duplication. And I don't think that 32
bits-long timestamp format enables high precision of delay/delay variation
calculation. AFAIK, delay measurement protocols use 64 bits-long formats,
NTP or PTPv1/truncated PTPv2. RTT would work only for bi-directional
applications, though it simplifies operations as it doesn't require clock
synchronization in the network.

Regards, Greg

On Tue, Aug 9, 2016 at 10:56 AM, Tom Herbert <[e-mail]> wrote:

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