Subject: Re: [Rtg-ooam-dt] OOAM Ping update

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 11 Jul 2016 22:46:59 +0000

Hi Greg/Dave,

This is very important question and I have seen 2 scenarios which WG/DT should discuss and solve

Scenario 1: O bit identify OAM, but I need next protocol header to be same as real data frame and some fixed bytes of real data frame so OAM packet can be re-encapped again in hardware.
In this scenario common oam header is x byte deep after overlay encapsulation and only O bit is used to identify OAM.

--> This is scenario where L2 and L3 Overlay is not on same hardware but distributed across Leaf and Super Spine Functionality
--> It's also true when we move from Overlay to Another Technology

Scenario 2: O bit identify OAM,  Common OAM header comes after the Overlay encapsulation.
In this scenario if next protocol is OAM for example, it may cause packet to take different path that real data frame? This needs to be answered in all Data Encapsulation drafts pointing that next protocol shouldn't be used for ecmp.

Thanks,
Deepak

From: Rtg-ooam-dt <[email-masked]<mailto:[email-masked]>> on behalf of Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 11:48 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-ooam-dt] OOAM Ping update

Hi Dave,
you've asked very important question. I think that in Berlin it will be discussed with our Responsible Area Director, WG chairs (SFC, NVO3, and BIER) and those interested and involved in development of OAM protocols, solutions. There's not just one way to slice the bread but, and I agree, we should come with way to coordinate our work to avoid disconnect, duplication of our efforts.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 11, 2016 7:11 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Subject: RE: OOAM Ping update

To put the OAM header within SFC, a value is required in the "Next Protocol" field of the NSH header.

Where (in which working group and draft) should this be documented in?
Should draft-ooamdt-rtgwg-ooam-header discuss this, or should there be a document for "OOAM within NSH" ?

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Saturday, July 09, 2016 3:11 AM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Cc: Tal Mizrahi
Subject: RE: OOAM Ping update

Hi Dave,
Echo Request/Reply messages, as all OOAM messages, will have OOAM Header that, as defined in draft-ooam-rtgwf-ooam-header-00, has Length field that is the number of octets of the OOAM packet. We've discussed the have, I think in addition to the Length field, First TLV Offset field. I think that we need more input from NPU vendors whether this is something they find useful.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 08, 2016 8:11 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Subject: RE: OOAM Ping update

Looking at the packet format again, I think a total length field is required, to allow the message to be carried within frames that do not have a frame size (e.g., Ethernet or MPLS).

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, July 06, 2016 5:00 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Dave Dolson; Tal Mizrahi
Subject: OOAM Ping update

Dear All,
I've expanded IANA section and added text to how the Reply Mode field controls/instructs the responding overlay node.

Please review, share your comments, suggestions.

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 23:38:28 +0000

Also, I'm not clear on whether the OAM bit causes the Next Protocol field to be interpreted differently or not.
‎At times, the field has been called OAM Protocol when the OAM flag is set, maybe implying a different definition and different IANA reservation.

From: Deepak Kumar (dekumar)
Sent: Monday, July 11, 2016 6:47 PM
To: Gregory Mirsky; Dave Dolson; [email-masked]
Cc: Tal Mizrahi
Subject: Re: [Rtg-ooam-dt] OOAM Ping update

Hi Greg/Dave,

Thanks,
Deepak

Hi Dave,
you’ve asked very important question. I think that in Berlin it will be discussed with our Responsible Area Director, WG chairs (SFC, NVO3, and BIER) and those interested and involved in development of OAM protocols, solutions. There’s not just one way to slice the bread but, and I agree, we should come with way to coordinate our work to avoid disconnect, duplication of our efforts.

                Regards,
                                Greg

To put the OAM header within SFC, a value is required in the “Next Protocol” field of the NSH header.

Where (in which working group and draft) should this be documented in?
Should draft-ooamdt-rtgwg-ooam-header discuss this, or should there be a document for “OOAM within NSH” ?

Hi Dave,
Echo Request/Reply messages, as all OOAM messages, will have OOAM Header that, as defined in draft-ooam-rtgwf-ooam-header-00, has Length field that is the number of octets of the OOAM packet. We’ve discussed the have, I think in addition to the Length field, First TLV Offset field. I think that we need more input from NPU vendors whether this is something they find useful.

                Regards,
                                Greg

Dear All,
I’ve expanded IANA section and added text to how the Reply Mode field controls/instructs the responding overlay node.

                Regards,
                                Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 11 Jul 2016 21:53:42 -0700

Hi Deepak,
Alia and Dave pointed to the recent discussion at SFC on the interpretation
of the OAM flag. I've read it and I think that the standing definition may
benefit from the further discussion and clarification. If we talk about
active OAM, then, I assume, Next Protocol field is OAM and the OOAM Header
immediately follows. If the Next Protocol is not OAM, then, I assume, this
is passive OAM, at least from Overlay network point of view  (it could be
Service OAM ). We should clarify,explain that to the SFC and others
interested in OAM layered approach.

Regards, Greg
On Jul 11, 2016 12:47 PM, "Deepak Kumar (dekumar)" <[email-masked]>
wrote:

