Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 3 Sep 2015 14:42:53 +0000

Hi Greg,

Nvo3 Requirement(s) should be updated to the way OAM is deployed by Operators.
Operators are deploying OAM in conjunction with Controller with l2/l3 vtep split between multiple switches and also combined.
As Requirement will drive the solution and standard to be usable operator deployment is important.

Thanks,
Deepak

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 22, 2015 at 2:11 PM
To: dekumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak, et. al,
I think that if we agree that particular OAM mechanism is needed to monitor, report defect or troubleshoot failure, then even it may be used in one of many deployment scenarios such requirement is a MUST for NVO3 OAM but is MAY for particular OAM tool set. In other words, to support particular deployment scenario NVO3 OAM protocol MUST exist as either extension of existing OAM or new mechanism/protocol. Whether it is included, used is decision outside of the scope of the requirements document.

Regards,
Greg

On Wed, Jul 22, 2015 at 2:24 PM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I have few minor comments on the draft.

NVO3 Reference model should be updated to show operator deployment(s) where L2 and L3 NVE are distributed across nodes and so to verify tenant end system to tenant end system path require de-encap and re-encap of traffic in middle nve if l3 routing is required.

In Reference Diagram we should also highlight L3 Network can be of multiple types and in case of ip, it can be ip unumbered which makes traceroute not even identifying ingress interface as all interfaces share the same ip.

Another Area requirement clarification should be done is that NVE if they are deployed with Distributed Anycast Gateway and EVPN, Tenant End system traceroute doesn’t provide any relevant information and this problem also need to be solved.

Path MTU is also very important requirement and we should also address it as part of OAM requirement also.

Again these requirement(s) should be May as they are not applicable for all scenarios.

Thanks,
Deepak

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Sep 2015 08:07:00 -0700

Hi Deepak,
I think that if a document merely describes the status quo then it should
not be on Standard track but Informational, Experimental or BCP.

Regards,
Greg

On Thu, Sep 3, 2015 at 7:42 AM, Deepak Kumar (dekumar) <[email-masked]>
wrote:

> Operators are deploying OAM in conjunction with Controller with l2/l3 vtep
> split between multiple switches and also combined.
> From: Greg Mirsky <[email-masked]>
> To: dekumar <[email-masked]>
> Cc: "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> I think that if we agree that particular OAM mechanism is needed to
> monitor, report defect or troubleshoot failure, then even it may be used in
> one of many deployment scenarios such requirement is a MUST for NVO3 OAM
> but is MAY for particular OAM tool set. In other words, to support
> particular deployment scenario NVO3 OAM protocol MUST exist as either
> extension of existing OAM or new mechanism/protocol. Whether it is
> included, used is decision outside of the scope of the requirements
> document.
>
> Regards,
> Greg
>
> On Wed, Jul 22, 2015 at 2:24 PM, Deepak Kumar (dekumar) <[email-masked]
> > wrote:
>
>> Hi,
>>
>> NVO3 Reference model should be updated to show operator deployment(s)
>> where L2 and L3 NVE are distributed across nodes and so to verify tenant
>> end system to tenant end system path require de-encap and re-encap of
>> traffic in middle nve if l3 routing is required.
>>
>> In Reference Diagram we should also highlight L3 Network can be of
>> multiple types and in case of ip, it can be ip unumbered which makes
>> traceroute not even identifying ingress interface as all interfaces share
>> the same ip.
>>
>> Another Area requirement clarification should be done is that NVE if they
>> are deployed with Distributed Anycast Gateway and EVPN, Tenant End system
>> traceroute doesn’t provide any relevant information and this problem also
>> need to be solved.
>>
>> [email-masked]

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 3 Sep 2015 15:17:40 +0000

Hi Greg,

I am talking about adding below requirement(s) in OAM requirement document so solution address all pieces of requirement.
Path MTU is also very important requirement. I am asking that these requirements are acknowledged and call out as MAY so solution can work on addressing them.

Thanks,
Deepak

Date: Thursday, September 3, 2015 at 8:07 AM

Hi Deepak,
I think that if a document merely describes the status quo then it should not be on Standard track but Informational, Experimental or BCP.

