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 protected]<mailto:[email protected]>> Date: Thursday, September 3, 2015 at 10:34 AM To: dekumar <[email protected]<mailto:[email protected]>> Cc: Greg Mirsky <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements Inline for my comments prefixed with %sam. Sent from my iPhone On Sep 3, 2015, at 9:49 AM, Deepak Kumar (dekumar) <[email protected]<mailto:[email protected]>> wrote: 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. %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. +++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 %sam- not sure what this requirement translates to. +++DK: Fragmentation has lot of side effect in the network and thus knowing path mtu we can atleast use TCP MSS to adjust size. 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. %sam - why you want to do it in nvo3 and not use the underlay OAM. IOW, it should be underlay OAM requirement. 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. %sam - same comment as above +++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 From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Thursday, September 3, 2015 at 8:53 AM To: dekumar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 On Thu, Sep 3, 2015 at 8:39 AM, Deepak Kumar (dekumar) <[email protected]<mailto:[email protected]>> wrote: 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 From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Thursday, September 3, 2015 at 8:28 AM To: dekumar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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. 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 protected]<mailto:[email protected]>> 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 From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Thursday, September 3, 2015 at 8:07 AM To: dekumar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Mail regarding draft-ashwood-nvo3-oam-requirements 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 protected]<mailto:[email protected]>> wrote: 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 protected]<mailto:[email protected]>> Date: Wednesday, July 22, 2015 at 2:11 PM To: dekumar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
