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. 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). > 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. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