Regards,
Greg

On Thu, Sep 3, 2015 at 7:42 AM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Deepak

Hi Deepak, et. al,

Regards,
Greg

Thanks,
Deepak

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Sep 2015 08:28:27 -0700

Hi Deepak,
I believe that ALL requirements are MUST as these are requirements, not
good wishes.
As example, I can refer to OAM Requirements in BIER tat does include
requirement to support PMTUD.

Regards,
Greg

On Thu, Sep 3, 2015 at 8:17 AM, Deepak Kumar (dekumar) <[email-masked]>
wrote:

> Hi Greg,
>
> I am talking about adding below requirement(s) in OAM requirement document
> so solution address all pieces of requirement.
> Path MTU is also very important requirement. I am asking that these
> requirements are acknowledged and call out as MAY so solution can work on
> addressing them.
>
> Thanks,
> Deepak
>
>> Operators are deploying OAM in conjunction with Controller with l2/l3
>> vtep split between multiple switches and also combined.
>> On Wed, Jul 22, 2015 at 2:24 PM, Deepak Kumar (dekumar) <
>> [email-masked]> wrote:
>>
>>> Hi,
>>>
>>> Another Area requirement clarification should be done is that NVE if
>>> they are deployed with Distributed Anycast Gateway and EVPN, Tenant End
>>> system traceroute doesn’t provide any relevant information and this problem
>>> also need to be solved.
>>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 3 Sep 2015 15:39:50 +0000

Hi Greg,

https://tools.ietf.org/html/draft-ashwood-nvo3-oam-requirements-03

If I do search of above draft I see it has MAY requirements. Can we add requirement for Out of Band support so it can be controller driven also as MAY requirement.

Thanks,
Deepak

Date: Thursday, September 3, 2015 at 8:28 AM

Hi Deepak,
I believe that ALL requirements are MUST as these are requirements, not good wishes.
As example, I can refer to OAM Requirements in BIER tat does include requirement to support PMTUD.

Regards,
Greg

On Thu, Sep 3, 2015 at 8:17 AM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak, et. al,

Regards,
Greg

Thanks,
Deepak

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Sep 2015 08:53:19 -0700

Hi Deepak,
I believe that statement that uses MAY as normative language is not a
requirement. As noted earlier, everything we agree as requirements has use
MUST or SHOULD NOT. Solutions, of OAM in particular, MAY support some
requirements. I think authors and the WG should review, discuss
requirements and use of normative language.

Regards,
Greg

On Thu, Sep 3, 2015 at 8:39 AM, Deepak Kumar (dekumar) <[email-masked]>
wrote:

> If I do search of above draft I see it has MAY requirements. Can we add
> requirement for Out of Band support so it can be controller driven also as
> MAY requirement.
>
> Thanks,
> Deepak
>
>> I am talking about adding below requirement(s) in OAM requirement
>> document so solution address all pieces of requirement.
>> On Thu, Sep 3, 2015 at 7:42 AM, Deepak Kumar (dekumar) <[email-masked]
>> > wrote:
>>
>>> Hi Greg,
>>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 3 Sep 2015 16:49:46 +0000

Hi Greg,

MAY as per my understanding of RFC2119 is optional and vendor may choose to include the item.
I agree we need to discuss the requirement(s) whether it should be MAY or SHOULD as I believe SHOULD “RECOMMEND” it but not force it to be mandatory. I will prefer it to be SHOULD especially 1. requirements as that’s what asked by operators.

I will want discussion on 3 new items below

1. NVo3 OAM solution should address exact path tracing of particular traffic between two tenant edge system from nvedge and provide complete visibility of underlay network with ECMP.
2. Nvo3 OAM solution should work both in-band and out-of-band mechanism.
3. Path mtu

I will want to discuss below existing requirement(s) should be MAY or SHOULD as this is the most important requirement(s) asked by operator(s) and in multi-vendor network we need solution.

R3) NVO3 OAM MAY allow monitoring/tracing of all possible paths in
   the underlay network between a specified set of two or more NV Edge
   devices.  Using this feature, equal cost paths that traverse LAG
   and/or ECMP may be differentiated.

