In-line.. -- Uma C. -----Original Message----- From: Tom Herbert [mailto:t...@quantonium.net] Sent: Tuesday, March 27, 2018 11:23 AM To: Uma Chunduri <uma.chund...@huawei.com> Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1
On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri <uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>> wrote: > Hi Sri, > > > > > I am really hoping we will be able to apply SRH insertion without > the > > need for IP encapsulation. At least for mobile environments within a > > closed administrative domains, there should be exceptions for > allowing > > insertion of SRH by a on-path node. > > While I see you intention to see a way to reduce the RFC8200 encap > overhead; for mobile/cellular environments I see its paramount to > have a standardized solutions because it's mostly multi-vendor equipment > from most of the operators deployments. Regardless if it's a closed > administrative domain or not. > > > However, it might be fine if it is an inside a DC (for example DC > underlay) kind of environment and this exception could be made; as the > diversity of different vendor equipment can be less. > That story line has played out many times before. In a closed system like a DC there is always seems to be some motivation to deploy proprietary solutions. Often this is done for convenience and because something is viewed as something critically needed today. In the long run, this is self defeating. It is a lot of effort to maintain proprietary protocols, and even worse can force the network into vendor lock-in. It's almost always better to stick with open standards from day one even in closed systems. [Uma]: Tom, I am all for open standards (regardless of which SDO). I was just comparing the realities of two different environments and both in MSDC or medium sized DCs today we have *both* proprietary protocols and single vendor equipment is prevalent. I was just saying this is not the case in other case (cellular). Otherwise I agree with your observation.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
