Hi Carlos, please find my follow-up in-line tagged GIM>>. Regards, Greg
On Mon, Nov 27, 2017 at 3:13 PM, Carlos Pignataro (cpignata) < [email protected]> wrote: > Greg, > > On Nov 27, 2017, at 6:06 PM, Greg Mirsky <[email protected]> wrote: > > Hi Carlos, > I believe that you're co-author of the iOAM in SFC NSH draft as well. Section > 4 <https://tools.ietf.org/html/draft-brockners-sfc-ioam-nsh-00#section-4> > of the draft, in my understanding, indicates that the authors prefer using > not MD Type 2 but rather Next Protocol approach, which is very close in > "overhead" of the OOAM-DT proposal > > > Not really. A next protocol pointing to an iOAM data field type has > nothing to do with a next protocol pointing to a header of stuff, pointing > to a next protocol, with that header having a variable length with flags > including timestamps and more stuff. > > GIM>> You misunderstand or misrepresent OOAM DT header, but that is not the case here. Let's look at the Option #2 for iOAM in SFC NSH. How the actual payload type be identified if the Next Protocol of the SFC NSH refers to iOAM? And where the total length of the iOAM be if someone wants to skip iOAM data altogether to get to the payload instead of parsing the TLVs? So, from my understanding of the Option #2, iOAM should have Next Protocol and Length fields of its own. You may call it Mandatory TLV and require be the very first TLV or call it iOAM header but the fact is that they are, in my opinion, must haves for Option #2. And if that is the case, how this iOAM construct is different from OOAM-DT header? > : > > 2. Encapsulation of IOAM data fields using the "Next Protocol" > field. Each IOAM data field option (trace, proof-of-transit, and > edge-to-edge) would be specified by its own "next protocol". > > The second option has been chosen here, because it avoids the > additional layer of TLV nesting that the use of NSH MD Type 2 would > result in. In addition, the second option does not constrain IOAM > data to a maximum of 256 octets, thus allowing support for very large > deployments. > > > And the Section 4 of the iOAM in GENEVE points to issues similar that > concern authors of the above mentioned SFC NSH draft - use of sub-TLVs, > length limitations. Though the text does not explicitly proposes to use the > Next Protocol field to identify iOAM and carry iOAM data after the GENEVE > header in its own header, I recall that it was noted in the presentation to > NVO3 WG in Singapore as one of options under consideration. > > > It is always possible to add another level of indirection… > > Best, > > — Carlos. > > > Regards, > Greg > > On Sun, Nov 26, 2017 at 8:56 PM, Carlos Pignataro (cpignata) < > [email protected]> wrote: > >> >> On Nov 17, 2017, at 2:16 PM, Dan Wing <[email protected]> wrote: >> >> On Nov 16, 2017, at 6:36 PM, Greg Mirsky <[email protected]> wrote: >> >> >> Dear WG Chairs, et. al, >> in their presentation in Singapore the iOAM team pointed to interest in >> using the extra header right after the GENEVE encapsulation. I've looked at >> their proposal and believe that the OOAM header, as proposed in the >> draft-ooamdt-rtgwg-ooam-header, may suit iOAM as well as active OAM in >> GENEVE. >> >> >> As an author of iOAM, draft-ooamdt-rtgwg-ooam-header is not useful for >> iOAM. Instead, please see https://tools.ietf.org/html/dr >> aft-brockners-nvo3-ioam-geneve-00 >> >> All the overhead from draft-ooamdt-rtgwg-ooam-header is either >> duplicative or not useful. >> >> With that said, would the WG consider adoption of >> draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv? >> >> >> Procedurally, is this a WG-chair-issued adoption call? >> >> >> In draft-ooamdt-rtgwg-demand-cc-cv, I don't see a way an >> arbitrary-length payload can be sent, which is necessary to ensure the path >> MTU is sufficient to carry actual traffic. Is there some other way to meet >> that need, perhaps with the "TLVs" field in Figure 1? >> >> In draft-ooamdt-rtgwg-demand-cc-cv, its Security Considerations says it >> is 'highly unlikely' for an attacker to know the sender's Handle and >> Sequence number. However, the I-D provides no guidance for how those >> values should be securely generated. The document should provide some >> guidance such as that the Handle be a PRNG value, and perhaps also that the >> sequence number should start at a random value. >> >> In draft-ooamdt-rtgwg-demand-cc-cv, it doesn't normatively say how the >> sequence number is supposed to be handled. Does it *need* to increase >> monotonically, or can it be treated more like a transaction number (thus >> allowing random values to be assigned and mapped to the originating packet >> as desired). Are there interoperability issues with an implementation >> handling this differently -- imagine if sender has one idea of what to do, >> but receiver or an on-path packet analyzer has a different expectation. >> >> (I adjusted the subject line to reflect the call-for-adoption that I am >> responding to. It was odd to see a call for adoption mention one I-D, but >> in the text it is calling for adoption of two I-Ds.) >> >> >> Is this an NVO3 adoption call? >> >> Thanks, >> >> — Carlos. >> >> -d >> >> >> >> Regards, >> Greg >> >> On Fri, Mar 31, 2017 at 11:34 PM, Bocci, Matthew (Nokia - GB) < >> [email protected]> wrote: >> This email begins a two week poll for adoption of >> draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group. >> >> >> >> Please review the draft and send any comments to the NVO3 list. >> >> Please also indicate whether you support adoption of the draft as an NVO3 >> working group document. >> >> >> >> Simultaneously, we are also poling for any IPR that may apply to the >> draft. >> >> >> >> Authors and contributors, are you aware of any IPR that applies to this >> draft? >> >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules (see >> RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> >> If you are listed as a document author or contributor, please respond to >> >> this email stating of whether or not you are aware of any relevant >> >> IPR. The response needs to be sent to the NVO3 WG mailing list. The >> >> document will not advance to the next stage until a response >> >> has been received from each author and each contributor. >> >> >> >> This poll closes on Friday 14th April 2017. >> >> >> >> Regards >> >> >> >> Matthew and Sam >> >> >> _______________________________________________ >> 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 > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