R14) NVO3 OAM frames MAY provide a mechanism to exercise/trace all
   data paths that result due to ECMP/LAG hops in the underlay network,
   if these paths have been known.

Thanks,

Deepak

Date: Thursday, September 3, 2015 at 8:53 AM

Hi Deepak,
I believe that statement that uses MAY as normative language is not a requirement. As noted earlier, everything we agree as requirements has use MUST or SHOULD NOT. Solutions, of OAM in particular, MAY support some requirements. I think authors and the WG should review, discuss requirements and use of normative language.

Regards,
Greg

On Thu, Sep 3, 2015 at 8:39 AM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak, et. al,

Regards,
Greg

Thanks,
Deepak

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Sep 2015 13:27:22 -0400

Deepak: 

I have asked for clarification on requirement to include of RFC2119 to WG
chairs on another document.  After I get the final input from WG chairs and
ADs I will post it here. 

Sue  

From: nvo3 [mailto:[email-masked]] On Behalf Of Deepak Kumar
(dekumar)
Sent: Thursday, September 03, 2015 12:50 PM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Greg,

MAY as per my understanding of RFC2119 is optional and vendor may choose to
include the item.

I agree we need to discuss the requirement(s) whether it should be MAY or
SHOULD as I believe SHOULD "RECOMMEND" it but not force it to be mandatory.
I will prefer it to be SHOULD especially 1. requirements as that's what
asked by operators.

1. NVo3 OAM solution should address exact path tracing of particular traffic
between two tenant edge system from nvedge and provide complete visibility
of underlay network with ECMP.

3. Path mtu

I will want to discuss below existing requirement(s) should be MAY or SHOULD
as this is the most important requirement(s) asked by operator(s) and in
multi-vendor network we need solution.

 

From: Greg Mirsky <[email-masked]>
Date: Thursday, September 3, 2015 at 8:53 AM
To: dekumar <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak, 

I believe that statement that uses MAY as normative language is not a
requirement. As noted earlier, everything we agree as requirements has use
MUST or SHOULD NOT. Solutions, of OAM in particular, MAY support some
requirements. I think authors and the WG should review, discuss requirements
and use of normative language.

Regards,

Greg

Hi Greg,

Thanks,

Deepak

To: dekumar <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak, 

I believe that ALL requirements are MUST as these are requirements, not good
wishes.

Regards,

Greg

Hi Greg,

Thanks,

Deepak

To: dekumar <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak, 

Regards,

Greg

Hi Greg,

Nvo3 Requirement(s) should be updated to the way OAM is deployed by
Operators.

As Requirement will drive the solution and standard to be usable operator
deployment is important.

Thanks,

Deepak

From: Greg Mirsky <[email-masked]>
Date: Wednesday, July 22, 2015 at 2:11 PM
To: dekumar <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak, et. al, 

I think that if we agree that particular OAM mechanism is needed to monitor,
report defect or troubleshoot failure, then even it may be used in one of
many deployment scenarios such requirement is a MUST for NVO3 OAM but is MAY
for particular OAM tool set. In other words, to support particular
deployment scenario NVO3 OAM protocol MUST exist as either extension of
existing OAM or new mechanism/protocol. Whether it is included, used is
decision outside of the scope of the requirements document.

Regards,

Greg

On Wed, Jul 22, 2015 at 2:24 PM, Deepak Kumar (dekumar) <[email-masked]>
wrote:

Hi,

NVO3 Reference model should be updated to show operator deployment(s) where
L2 and L3 NVE are distributed across nodes and so to verify tenant end
system to tenant end system path require de-encap and re-encap of traffic in
middle nve if l3 routing is required.

In Reference Diagram we should also highlight L3 Network can be of multiple
types and in case of ip, it can be ip unumbered which makes traceroute not
even identifying ingress interface as all interfaces share the same ip.

Another Area requirement clarification should be done is that NVE if they
are deployed with Distributed Anycast Gateway and EVPN, Tenant End system
traceroute doesn't provide any relevant information and this problem also
need to be solved.

Path MTU is also very important requirement and we should also address it as
part of OAM requirement also.

