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:
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.
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/
> 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]> 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
