Subject: Re: [Rtg-ooam-dt] Minutes from 01/26/16 meeting

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 2 Feb 2016 15:56:06 +0000

Hi Greg,

Thanks! Please see inline.

> On Jan 30, 2016, at 9:43 AM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Carlos,
> many thanks for your thoughtful questions. My notes in-lined and tagged GIM>>.
> 
>                 Regards,
>                                 Greg
> 
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Thursday, January 28, 2016 10:29 PM
> To: Gregory Mirsky
> Cc: [email-masked] <mailto:[email-masked]>
> Subject: Re: [Rtg-ooam-dt] Minutes from 01/26/16 meeting
> 
> Thanks Greg for sending these minutes and apologies I could not join due to travel.
> 
> I have a couple of questions, please see inline.
> 
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
> 
> On Jan 27, 2016, at 15:13, Gregory Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear All,
> apologies for the delay and please feel free to add your notes, correct mine.
> ·         Overlay OAM Requirements:
> o   document is reasonably complete and stable
> o   updates may be done resulting from our work on the Gap analysis of OAM solutions
> ·         Role of telemetry
> o   will discourage use of OAM channel, which is in-band with data, for telemetry collection.
> 
> When you say "inband with data", you mean inband as fate sharing with the user flow, and not inband with the data packet, right? Though the ECMP realities make it potentially less fate-sharing?
> GIM>> Indeed, it is the fate sharing. Should add text to Requirements to explain “in-band”. Yes, ECMP may cause data and OAM flows to take different paths through the network. One example I can think of, MPLS network without Entropy Label. Should we then say “MUST try to ensure that OAM is in-band with the user flow” in the requirements document?

I still think that fate-sharing is more descriptive than ‘in-band with the user flow”, but either would work.

I’m not too keep on “MUST try to ensure” though. Well, I tried, didn’t work :-)

> 
> Also, why discourage?
> GIM>> Excessive use of the in-band OAM channel may affect user flow and thus change network behavior. For example, if operator uses passive measurement exporting massive amount of data over the OAM channel may affect network. I think that a management channel should be used in such case. Obviously it may traverse the same nodes and links but may not require the same QoS. We can refer to LMAP Reference Model with Controller, Measurement Agent and Data Collector.

I agree. So instead of discouraging, it does deserve a more specific analysis.

> 
> o   Though it MAY be used at very slow rate or with on-demand OAM. Experience with Y.1731 LMM demonstrated that collecting counters to calculate packet loss has problems, SLM preferred.
> o   AP: Deepak and David will present use cases for Telemetry over OAM Channel
> ·         Gap analysis
> o   BFD
> 
> Are we doing a gap analysis only with BFD? The working modes of BFD are very different than on demand tests like derivatives of LSP Ping or even S-BFD.
> GIM>> You are absolutely correct. We only started with the gap analysis and BFD was first mentioned in my list on the scratch pad. We will get to ping/traceroute tool, performance measurement methods and AIS.
> 

Got it. Thank you. Let’s add S-BFD as well.

Ideally we should reach the point in which we have a matrix of protocols vs. requirements.

> §  we see use case for both p2p BFD, e.g. NVO3, SFC, and p2mp BFD, e.g. BIER
> §  encapsulation choices:
> 
> Should this be encapsulation agnostic? Are these just to show use cases of how it would look in sample deployments and transports?
> GIM>> Didn’t mean data plane encapsulation in this discussion. Perhaps should find better term, would you help? But there will be differences whether BFD uses IP/UDP encapsulation or ACH. In the former, as I think, it will be encapsulated as IP protocol while in the latter case – as OAM protocol.
> 

Got it. Agreed. Instead of encapsulation, we could talk about different OAM protocols formats, or modes.

> ·         IP/UDP as per RFC 5884
> ·         ACH as per RFC 5885
> ·         to visualize how BFD would look for our targeted layers APs:
> o   Ignas will do it for NVO3
> o   Greg will do it for BIER
> o   any volunteers for SFC?
> ·         would we need BFD bootstrap similar to BFD Discriminator TLV in LSP Ping?
> 
> A larger question about the bootstrap is encap independent bootstrap as well.
> GIM>> Yes, but supported OAM encapsulations should be reflected in capability advertisement. I think we don’t have to iron details of OAM control plane but should make a note of it.
> 

Here I disagree a bit. Without bootstrapping some protocols will not work. I would not call it “control plane” since that’s a bit too generic, but initialization procedures are part of the equation.

Thanks!

Carlos.