Again these requirement(s) should be May as they are not applicable for all
scenarios.

Thanks,

Deepak

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 3 Sep 2015 10:34:14 -0700

Inline for my comments prefixed with %sam.

Sent from my iPhone

> On Sep 3, 2015, at 9:49 AM, Deepak Kumar (dekumar) <[email-masked]> wrote:
> 
> Hi Greg,
> 
%sam - I do not agree that this is a valid one as it is imposing a requirement to provide underlay information. At best it is MAY, if someone really likes to implement.

> 2. Nvo3 OAM solution should work both in-band and out-of-band mechanism.
%sam - I am not sure what exactly you are asking. Very vague and broad statement. It is like asking OAM to work in every possible scenario without telling what those specifics are.
> 3. Path mtu
%sam- not sure what this requirement translates to.
>    and/or ECMP may be differentiated.
%sam - why you want to do it in nvo3 and not use the underlay OAM. IOW, it should be underlay OAM requirement.
>    if these paths have been known.
%sam - same comment as above
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> On Thu, Sep 3, 2015 at 8:39 AM, Deepak Kumar (dekumar) <[email-masked]> wrote:
>> Hi Greg,
>> 
>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>> On Thu, Sep 3, 2015 at 8:17 AM, Deepak Kumar (dekumar) <[email-masked]> wrote:
>>> Hi Greg,
>>> 
>>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>>> On Thu, Sep 3, 2015 at 7:42 AM, Deepak Kumar (dekumar) <[email-masked]> wrote:
>>>> Hi Greg,
>>>> 
>>>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>> On Wed, Jul 22, 2015 at 2:24 PM, Deepak Kumar (dekumar) <[email-masked]> wrote:
>>>>> Hi,
>>>>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 3 Sep 2015 18:01:34 +0000

Hi Sam,

Underlay network if it’s IP provide outer TTL expiry which can be used to get the visibility of underlay by overlay OAM, so why this requirement can’t be made SHOULD? I am fine with “MAY” if it means OAM solution will address these scenarios, but I still see that “SHOULD” is not forcing everyone to implement it.

Also Even on VTEP we have to know which egress interface traffic will go out to even figure out which underlay interface we should start tracking, all this can be achieved using TTL expiry method so why there’s objection.

Now TTL expiry does it cover exact data path within the switch is definitely up for debate based on my looking at different hardware but from requirement angle I am not asking it as MUST but asking it to be recommended that all OAM capable switch can provide underlay visibility with TTL expiry, non OAM capable switch scenario ICMP do provide atleast Switch ip address information already.
Now recommendation means that there may exist valid reason for particular circumstances to ignore which are non oam capable switches.

Inline +++DK: for others

From: Sam Aldrin <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 3, 2015 at 10:34 AM
To: dekumar <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Sent from my iPhone

On Sep 3, 2015, at 9:49 AM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Greg,

+++DK: With controller in picture which have visibility of all the path(s), an out of band solution where replies to controller provide whether all path(s) are alive or not can easily be achievable. I want atleast reference diagram which mention controller and so solution for controller can be provided.

3. Path mtu

+++DK: Fragmentation has lot of side effect in the network and thus knowing path mtu we can atleast use TCP MSS to adjust size.

+++DK: Again it depend on deployment model as in case of controller and controlled Datacenter all paths are known, so “MAY” make sense as some vendor(s) may choose to implement it and this can be done.
But I wanted thoughts from others also whether they feel this is “MAY” or “SHOULD”.

Thanks,
Deepak

Thanks,

Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak, et. al,

Regards,
Greg

Thanks,
Deepak

---

From: "Chenhao (philips)" <[email-masked]>
Date: Sun, 6 Sep 2015 01:59:29 +0000

Hi Greg,

NVO3 Requirements draft has always been on Informational (not Standard track) since its ‘-00’ version. So I do not think there is any problem if it describes the status quo.

Best regards,
Hao

From: nvo3 [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, September 03, 2015 11:07 PM
To: Deepak Kumar (dekumar)
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements

Hi Deepak,

Regards,
Greg

Thanks,
Deepak

Hi Deepak, et. al,

Regards,
Greg

Thanks,
Deepak