Hi Deepak, yours input, experience are very interesting. But doesn't such difference in behavior indicates that HW is not capable of processing entropy in the same manner one can achieve in SW-based (should I assume white-box) solution? If that could be the state of the art, defining behaviors, protocols that are not limited by today HW doesn't sound to me too wrong. Re-phrasing "If we agree, they will build it." Not?
Regards, Greg On Tue, Aug 9, 2016 at 4:19 PM, Deepak Kumar (dekumar) <[email protected]> wrote: > Hi Greg, > > If packet needs to be software forwarded then carry ECMP as flow entropy > is fine and we use it to software forward the packet to new Overlay tunnel, > but if packet needs to go in hardware and cover the complete ingress and > egress pipeline as real data packet, OAM needs to be hidden and bit helps > there. > So in this scenario, packet keeps getting forward as Data, and one copy is > punted to software for tracing ingress/egress path or hardware can add more > meta data as per their capability. > > Thanks, > Deepak > > From: Greg Mirsky <[email protected]> > Date: Tuesday, August 9, 2016 at 4:06 PM > To: dekumar <[email protected]> > Cc: Tom Herbert <[email protected]>, "Bocci, Matthew (Nokia - GB)" < > [email protected]>, "Carlos Pignataro (cpignata)" < > [email protected]>, NVO3 <[email protected]>, Alia Atlas <[email protected]>, > "[email protected]" <[email protected]> > > Subject: Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: > Consensus call on encap proposals) > > Hi Deepak, > I think what you're describing is not Active overlay but piggy-back OAM > and iOAM is one of examples of that. Or, perhaps, this is Service OAM > altogether. > And for ECMP, why not to have Entropy field in the overlay encapsulation > instead of "looking in customer payload". That, I believe, would be more > efficient in the fast path. > > Regards, Greg > > On Tue, Aug 9, 2016 at 3:55 PM, Deepak Kumar (dekumar) <[email protected]> > wrote: > >> Hi, >> >> Even in case of Active OAM we need O bit as Overlay splicing or stiching >> can occur for scalability reason and in that case we need to look inside >> host payload after overlay de-cap and use it to re-encap to new tunnel and >> setting the OAM bit and keep the OAM channel deep inside packet. >> If we use Next protocol as OAM then there won't be any host payload to >> handle this scenario. >> If we depend on looking in customer payload to figure out it's OAM packet >> then hashing we will get might not be same as icmp uses l3 hashing, whereas >> udp/tcp uses l4 hashing and more fields. >> >> Thanks, >> Deepak >> >> From: Rtg-ooam-dt <[email protected]> on behalf of Greg >> Mirsky <[email protected]> >> Date: Tuesday, August 9, 2016 at 3:34 PM >> To: Tom Herbert <[email protected]> >> Cc: "Bocci, Matthew (Nokia - GB)" <[email protected]>, "Carlos >> Pignataro (cpignata)" <[email protected]>, NVO3 <[email protected]>, Alia >> Atlas <[email protected]>, "[email protected]" <[email protected]> >> Subject: Re: [Rtg-ooam-dt] [nvo3] O-bit vs. OAM as Next Protocol (Re: >> Consensus call on encap proposals) >> >> Hi Tom, >> would add two notes: >> >> - being in-band OAM is not exclusively property of iOAM. Active OAM >> can be in-band if test protocols are treated as data payload (something >> that all three NVO3 protocols do); >> - ability to test and/or measure for iOAM limited by presence of the >> data traffic. Active OAM, by using dedicated test packets, doesn't have >> such limitation. >> >> My view is that combination of active, passive and in-between (e.g. iOAM) >> methods provides operators with the most comprehensive OAM tool box. >> >> Regards, Greg >> >> On Tue, Aug 9, 2016 at 12:14 PM, Tom Herbert <[email protected]> wrote: >> >>> On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata) >>> <[email protected]> wrote: >>> > >>> >> On Aug 9, 2016, at 12:28 PM, Tom Herbert <[email protected]> wrote: >>> >> >>> >> On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky <[email protected]> >>> 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 <[email protected]> >>> wrote: >>> >>>> >>> >>>> On Sun, Aug 7, 2016 at 7:02 PM, Greg Mirsky <[email protected]> >>> 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 <[email protected]> >>> 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 >>> >>>>>> <[email protected]> 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 >>> >>>>>>> [email protected] >>> >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> nvo3 mailing list >>> >>>>>> [email protected] >>> >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> nvo3 mailing list >>> >>>>> [email protected] >>> >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>>>> >>> >>> >>> >>> >>> >> >>> >> _______________________________________________ >>> >> Rtg-ooam-dt mailing list >>> >> [email protected] >>> >> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt >>> > >>> >> >> >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
