Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

From: David Mozes <[email-masked]>
Date: Fri, 1 Jan 2016 16:20:25 +0000

Hi Gregory ,
Sure i agree with you regarding the Mip's and that their is no intermedia nodes on NVO3.
However , there is a problem here
Trace Rote will  not work to the virtual network users . My Q , It is not one of our  scopes to try solving this ?

Thx
David
On Jan 1, 2016, at 12:03 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi David,
yes, verification of inter-layer mappings or control plane to data plane mappings, which is  connectivity verification, is valuable and should be among the OAM requirements. But I don’t think of these as tracing the network elements at particular layer, i.e. doing the traceroute. In NVO3 reference model I don’t find intermediate or transient nodes but only edge nodes. Hence I conclude that ping and traceroute in NVO3 environment will produce the same results.

                Happy New Year!

                                Regards,
                                                Greg

From: David Mozes [mailto:[email-masked]]
Sent: Thursday, December 31, 2015 12:11 AM
To: Gregory Mirsky; Nagendra Kumar Nainar (naikumar); [email-masked]<mailto:[email-masked]>
Cc: Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi Gregory  ,
I thinks the MIP points  that we like to trace is actually the underlay network  path between the NVEs .
One method is to  use the same ideas as in traceroute (ttl)   Erik  has some draft on that  .
There are other methods  using the OAM bits on the  uncap header e.g.  VXLAN-GPE/GENEVE    etc ..

Happy new year to all

David

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, December 30, 2015 11:41 PM
To: David Mozes <[email-masked]<mailto:[email-masked]>>; Nagendra Kumar Nainar (naikumar) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Alia Atlas ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi David,
agree, ability to trace a path is one of the most valuable troubleshooting mechanisms. I’ll make it clear in the draft.
One question regarding NVO3 environment. For example, BIER architecture is not only allows but requires that transient nodes, Bit-Forwarding Routers, used in BIER domain between Bit-Forwarding Ingress Router (BFIR) and Bit-Forwarding Egress Router (BFER). What may be viewed as transient virtual node in NVO3 reference model? If NVO3 OAM domain among NVEs, then, if I use terminology of connection-oriented networks OAM, where our MIPs to trace? I think I can see only MEPs at NVEs. Greatly appreciate you comments.

Happy New Year to All!

                Regards,
                                Greg

From: David Mozes [mailto:[email-masked]]
Sent: Tuesday, December 29, 2015 12:14 AM
To: Gregory Mirsky; Nagendra Kumar Nainar (naikumar); [email-masked]<mailto:[email-masked]>
Cc: Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi ,
I think we need
 need Route tracing

https://tools.ietf.org/html/rfc5860#page-11

Or the similar on NVO3   proposals

