Re: [Idr] [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt

Hi Nagendra,

Thanks a lot for your comments, and please see replies with [Jie]

<snip>
A. If BGP speaker A is originator of the labeled IPv4 (or IPv6)
   route, A sets its BGP LSP Path MTU to the maximal value, advertises
   the labeled IPv4 (or IPv6) route with the MTU Extended Community to
   its BGP Peer (its upstream BGP LSR).

1.  Any reason to specify the MTU with maximal value on egress side?. I understand RFC3988 have the same behavior, but I am not aware of any reason. Per my understanding, setting the MTU value as the link MTU to the respective FEC value will help avoid IP fragmentation upto egress side. For example, if on egress PE, the link MTU is 1500 while the calculated Path MTU (based on this draft) is 9000, it still needs IP fragmentation on egress side.

[Jie] Actually this specification is for scenarios where the prefix advertised with label belongs to the egress node. When it's not the case, the MTU would be set to the link MTU to the prefix. I guess you are talking about advertising VPN routes, right? Yes in this case the Path MTU should be to a specific VPN prefix. This specification would be modified in next revision. 

2. After advertising the UPDATE to neighbor what will be the action when the MTU changes?.

[Jie] when the MTU changes, similar to other path attribute changes, update would be sent the the peer. In order to avoid unnecessary route flapping, we would define rules like this:
If the MTU decreases, the update SHOULD be sent to peer immediately to avoid possible packet discard.
If the MTU increases, the update SHOULD be hold down for a while, probably be sent when there is also change of other attributes.

3. Since we already have RFC3988 that helps calculate MTU with LDP, Am I assuming right that this ID helps in Inter-AS scenarios (Option B) or scenarios where RSVP is used for LSP establishment?. Should we specify that in ID?.

[Jie] As I know, RSVP also defines its mechanism of MTU discovery. Thus this draft helps in scenarios where end-to-end LSP is established with labeled BGP. The typical use cases include inter-AS VPN Option C, Seamless MPLS and Carrier's Carrier. And Option B may also be a use case. Next revision will describe the scenarios. 

Discussion about other possible use cases would be appreciated.

Many thanks,
Jie

-----Original Message-----
From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] On Behalf Of Zengqing
Sent: Monday, July 11, 2011 9:12 AM
To: idr@ietf.org; l3vpn@ietf.org
Subject: [idr] FW: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt

FYI.
Any comments will be appreciated.

Best Regards!
Qing & Jie

> -----Original Message-----
> From: i-d-announce-bounces@ietf.org
> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Monday, July 04, 2011 6:48 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-zeng-idr-bgp-mtu-extension-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>       Title           : Maximum Transmission Unit Extended Community
> for BGP-4
>       Author(s)       : Qing Zeng
>                           Jie Dong
>       Filename        : draft-zeng-idr-bgp-mtu-extension-00.txt
>       Pages           : 6
>       Date            : 2011-07-04
>
>    Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU)
>    discovery requires that IP routers have knowledge of the MTU for each
>    link to which they are connected.  As MPLS progresses, [RFC3988]
>    specifies some extensions to LDP in support of LDP LSP MTU discovery.
>    For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it
>    does not have the ability to signal the path MTU to the ingress Label
>    Switching Router (LSR).  In the absence of this functionality, the
>    MTU for the BGP LSP must be statically configured by network
>    operators or by equivalent off-line mechanisms.
>
>    This document defines the MTU Extended Community for BGP in support
>    of BGP LSP MTU discovery.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-zeng-idr-bgp-mtu-extension-00.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr