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]> 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]> > Date: Thursday, September 3, 2015 at 8:28 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 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