> Scenario 1: O bit identify OAM, but I need next protocol header to be same
> as real data frame and some fixed bytes of real data frame so OAM packet
> can be re-encapped again in hardware.
> In this scenario common oam header is x byte deep after overlay
> encapsulation and only O bit is used to identify OAM.
>
> --> This is scenario where L2 and L3 Overlay is not on same hardware but
> distributed across Leaf and Super Spine Functionality
> In this scenario if next protocol is OAM for example, it may cause packet
> to take different path that real data frame? This needs to be answered in
> all Data Encapsulation drafts pointing that next protocol shouldn't be used
> for ecmp.
>
> Thanks,
> Deepak
>
> From: Rtg-ooam-dt <[email-masked]> on behalf of Gregory
> Mirsky <[email-masked]>
> To: Dave Dolson <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> you’ve asked very important question. I think that in Berlin it will be
> discussed with our Responsible Area Director, WG chairs (SFC, NVO3, and
> BIER) and those interested and involved in development of OAM protocols,
> solutions. There’s not just one way to slice the bread but, and I agree, we
> should come with way to coordinate our work to avoid disconnect,
> duplication of our efforts.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Dave Dolson [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, July 11, 2016 7:11 AM
> *To:* Gregory Mirsky <[email-masked]>; [email-masked]
> *Cc:* Tal Mizrahi <[email-masked]>
> *Subject:* RE: OOAM Ping update
>
>
>
> *From:* Gregory Mirsky [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Saturday, July 09, 2016 3:11 AM
> *To:* Dave Dolson; [email-masked]
> *Cc:* Tal Mizrahi
> *Subject:* RE: OOAM Ping update
>
>
>
> Hi Dave,
>
> Echo Request/Reply messages, as all OOAM messages, will have OOAM Header
> that, as defined in draft-ooam-rtgwf-ooam-header-00, has Length field that
> is the number of octets of the OOAM packet. We’ve discussed the have, I
> think in addition to the Length field, First TLV Offset field. I think that
> we need more input from NPU vendors whether this is something they find
> useful.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Dave Dolson [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, July 08, 2016 8:11 AM
> *To:* Gregory Mirsky <[email-masked]>; [email-masked]
> *Cc:* Tal Mizrahi <[email-masked]>
> *Subject:* RE: OOAM Ping update
>
>
>
> Looking at the packet format again, I think a total length field is
> required, to allow the message to be carried within frames that do not have
> a frame size (e.g., Ethernet or MPLS).
>
>
>
>
>
> *From:* Gregory Mirsky [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, July 06, 2016 5:00 PM
> *To:* [email-masked]
> *Cc:* Dave Dolson; Tal Mizrahi
> *Subject:* OOAM Ping update
>
>
>
> Dear All,
>
> I’ve expanded IANA section and added text to how the Reply Mode field
> controls/instructs the responding overlay node.
>
>
>
> _______________________________________________
> Rtg-ooam-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt
>
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 12 Jul 2016 11:32:44 +0000

And also clarify what does it mean when O bit=0 and Next Protocol=OAM?

From: Greg Mirsky
Sent: Tuesday, July 12, 2016 12:53 AM
To: Deepak Kumar (dekumar)
Cc: Dave Dolson; Tal Mizrahi; [email-masked]; Gregory Mirsky
Subject: Re: [Rtg-ooam-dt] OOAM Ping update

Hi Deepak,
Alia and Dave pointed to the recent discussion at SFC on the interpretation of the OAM flag. I've read it and I think that the standing definition may benefit from the further discussion and clarification. If we talk about active OAM, then, I assume, Next Protocol field is OAM and the OOAM Header immediately follows. If the Next Protocol is not OAM, then, I assume, this is passive OAM, at least from Overlay network point of view  (it could be Service OAM ). We should clarify,explain that to the SFC and others interested in OAM layered approach.

Regards, Greg

On Jul 11, 2016 12:47 PM, "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg/Dave,

Thanks,
Deepak

Hi Dave,

                Regards,
                                Greg

Hi Dave,

                Regards,
                                Greg

Dear All,

                Regards,
                                Greg

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

---

From: David Mozes <[email-masked]>
Date: Tue, 12 Jul 2016 14:21:45 +0000

Deepak  an all
Regarding option  1 How many fixed  bytes   you think we have to take  ?

Thx
David

From: Rtg-ooam-dt [mailto:[email-masked]] On Behalf Of Deepak Kumar (dekumar)
Sent: Tuesday, July 12, 2016 1:47 AM
To: Gregory Mirsky <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]
Cc: Tal Mizrahi <[email-masked]>
Subject: Re: [Rtg-ooam-dt] OOAM Ping update

Hi Greg/Dave,

Thanks,
Deepak

Hi Dave,

                Regards,
                                Greg

Hi Dave,

                Regards,
                                Greg

Dear All,

                Regards,
                                Greg

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Tue, 12 Jul 2016 14:56:16 +0000

At least to cover IPv6 and l4 protocol to derive customer flow and actual hashing.

Thanks
Deepak

Sent from my iPhone

On Jul 12, 2016, at 7:22 AM, David Mozes <[email-masked]<mailto:[email-masked]>> wrote:

Deepak  an all

Thx
David

To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Greg/Dave,

Thanks,
Deepak

Hi Dave,

                Regards,
                                Greg

Hi Dave,

                Regards,
                                Greg

Dear All,

                Regards,
                                Greg