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
