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]> 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]> > Date: Thursday, September 3, 2015 at 8:07 AM > > To: dekumar <[email protected]> > Cc: "[email protected]" < > [email protected]>, "[email protected]" < > [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]> > 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]> >> Date: Wednesday, July 22, 2015 at 2:11 PM >> To: dekumar <[email protected]> >> Cc: "[email protected]" < >> [email protected]>, "[email protected]" < >> [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]> 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] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >> >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
