Re: [ippm] Vote at IPPM session

Hi Al,

I am not clear about some of your suggestions.
Please see inline.

Thanks,
Tianran

> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C
> (AL)
> Sent: Wednesday, April 19, 2017 4:04 AM
> To: Brian Trammell (IETF); Frank Brockners (fbrockne)
> Cc: IPPM Chairs; ippm@ietf.org
> Subject: Re: [ippm] Vote at IPPM session
> 
> All,
> one alternative to consider, below.
> Al
> 
> > -----Original Message-----
> > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch]
> > Sent: Tuesday, April 18, 2017 3:26 PM
> > To: Frank Brockners (fbrockne)
> > Cc: adrian@olddog.co.uk; MORTON, ALFRED C (AL); IPPM Chairs;
> > ippm@ietf.org; 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. 

"Discard" the traffic? This might be available for active measurement with additional testing packets. But this iOAM is in-situ within the data packet. The discard will harm the user traffic. Or bypassing the iOAM instruction/header be better?

>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)
> > <fbrockne@cisco.com> wrote:
> > >
> > > Hi Adrian,
> > >
> > > thanks - please see inline below...
> > >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> > > Sent: Samstag, 15. April 2017 11:16
> > > To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> > > Cc: 'ALFRED MORTON' <acmorton@att.com>; 'Brian Trammell (IETF)'
> > <ietf@trammell.ch>; 'IPPM Chairs' <ippm-chairs@ietf.org>;
> > ippm@ietf.org; 'Sarah B' <sbanks@encrypted.net>
> > > 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
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm