Hi Dan, thank you for your thorough review of the cc-cv draft and very helpful comments. As I understand, the adoption call for both documents ran its course and had not brought enough support from the WG. Please find my answers and notes in-line tagged GIM>>.
Regards, Greg On Fri, Nov 17, 2017 at 11:16 AM, 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. With that said, would the WG consider adoption of > draft-ooamdt-rtgwg-ooam-header and draft-ooamdt-rtgwg-demand-cc-cv? > > 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? > GIM>> You're correct, the plan is to use Payload type TLV to create test packets of desired length. > > 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. > GIM>> Excellent, thank you! Will use your suggestions in the next version of the draft. > > 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. > GIM>> Echo request/reply can be used as synthetic traffic to measure packet loss. In such scenario the sequence number must be incremented for each transmitted packet. I agree that statement that the sequence number is monotonically increasing in course of the given test session is very helpful and will add it in the next version. I think that should set correct and unambiguous expectations on part of changes in the sequence number at the receiver of echo request or on-path analyzer. The Handle has been defined as transaction number, i.e. test session ID, and must remain unchanged through the course of the particular test session. > (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.) > > -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