> ·         Location of Test Point
> o   Test point (TP) – synonymous to Maintenance Point in Ethernet OAM. We agreed to use TP to refer to location of the OOAM function in a virtual node.
> o   We have discussed what can be exercised by OAM and agreed that that depends upon where TP is located, e.g. VTEP as NVE.
> o   AP: Erik to contribute text, tentatively to be included in Gap analysis document, that explains, illustrates TP and role of TP location in the particular layer.
> 
> Regards,
>                 Greg
> 
> Thanks!
> 
> Carlos.
> 
> 
> _______________________________________________
> Rtg-ooam-dt mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt <https://www.ietf.org/mailman/listinfo/rtg-ooam-dt>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 3 Feb 2016 03:41:51 +0000

Hi Carlos,
great questions and comments that really help us to clarify definitions, requirements and progress our work. Greatly appreciated.
Please find my notes in-lined and tagged GIM2>>.

                Regards,
                                Greg

PS. Would anyone likes to volunteer to start Gap Analysis doc, see below?

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, February 02, 2016 11:56 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: [Rtg-ooam-dt] Minutes from 01/26/16 meeting

Hi Greg,

On Jan 30, 2016, at 9:43 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

                Regards,
                                Greg

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Thursday, January 28, 2016 10:29 PM
To: Gregory Mirsky
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rtg-ooam-dt] Minutes from 01/26/16 meeting

On Jan 27, 2016, at 15:13, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,
apologies for the delay and please feel free to add your notes, correct mine.
•         Overlay OAM Requirements:
o   document is reasonably complete and stable
o   updates may be done resulting from our work on the Gap analysis of OAM solutions
•         Role of telemetry
o   will discourage use of OAM channel, which is in-band with data, for telemetry collection.

I still think that fate-sharing is more descriptive than ‘in-band with the user flow”, but either would work.
GIM2>> I think that both terms are valid and can be used interchangeably in the documents. OOAM Requirements seems as good place to introduce them.

I’m not too keep on “MUST try to ensure” though. Well, I tried, didn’t work :-)
GIM2>> I think that if layer encapsulation supports multi-protocol payload and includes OAM as one of payload types, then fate-sharing is assured. Would “SHOULD ensure fate sharing with data between OOAM Test Points” be realistic? I’ll add explanation on role of multi-protocol payload to the OOAM Requirements doc.

Also, why discourage?

I agree. So instead of discouraging, it does deserve a more specific analysis.
GIM2>> I’ll add, with some rewording, my text to the OOAM Requirements doc in a day or two. Please feel free to edit, expand.

•         Gap analysis
o   BFD

Ideally we should reach the point in which we have a matrix of protocols vs. requirements.
GIM2>> I think we’re ready to start on the Gap Analysis doc. Would one of us volunteer to copy text from the Scratch Pad on IP OAM tools over, shape it into better format, add content?

•  we see use case for both p2p BFD, e.g. NVO3, SFC, and p2mp BFD, e.g. BIER
•  encapsulation choices:

Got it. Agreed. Instead of encapsulation, we could talk about different OAM protocols formats, or modes.
GIM2>> Yes! Protocol formats.

•         IP/UDP as per RFC 5884
•         ACH as per RFC 5885
•         to visualize how BFD would look for our targeted layers APs:
o   Ignas will do it for NVO3
o   Greg will do it for BIER
o   any volunteers for SFC?
•         would we need BFD bootstrap similar to BFD Discriminator TLV in LSP Ping?

Here I disagree a bit. Without bootstrapping some protocols will not work. I would not call it “control plane” since that’s a bit too generic, but initialization procedures are part of the equation.
GIM2>> I think that OOAM Control plane work may be required but that is out the scope for us. Initialization of OOAM is, IMHO, in the scope of the DT. Initialization does include bootstrapping OOAM protocols at Test Points.

Thanks!

Carlos.

•         Location of Test Point

Regards,
                Greg

Thanks!

Carlos.

_______________________________________________
Rtg-ooam-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-ooam-dt

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 7 Feb 2016 15:43:51 +0000

Thanks for the thoughtful reply, Greg. A couple of follow-ups inline with bold green.

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 2, 2016 at 10:41 PM
To: Carlos Pignataro <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rtg-ooam-dt] Minutes from 01/26/16 meeting

Hi Carlos,

                Regards,
                                Greg

Hi Greg,

Hi Carlos,

                Regards,
                                Greg

CMP: I think that would be good. I think it is realistic because it is a "SHOULD"

Also, why discourage?

CMP: I get it, but I would not discourage. I'd warn about it, ensure people think about it and consider it, and make their own determinations.

CMP: Thanks!

CMP: Ack.

·         IP/UDP as per RFC 5884
·         ACH as per RFC 5885

Thanks!

Carlos.

·         Location of Test Point

Regards,
                Greg

Thanks!

Carlos.