Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: sfc [mailto:[e-mail]] 代表 Linda Dunbar
> 发送时间: 2014年5月15日 6:03
> 收件人: Black, David; [e-mail]; [e-mail]
> 抄送: [e-mail]
> 主题: Re: [sfc] Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> I think that the "fragmentation and path MTU text" should be seriously discussed
> in SFC WG that is considering Service Chain Header format.
> 
> I've heard people mentioning encoding the explicit Service Chain path as
> metadata to the data packet header for some scenarios where head-end SC
> classifier node determines the chain path dynamically.

To allow the classifier to determine the service path dynamically, why not directly encoding the explicit service path information within the SR (source routing or segment routing) header (see http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00), especially the MPLS label stack based SR header if MTU is still a concern? 

Best regards,
Xiaohu

> Just imagine having IPv6 addresses encoded in the packet header to show
> explicit service chain path, which can be very long.


> Cheers,
> 
> Linda
> 
> 
> 
> 
> 
> -----Original Message-----
> From: tsv-area [mailto:[e-mail]] On Behalf Of Black, David
> Sent: Wednesday, May 14, 2014 3:53 PM
> To: [e-mail]; [e-mail]
> Subject: Fragmentation and Path MTU text in nvo3 dataplane reqts draft
> 
> <WG chair hat off>
> 
> Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains
> some text on dealing with the fragmentation and MTU effects of tunnels.
> I thought I'd ask for some early review of this text, given recent IESG excitement
> around fragmentation and Path MTU topics in another draft:
> 
> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/
> 
> I believe that the nvo3 draft is in better shape in these areas.  Nonetheless, I've
> included its current text on fragmentation and path MTU below, and (on behalf
> of the draft authors and nvo3 WG chairs) I'm looking for input on what that text
> should say and why.
> 
> In nvo3 terminology, an overlay network is an inner network that is tunneled
> over an outer underlay network.  The nvo3 WG also uses "Tenant System" as
> the term for a sender/receiver of network traffic because multi-tenancy is an
> important motivation for the WG's activities in network virtualization.
> 
> --------------------------------------
> 
> 3.5. Path MTU
> 
>        The tunnel overlay header can cause the MTU of the path to the
>        egress tunnel endpoint to be exceeded.
> 
>        IP fragmentation SHOULD be avoided for performance reasons.
> 
>        The interface MTU as seen by a Tenant System SHOULD be adjusted
> such
>        that no fragmentation is needed. This can be achieved by
>        configuration or be discovered dynamically.
> 
>        Either of the following options MUST be supported:
> 
>           o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
>             Extended MTU Path Discovery techniques such as defined in
>             [RFC4821]
> 
>           o Segmentation and reassembly support from the overlay layer
>             operations without relying on the Tenant Systems to know about
>             the end-to-end MTU
> 
>           o The underlay network MAY be designed in such a way that the
> MTU
>             can accommodate the extra tunnel overhead.
> 
> --------------------------------------
> 
> </WG chair hat off>
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc