Resposes below... On 7/8/2015 8:13 AM, Saumya Dikshit (sadikshi) wrote: > > > On 7/6/15, 10:50 PM, "Joe Touch" <[email protected]> wrote: > >> >> >> On 7/3/2015 1:12 AM, Saumya Dikshit (sadikshi) wrote: >>> >>> >>> On 7/2/15, 11:00 PM, "Joe Touch" <[email protected]> wrote: >>> >>>> >>>> >>>> On 7/1/2015 8:45 PM, Saumya Dikshit (sadikshi) wrote: >>>>> <Saumya> The encapsulation and reassembly mention in 3.1.1 is with >>>>> respect >>>>> to the outer header encapsulation (for Vxlan tunnel encap). >>>>> Frag/reassembly in underlay is performed in context of outer encap >>>>> which >>>>> is L3 based. That¹s one of the reason Vxlan scores over other >>>>> L2-tunneling >>>>> schema. >>>> >>>> That's good, but then the PTB needs to be interpreted correctly. >>>> >>>> PTB is TB. It isn't "packet larger than I'd like, but I can deal with >>>> it". There is no such signal for the latter. >>> >>> Sure, That¹s what is being conveyed here; for underlay indeed its a PTB >>> (without frag). >> >> That's not what PTB means. It doesn't mean "I can't get there optimally" >> - it means "I can't get there at all". >> >> When an ingress sends PTB rather than doing frag and reassembly, it >> makes the network more fragile. > > But isn’t it fair to communicate/relay errors generated from transit > devices > and not only the gateways, to the client-end point. ...
It is, but again, PTB means "I cannot get there at all". If you send that signal when you *can* get there with fragmentation, you're just hobbling your own network. What you want is a "packet larger than I'd prefer" or "packet larger than is optimal for me". There is currently no such ICMP message. > This may require operator intervention to configure and adjust the MTUs > across all the links in both underlay and client side network. > The public cloud operator may not want to go around these issues. It's your decision when to send PTB, but when you send it, it means only one thing. If you want it to mean "I really can't get there" but you want to also avoid fragmentation, you need to control the network over which the tunnels go. ... >>> I believe that it will serve good, if this TB which is >>> generated by any node in the path (overlay or underlay), is not >>> black-holed.= >> >> It is only helping relieve a problem you're creating by forcing the >> ingress to be more limited. Yes, it helps fix a problem you create, but >> that's not a good thing. Stop creating the problem. > > Problem is already there on the field right now. Its just that there not > enough IPv6 applications (except Skype :) ) on field to rake this up. And the Web, including Google, Twitter, and Facebook. And email. And NetFlix: http://www.internetsociety.org/deploy360/blog/2012/06/netflix-now-streaming-videos-over-ipv6/ FWIW, if you're not supporting IPv6 in this doc *right now*, I doubt it will make it past the IESG. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
