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. As the core networks can be brownfield ones , where as the gateways only the new addition for supporting Vxlan. 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. >If the PTB indicates a transit payload >smaller than the required smallest size, then the link is effectively no >longer supporting that protocol (e.g., 1280 for IPv6). Lesser than 1280 for sure should be taken care of in case there IPv6 enabled end points >> 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. > >Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
