Hi Tom, I realize there have been some discussions, but I think its time to reopen those discussion in 6MAN or wherever and find a way-forward. There is a strong use-case now for such capability. I am not convinced that we cannot find a work around. May be its about documentation on the potential issues and with an IESG note on the considerations before enabling such mode. It will be unfortunate, if we loose this basic capability of SRH insertion by an on-path node.
Sri On 3/27/18, 11:22 AM, "Tom Herbert" <[email protected]> wrote: >On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri <[email protected]> >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. > >Tom > >> >> But the best course still would be to have this documented clearly and >>if possible do an update to RFC8200 @ 6man as pointed below by Tom. >> >> -- >> Uma C. >> >> -----Original Message----- >> From: dmm [mailto:[email protected]] On Behalf Of Tom Herbert >> Sent: Tuesday, March 27, 2018 8:05 AM >> To: Sri Gundavelli (sgundave) <[email protected]> >> Cc: [email protected] >> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 >> >> On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave) >><[email protected]> wrote: >>> >>> >>> On 3/26/18, 5:16 PM, "Tom Herbert" <[email protected]> wrote: >>> >>>>> With regards to SR encapsulation: "this is using IP-in-IP as default. >>>>> Why not using UDP encapsulation?" >>>> >>> >>> 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. I realize there are issues with >>> ICMP error messages hitting the source etc, but we should be able to >>> document those issues and specify work arounds. I understand there >>> have been discussions on this topic before, but I hope authors will >>> find some agreements for the same. >>> >> Sri, >> >> There's been quite a bit of discussion on this on 6man list with >>reference to draft-voyer-6man-extension-header-insertion. The problem is >>that extension header insertion would violate RFC8200: "Extension >>headers (except for the Hop-by-Hop Options header) are not processed, >>inserted, or deleted by any node along a packet's delivery path". >> >> In addition to the the protocol ramifications of doing this (dealing >>with MTU, ICMP error, etc.) there were questions as to whether the >>benefit is significant enough to justify the cost, as well as what does >>it mean to define Internet protocols that only work in a "controlled >>domain". >> >> I believe 6man is the right place for further discussions on this. >> >> Tom >> >> >> >> >>> >>> Sri >>> <with no chair hat> >>> >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
