Re: [ippm] Vote at IPPM session

["MORTON, ALFRED C (AL)" <[e-mail]>]

All,
one alternative to consider, below.
Al

> -----Original Message-----
> From: Brian Trammell (IETF) [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2017 3:26 PM
> To: Frank Brockners (fbrockne)
> Cc: [e-mail]; MORTON, ALFRED C (AL); IPPM Chairs;
> [e-mail]; Sarah B
> Subject: Re: [ippm] Vote at IPPM session
> 
> hi Frank, all,
> 
> Speaking as an individual.
> 
> First, thanks for the scope section... this is all much more concrete
> now.
> 
> So, as I understand it, iOAM is designed first and foremost to be a
> single-network (in the sense of "coherent administrative domain")
> protocol data model with a binding to a variety of "carrier" protocols
> (the draft speaks of "transports" in the RTG-area meaning of the term,
> not the TSV-area one, so let's overload "carrier" here instead), some of
> which are also explicitly single-network, some of which less so...
> 
> I tend to share the concerns of those who've expressed discomfort with
> the "warning label approach" to ensuring that iOAM data stays single-
> network, but I'm not sure it's a problem *for the data model*. I don't
> necessarily read this "MUST NOT leave the network" as an additional
> responsibility of operators, but rather on the designers of carrier
> protocols for iOAM data. Now, some of the carrier protocols (e.g. IPv6
> extension headers) provide no such protection or support for providing
> that protection, so in that case it falls to the implementor of the iOAM
> solution to provide it... but this is rather a matter to be handled on a
> per carrier protocol basis, isn't it?
> 
> Cheers,
> Brian
[ACM] 

IOM, there is a general message to convey for all future protocol 
development. Something like "sufficient provisions should be made
to restrict the iOAM traffic to the intended domain."

We could provide guidance to interconnecting network operators,
as well, effectively allowing them to discard traffic containing 
unexpected iOAM data. This would be applicable to 
non-iOAM network operators, but might be more important for
interconnecting operators who have established their own iOAM domain.

This is similar to the approach we used for BMWG test traffic:
there are v4 and v6 address spaces dedicated for isolated test 
environments, and any packet with testing addresses observed on 
the Internet may be discarded.

regards,
Al

> 
> 
> 
> > On 18 Apr 2017, at 18:53, Frank Brockners (fbrockne)
> <[e-mail]> wrote:
> >
> > Hi Adrian,
> >
> > thanks - please see inline below...
> >
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: Samstag, 15. April 2017 11:16
> > To: Frank Brockners (fbrockne) <[e-mail]>
> > Cc: 'ALFRED MORTON' <[e-mail]>; 'Brian Trammell (IETF)'
> <[e-mail]>; 'IPPM Chairs' <[e-mail]>; [e-mail];
> 'Sarah B' <[e-mail]>
> > Subject: RE: [ippm] Vote at IPPM session
> >
> > Hi Frank, all,
> >
> > Thanks for proposing some text.
> >
> >> How about: "The operator of such a domain MUST put provisions in
> place
> >> to ensure that in-situ OAM data stays within the specific domain only
> >> (i.e., does
> > not
> >> leak beyond the edge) using for example packet filtering methods. The
> >> operator SHOULD consider potential operational impact of IOAM to
> >> mechanisms such as ECMP processing (e.g. load-balancing schemes based
> >> on packet length could be impacted by the increased packet size due
> to
> >> IOAM), path MTU (i.e. ensure that the MTU of all links within a
> domain
> >> is sufficiently large to support the
> > increased
> >> packet size due to IOAM) and ICMP message handling (i.e. in case of a
> >> native
> > IPv6
> >> transport, IOAM support for ICMPv6 Echo Request/Reply could desired
> >> which would translate into ICMPv6 extensions to enable IOAM data
> >> fields to be copied from an Echo Request message to an Echo Reply
> message)."
> >
> > Like Sarah, I think this is a start.
> >
> > I remain disappointed that it is the operators' responsibility to
> ensure various things, and not a feature of the protocol or
> implementation.
> >
> > But perhaps this text serves as a warning to the operators about using
> implementations of iOAM and so will suffice.
> >
> > ...FB: The current document is just the starting point. Let's hope
> that the WG can improve the current approach further and/or suggest
> improved text.
> >
> > I think the use of 2119 capitalisation is meaningless in this
> paragraph, and that the "SHOULD" in the second sentence should in any
> case be a "must".
> >
> > ...FB: Thanks. Will change/correct in the next revision (along with a
> set of typos that I introduced when crafting the section)
> >
> > Thanks, Frank
> >
> > Thanks,
> > Adrian