Thx
David
From: Rtg-ooam-dt [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Sunday, December 27, 2015 6:35 PM
To: Nagendra Kumar Nainar (naikumar) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Alia Atlas ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Nagendra,
thank you for your comments.
I agree with PMTUD. Though am not certain about the ECMP as far as pro-active monitoring if only tracing, i.e. on-demand. I think it would be great topic for us to discuss during the next call.
Would January 5th, 2016 @ 07:00 PST work? Would Tuesdays @ 07:00 PST work as regular meeting time?

                Regards,
                                Greg

From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
Sent: Thursday, December 24, 2015 5:06 AM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Cc: Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Greg,

Merry Christmas and Happy New year!!

It is a good start. A couple of points that quickly popped up are below:

1. ECMP awareness - I think we should also include ECMP awareness as one of the requirement.  We may need a right terminology that depicts ECMP and is applicable on different overlay.
2. Path MTU – I see this as one of the topic coming up with different overlay. It is better to include this in the requirement.

Will read more and share any more comments.

Thanks,
Nagendra

From: Rtg-ooam-dt <[email-masked]<mailto:[email-masked]>> on behalf of Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 23, 2015 at 11:05 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: [Rtg-ooam-dt] O-OAM Requirements

Dear All,
happy holidays, Merry Christmas and Happy New Year to All!

I put down some OAM requirements. Greatly appreciate your comments. Can we put it somewhere, somehow for everyone to edit?

You’ll notice that some requirements are explicitly point to unidirectional character of OAM. I think that services provided y an overlay network are unidirectional and bi-directional Fault Monitoring and Performance Measurement are unnecessary. Though in some cases egress node may use IP network to send notification to the ingress node. What do you think?

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 1 Jan 2016 17:02:32 +0000

Hi David,
happy New Year and thank you for your response.
For overlay network, like BIER domain, for example, Traceroute would work from BFR to BFR. I think we’ve made it work in BIER Ping and Trace<https://tools.ietf.org/html/draft-kumarzheng-bier-ping-01>
If we agree on NVO3 case, let’s look through BIER and SFC (for this one I’d propose to discuss OAM model first – is SF included in SFC OAM or SFC OAM stops at SFF and SFF to SF mapping is inter-layer OAM issue).
I’d like to keep us moving. Tuesday next week?

                Regards,
                                Greg

From: David Mozes [mailto:[email-masked]]
Sent: Friday, January 01, 2016 8:20 AM
To: Gregory Mirsky
Cc: Nagendra Kumar Nainar (naikumar); [email-masked]; Alia Atlas ([email-masked])
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Gregory ,

Thx
David

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

Thanks,
Nagendra

Dear All,

                Regards,
                                Greg

---

From: David Mozes <[email-masked]>
Date: Sun, 3 Jan 2016 08:50:22 +0000

Yes  ,sure
Do You will send  WebEx innovation for the meeting on Tuesday   ?

Thx
David

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, January 01, 2016 7:03 PM
To: David Mozes <[email-masked]>
Cc: Nagendra Kumar Nainar (naikumar) <[email-masked]>; [email-masked]; Alia Atlas ([email-masked]) <[email-masked]>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi David,

                Regards,
                                Greg

From: David Mozes [mailto:[email-masked]]
Sent: Friday, January 01, 2016 8:20 AM
To: Gregory Mirsky
Cc: Nagendra Kumar Nainar (naikumar); [email-masked]<mailto:[email-masked]>; Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi Gregory ,

Thx
David

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

Thanks,
Nagendra

Dear All,

                Regards,
                                Greg

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 4 Jan 2016 18:03:01 +0000

Hi,

Happy New year to all.
As part of requirements oam protocol should be extensible to add data plane check when control plane is involved (evpn oam).

Below is lsp draft when evpn is with mpls data plane, but evpn is also currently used in overlay.

Eg: https://datatracker.ietf.org/doc/draft-jain-bess-evpn-lsp-ping/

Thanks
Deepak

Sent from my iPhone
On Jan 1, 2016, at 9:02 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi David,

                Regards,
                                Greg

Hi Gregory ,

Thx
David

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

Thanks,
Nagendra

Dear All,

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 Jan 2016 18:14:17 +0000

Hi Deepak,
thank you for the reference to EVPN. The latest version of the requirements I've sent out with the meeting invitation now has the following new requirement:
[R13]     Overlay OAM MAY support verification of the mapping between its data plane state and client layer services.
I've tried to capture Layer-Transcending Traceroute for Overlay Networks like VXLAN Erik presented in Yokohama. Since EVPN is not explicitly in our charter, applicability of proposed solutions to EVPN would certainly be nice.

                Regards,
                                Greg

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Monday, January 04, 2016 10:03 AM
To: Gregory Mirsky
Cc: David Mozes; [email-masked]; Nagendra Kumar Nainar (naikumar); Alia Atlas ([email-masked])
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi,

Happy New year to all.

Thanks
Deepak

Sent from my iPhone
On Jan 1, 2016, at 9:02 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,
happy New Year and thank you for your response.
For overlay network, like BIER domain, for example, Traceroute would work from BFR to BFR. I think we've made it work in BIER Ping and Trace<https://tools.ietf.org/html/draft-kumarzheng-bier-ping-01>
If we agree on NVO3 case, let's look through BIER and SFC (for this one I'd propose to discuss OAM model first - is SF included in SFC OAM or SFC OAM stops at SFF and SFF to SF mapping is inter-layer OAM issue).
I'd like to keep us moving. Tuesday next week?

                Regards,
                                Greg

Hi Gregory ,

