Greg, On Nov 27, 2017, at 6:06 PM, Greg Mirsky <[email protected]<mailto:[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. : 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]<mailto:[email protected]>> wrote: On Nov 17, 2017, at 2:16 PM, Dan Wing <[email protected]<mailto:[email protected]>> wrote: On Nov 16, 2017, at 6:36 PM, Greg Mirsky <[email protected]<mailto:[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/draft-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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
