Re: [ippm] Vote at IPPM session

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks, Rüdiger — I like it too, and since this is targeting a wide range of developments (i.e., “Designers of carrier protocols for IOAM” includes disparate encaps), we might want to allow for some room and not be to prescriptive since there’s different capabilities available.

That said, as we are talking about edge-to-edge path constructs, there ought to think beyond “config knob” and also include operator collaboration in the solution.

I fully agree with you on roles.

Thanks,

Carlos.

> On Apr 27, 2017, at 11:43 AM, Adrian Farrel <[e-mail]> wrote:
> 
> That's nice Rüdiger,
> 
> Although too many "designers" in the text.
> 
> Adrian
> 
>> -----Original Message-----
>> From: ippm [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: 27 April 2017 14:56
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [ippm] Vote at IPPM session
>> 
>> Hi Carlos,
>> 
>> Let me pick up Frank's proposal:
>> 
>> OLD
>> "Designers of carrier protocols for IOAM designers must consider to put
>> mechanisms in place to ensure that in-situ OAM data stays within an IOAM
>> domain.."
>> 
>> NEW
>> "Designers of carrier protocols for IOAM designers must specify mechanisms to
>> ensure that in-situ OAM data stays within an IOAM domain.."
>> 
>> I don't object that the operator is involved. But the operators task to me should
>> be to turn an "in-situ OAM configuration knob" to solve the problem. This knob
>> must be delivered by the protocol developers. "Consider" to me as a non-native
>> speaker sounds like "think about and if it's getting complex, doing nothing is a
>> valid option".
>> 
>> As mentioned earlier, relying on a firewall to me is an option I'd like to avoid.
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Carlos Pignataro (cpignata) [mailto:[e-mail]]
>> Gesendet: Sonntag, 23. April 2017 13:44
>> An: Al Morton
>> Cc: Geib, Rüdiger; [e-mail]; [e-mail]
>> Betreff: Re: [ippm] Vote at IPPM session
>> 
>> Hi,
>> 
>> This is a very useful discussion — although on the tail-end seems to be diverging
>> from the original goal. I suggest that we should probably not take this discussion
>> into all inter-domain permutations.
>> 
>> In other words, is there some case that the original text does not cover? The text
>> includes “mechanisms in place to ensure that in-situ OAM data stays within an
>> IOAM domain” and “provisions in place to ensure that IOAM data does not leak
>> beyond the edge of an IOAM domain”.
>> 
>> The idea is that an IOAM Domain should take care of considerations because of
>> e.g., increased packet sizes within its domain, and prevent leakage.
>> 
>> In many deployments, the latter (i.e., "ensuring that iOAM data stays within the
>> domain, and does not leak beyond the exit edge”) would be a natural
>> characteristic of the encapsulation. For example, when using IOAM with NSH, an
>> IOAM domain would be an SFC domain, and thus removing NSH encap will also
>> ensure IOAM does not leak. Same with VxLAN-GPE, etc.
>> 
>> But net-net, I’d recommend we define the IOAM domain behavior and not all
>> other possible views.
>> 
>> Thanks!
>> 
>> — Carlos.
>> 
>>> On Apr 19, 2017, at 4:02 PM, MORTON, ALFRED C (AL) <[e-mail]>
>> wrote:
>>> 
>>> Hi Rüdiger,
>>> short reply in-line,
>>> Al
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]]
>>>> Sent: Wednesday, April 19, 2017 3:15 AM
>>>> To: MORTON, ALFRED C (AL)
>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> Subject: AW: [ippm] Vote at IPPM session
>>>> 
>>>> Hi Al,
>>>> 
>>>> is a non-iOAM network operator able to detect standard ipv6 packets
>>>> with iOAM extensions, if the receiving operators equipment is
>>>> configured to support standard ipv6 protocol only? The pre-condition
>>>> here is "non-iOAM domain" at the receiving side. My point is, if a
>>>> domain isn't interested in supporting the iOAM extensions, is it
>>>> obliged to operate iOAM aware equipment to detect undesired traffic at
>> network boundaries?
>>> [ACM]
>>> No, an operator can let the traffic flow if they want.
>>> However, if operators find that their network is affected by traffic
>>> with iOAM data from another domain, they would be justified to discard
>>> that traffic (as long as there is a clear domain limit expressed to
>>> iOAM protocol designers of the future, as Frank has suggested).
>>> 
>>> This is the same ability afforded operators by declaring BMWG address
>>> space for isolated testing-only, or the various private network
>>> address spaces. Plenty of Net10 traffic escapes, and operators are not
>>> obliged to drop it, but they certainly can.
>>> 
>>>> 
>>>> I'm not sure, whether this is an IPPM discussion. Is there any other
>>>> IPPM protocol or packet content requiring a discard of traffic at a
>>>> domain boundary?
>>>> 
>>>> Regards,
>>>> 
>>>> Ruediger
>>>> 
>>>> 
>>>> [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.
>>>> 
>>> 
>>> _______________________________________________
>>> ippm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ippm
>> 
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>