Thx
David
On Jan 1, 2016, at 12:03 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,
yes, verification of inter-layer mappings or control plane to data plane mappings, which is  connectivity verification, is valuable and should be among the OAM requirements. But I don't think of these as tracing the network elements at particular layer, i.e. doing the traceroute. In NVO3 reference model I don't find intermediate or transient nodes but only edge nodes. Hence I conclude that ping and traceroute in NVO3 environment will produce the same results.

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,
agree, ability to trace a path is one of the most valuable troubleshooting mechanisms. I'll make it clear in the draft.
One question regarding NVO3 environment. For example, BIER architecture is not only allows but requires that transient nodes, Bit-Forwarding Routers, used in BIER domain between Bit-Forwarding Ingress Router (BFIR) and Bit-Forwarding Egress Router (BFER). What may be viewed as transient virtual node in NVO3 reference model? If NVO3 OAM domain among NVEs, then, if I use terminology of connection-oriented networks OAM, where our MIPs to trace? I think I can see only MEPs at NVEs. Greatly appreciate you comments.

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

1. ECMP awareness - I think we should also include ECMP awareness as one of the requirement.  We may need a right terminology that depicts ECMP and is applicable on different overlay.
2. Path MTU - I see this as one of the topic coming up with different overlay. It is better to include this in the requirement.

Thanks,
Nagendra

Dear All,

You'll notice that some requirements are explicitly point to unidirectional character of OAM. I think that services provided y an overlay network are unidirectional and bi-directional Fault Monitoring and Performance Measurement are unnecessary. Though in some cases egress node may use IP network to send notification to the ingress node. What do you think?

                Regards,
                                Greg

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 4 Jan 2016 18:26:44 +0000

Hi Greg,

I think PMTUD is not included in this latest version. Regarding ECMP awareness, I still think it is important to be included.Let us discuss this tomorrow.

Thanks,
Nagendra

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 4, 2016 at 1:14 PM
To: "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>
Cc: David Mozes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Nagendra Kumar Nainar <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi Deepak,
thank you for the reference to EVPN. The latest version of the requirements I’ve sent out with the meeting invitation now has the following new requirement:
[R13]     Overlay OAM MAY support verification of the mapping between its data plane state and client layer services.
I’ve tried to capture Layer-Transcending Traceroute for Overlay Networks like VXLAN Erik presented in Yokohama. Since EVPN is not explicitly in our charter, applicability of proposed solutions to EVPN would certainly be nice.

                Regards,
                                Greg

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Monday, January 04, 2016 10:03 AM
To: Gregory Mirsky
Cc: David Mozes; [email-masked]<mailto:[email-masked]>; Nagendra Kumar Nainar (naikumar); Alia Atlas ([email-masked]<mailto:[email-masked]>)
Subject: Re: [Rtg-ooam-dt] O-OAM Requirements

Hi,

Happy New year to all.

Thanks
Deepak

Sent from my iPhone

                Regards,
                                Greg

Hi Gregory ,

Thx
David

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

Thanks,
Nagendra

Dear All,

                Regards,
                                Greg

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Tue, 5 Jan 2016 07:31:35 +0000

Hi,

Path Discovery in all overlay network is very important requirement. Also understanding of ingress and egress interface as packet traces through the network. So having implicit MIP in the underlay network is important for model to give useful information to end user.
This information is required to understand the actual Host - Host Path in the overlay network with underlay also it helps understand if all ECMP path between two NVE End Points are covered or not.

Once Path is known Telemetry data (queue depth, packet statistics, etc.) can also be queried along the path.

Is Telemetry Data collection along the Path of the flow is scope of the effort?

Thanks,
Deepak

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 4, 2016 at 10:14 AM
To: dekumar <[email-masked]<mailto:[email-masked]>>
Cc: David Mozes <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Nagendra Kumar Nainar (naikumar)" <[email-masked]<mailto:[email-masked]>>, "Alia Atlas ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rtg-ooam-dt] O-OAM Requirements

Hi Deepak,

                Regards,
                                Greg

Hi,

Happy New year to all.

Thanks
Deepak

Sent from my iPhone

                Regards,
                                Greg

Hi Gregory ,

Thx
David

                Happy New Year!

                                Regards,
                                                Greg

Hi Gregory  ,

Happy new year to all

David

Hi David,

Happy New Year to All!

                Regards,
                                Greg

Hi ,
I think we need
 need Route tracing

Thx
David

Hi Nagendra,

                Regards,
                                Greg

Hi Greg,

Thanks,
Nagendra

Dear All,

                Regards,
                                Greg