Subject: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document?

From: John Scudder <[email-masked]>
Date: Wed, 16 Nov 2011 01:01:57 -0800

Folks,

We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.

Thanks,

--John

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 16 Nov 2011 10:54:07 +0100

no support - IMO its not needed as a router could send the
PMTU/ICMP message in the downstream direction where a
LSP egress node decapsulates the packet and finally sends
it back to the ingress node;
we are doing this successfully for other labeled environments,
so i fail to see why LBGP is different in that respect.

tx,

/hannes

On 11/16/2011 10:01 AM, John Scudder wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jie Dong <[email-masked]>
Date: Wed, 16 Nov 2011 13:40:32 +0000

Hi Hannes, 

Thanks for your comment. Could you help provide in which document is this solution specified?

RFC1191(PMTU discovery) says: "It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area..." And since as we know other label sigaling protocols have defined the control plane based MTU discovery, it would be reasonble to also have this mechanism for labeled bgp. 

Also for some inter-AS scenarios data plane MTU discovery   mechanism may not be allowed. 

Regards,
Jie
________________________________________
From: [email-masked] [[email-masked]] on behalf of Hannes Gredler [[email-masked]]
Sent: Wednesday, November 16, 2011 17:54
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document?

tx,

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 01:13:47 +0100

If I understand justification for this work it dates back to invention 
of "mpls mtu" command on routing operating system where for whatever 
reason when hosts can not detect the right MTU router performing MPLS 
imposition had to fragment IPv4 packets in order to fit bigger frames 
into smaller LSP pipes.

If we just consider that reason while setting such MTU may be 
administratively easy in given domain the problem becomes harder across 
domains as you need to lift the old fashion telephone and ask Mr. Peer 
what is your min MTU of today. Moreover when such MTU changes Mr Peer 
must inform you or your users starts crying so you are calling him again.

I see not much harm to automate such process and carry MTU value in BGP 
3107. Other protocols have already been extended to perform MTU 
propagation - example RSVP:

http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp

Said all of this I am much more in favor to detect MTU host to host in 
the data plane. And if this is broken for whatever reason we should 
focus on fixing that problem rather then patching it on routers. The 
latter while was/is possible for IPv4 (even when neglecting presence of 
DF bit) in the light of upcoming IPv6 which sort of does not allow 
network fragmentation may be a bit hard.

Regards,
R.

>> We have received a request from the authors to adopt
>> ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send
>> your comments to the list. The deadline for comments is December 5,
>> 2011 at noon EST.
>>
>> Thanks,
>>
>> --John

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 17 Nov 2011 02:12:39 +0100

On Thu, Nov 17, 2011 at 01:13:47AM +0100, Robert Raszuk wrote:
| If I understand justification for this work it dates back to invention 
| of "mpls mtu" command on routing operating system where for whatever 
| reason when hosts can not detect the right MTU router performing MPLS 
| imposition had to fragment IPv4 packets in order to fit bigger frames 
| into smaller LSP pipes.
| 
| If we just consider that reason while setting such MTU may be 
| administratively easy in given domain the problem becomes harder across 
| domains as you need to lift the old fashion telephone and ask Mr. Peer 
| what is your min MTU of today. Moreover when such MTU changes Mr Peer 
| must inform you or your users starts crying so you are calling him again.

wouldn't a more straightforward to make PMTU to work between
end-systems and fix "whatever reason" ?
 
| I see not much harm to automate such process and carry MTU value in BGP 
| 3107. 

the part that i do not understand is how an implementation shall compute
the MTU of a core iBGP segment ? unless all of the underlying link MTU gets
signaled in a protocol like LDP|IGP there is no way to "automate"
that process;

| Other protocols have already been extended to perform MTU 
| propagation - example RSVP:
| 
| http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp

good example: i'd argue that the brief difference is that RSVP usually is
deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) along the
LSP and iBGP is not.

| Said all of this I am much more in favor to detect MTU host to host in 
| the data plane. And if this is broken for whatever reason we should 
| focus on fixing that problem rather then patching it on routers. The 
| latter while was/is possible for IPv4 (even when neglecting presence of 
| DF bit) in the light of upcoming IPv6 which sort of does not allow 
| network fragmentation may be a bit hard.

| 
| >no support - IMO its not needed as a router could send the
| >PMTU/ICMP message in the downstream direction where a
| >LSP egress node decapsulates the packet and finally sends
| >it back to the ingress node;
| >we are doing this successfully for other labeled environments,
| >so i fail to see why LBGP is different in that respect.
| >
| >tx,
| >
| >/hannes
| >
| >On 11/16/2011 10:01 AM, John Scudder wrote:
| >>Folks,
| >>
| >>We have received a request from the authors to adopt
| >>ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document. Please send
| >>your comments to the list. The deadline for comments is December 5,
| >>2011 at noon EST.
| >>
| >>Thanks,
| >>
| >>--John
| >>_______________________________________________
| >>Idr mailing list
| >>[email-masked]
| >>https://www.ietf.org/mailman/listinfo/idr
| >_______________________________________________
| >Idr mailing list
| >[email-masked]
| >https://www.ietf.org/mailman/listinfo/idr
| >
| >
|

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 17 Nov 2011 02:15:24 +0100

On Wed, Nov 16, 2011 at 01:40:32PM +0000, Jie Dong wrote:
| Hi Hannes, 
| 
| Thanks for your comment. Could you help provide in which document is this solution specified?
| 
| RFC1191(PMTU discovery) says: "It is expected that future routing protocols will be able to provide accurate PMTU information within a routing area..." And since as we know other label sigaling protocols have defined the control plane based MTU discovery, it would be reasonble to also have this mechanism for labeled bgp. 

can you elaborate how the MTU shall be computed for iBGP path which consists
of a (more than one) set of links ?
 
| Also for some inter-AS scenarios data plane MTU discovery   mechanism may not be allowed. 
| 
| Regards,
| Jie
| ________________________________________
| From: [email-masked] [[email-masked]] on behalf of Hannes Gredler [[email-masked]]
| Sent: Wednesday, November 16, 2011 17:54
| To: John Scudder
| Cc: [email-masked] List
| Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR WG document?
| 
| no support - IMO its not needed as a router could send the
| PMTU/ICMP message in the downstream direction where a
| LSP egress node decapsulates the packet and finally sends
| it back to the ingress node;
| we are doing this successfully for other labeled environments,
| so i fail to see why LBGP is different in that respect.
| 
| tx,
| 
| /hannes
| 
| On 11/16/2011 10:01 AM, John Scudder wrote:
| > Folks,
| >
| > We have received a request from the authors to adopt ft-zeng-idr-bgp-mtu-extension-01 as an IDR WG document.  Please send your comments to the list.  The deadline for comments is December 5, 2011 at noon EST.
| >
| > Thanks,
| >
| > --John
| > _______________________________________________
| > Idr mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/idr
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 02:28:30 +0100

Hannes,

> end-systems and fix "whatever reason" ?

Of course and that is why I said in my original mail:

"Said all of this I am much more in favor to detect MTU host to host in 
the data plane. And if this is broken for whatever reason we should 
focus on fixing that problem rather then patching it on routers."

> |http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp
>

True. So if one would like to map such RSVP carried MTU on ASBRs into 
3107 would you support it ? Just curious ...

Cheers,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 17 Nov 2011 03:18:22 +0100

On Thu, Nov 17, 2011 at 02:28:30AM +0100, Robert Raszuk wrote:
| Hannes,
| 
| >wouldn't a more straightforward to make PMTU to work between
| >end-systems and fix "whatever reason" ?
| 
| Of course and that is why I said in my original mail:
| 
| "Said all of this I am much more in favor to detect MTU host to host in 
| the data plane. And if this is broken for whatever reason we should 
| focus on fixing that problem rather then patching it on routers."
| 
| >| Other protocols have already been extended to perform MTU
| >| propagation - example RSVP:
| >|
| >|http://www.google.com/search?gcx=w&sourceid=chrome&ie=UTF-8&q=mpls-mtu-signaling-rsvp
| >
| >good example: i'd argue that the brief difference is that RSVP usually is
| >deployed in a hop-by-hop fashion (and hence can implement a min(link-MTU) 
| >along the
| >LSP and iBGP is not.
| 
| True. So if one would like to map such RSVP carried MTU on ASBRs into 
| 3107 would you support it ? Just curious ...

for RSVP this would be doable, however ...
i am worried about the complexities and scaling implications
surrounding this. as per your example everytime a iBGP 3107 path
resolves over a RSVP i need to callback into BGP, check if there
is a MTU change of the resolved path, and if so, re-build all
outgoing BGP messages.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 03:41:58 +0100

Hi Hannes,

> is a MTU change of the resolved path, and if so, re-build all

True too. Since we are at this topic I think there is number of issues 
which needs to be discussed a bit more before we reach any conclusions 
not maybe on this particular draft, but on the problem space.

Few open questions ..

- Does MTU discovery belong in control plane or data plane or both ?

- Is http://tools.ietf.org/html/rfc2923 complete reg TCP MTU issues ? 
How about other protocols ? Can those be always solved by data plane ?

- Is MTU problem affecting only MPLS networks or also pure IP networks ?

- If protocols have been enhanced to simplify MTU discovery intra-domian 
should some effort be spend to also address inter-domain cases ?

Regards,
R.

---

From: Jie Dong <[email-masked]>
Date: Thu, 17 Nov 2011 02:42:29 +0000

#Jie: Good catch. Section 3.4 of this draft describes considerations on possible route flapping. And the re-advertisement of BGP update would only happen if the Path MTU decreases, since this may impact the service traffic. For MTU increase scenario, the update would be hold down until some other changes require a bgp re-advertisement. 

And LDP also has the control plane MTU discovery mechanism: http://tools.ietf.org/html/rfc3988

Thanks,
Jie

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 17 Nov 2011 04:02:57 +0100

> - Does MTU discovery belong in control plane or data plane or both ?

i feel that this really should belong into the dataplane.
for IP we have PMTU and
for MPLS paths we could do a similar thing using lsping.

> How about other protocols ? Can those be always solved by data plane ?

can you give some specific example for "other protocols" ?

> - Is MTU problem affecting only MPLS networks or also pure IP networks ?

both and - it depends if the endpoint can actually play an
active role and hence perform path MTU discovery.

> should some effort be spend to also address inter-domain cases ?

using lsping we have got support for both interdomain and intradomain
protocols.

---

From: Jie Dong <[email-masked]>
Date: Thu, 17 Nov 2011 03:31:10 +0000

Hi,

#Jie: As in my previous reply to Hannes, The update would only be signaled when the MTU decreases, this is necessary as otherwise this would impact the service traffic.

Few open questions ..

#Jie: I think we already have both. And they would be used in different cases.

Data plane MTU discovery needs be run periodically to catch the changes of MTU, or it could be performed when some packets are already getting discarded.

Control plane MTU discovery could discover the MTU change proactively, and the re-signaling is only needed when the MTU decrease. 

#Jie: I guess you mean other "transport protocol". Here one way is to define and perform specific procedures for each transport protocol, and another way is to discover the MTU in lower layer and provide this to each transport protocols. 

#Jie: Both IMO.

#Jie: Sounds reasonable to me.

Regards,
Jie

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 17 Nov 2011 03:50:46 -0500

support.

For L3VPN option c, BGP contributes one link of an end-to-end LSP. This draft proposes a good way to propagate the PMTU across that link.

One part I don't understand is in 3.3.c, why does the speaker not pass along the MTU from the previous link? In the L3VPN option c, 3 label case, it sets itself as nexthop. It should preserve the MTU, I think.

In some cases, such as a multihop BGP session, or a BGP session between loopback interfaces, it can not determine an MTU. This is of no concern. BGP would simply not generate this MTU community.

As for data plane/control plane arguments, I think a control protocol that participates in the establishment of a tunnel is the best place to pass any needed properties of that tunnel, including the MTU. Signaling of properties, including MTU belongs in the control plane. That after all is control. The data plane is named "data", because that's all that belongs in it.

--
Jakob Heitz.

---

From: Jie Dong <[email-masked]>
Date: Thu, 17 Nov 2011 09:23:36 +0000

Hi Jakob, 

Thanks for your comments, and please see replies inline with #Jie.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jakob Heitz [[email-masked]]
Sent: Thursday, November 17, 2011 16:50
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of ft-zeng-idr-bgp-mtu-extension-01 as IDR  WG      document?

support.

#Jie: When the speaker sets itself as nexthop, this means it would be on the forwarding path of the LSP, and in this case it should compare the received LSP path MTU and "its BGP LSR Link MTU to its nexthop minus 4", and choose the smaller one as its LSP Path MTU, and then propagate this MTU to its upstream BGP peers.

#Jie: In this case BGP could choose the minimum of the link MTU between the two BGP speaker as its BGP LSR link MTU.

#Jie: Agreed. Path MTU can be considered as a attribute of the LSP path and is reasonable to be advertised using the control plane. And we have done this in other label signaling protocols.

Regards,
Jie

--
Jakob Heitz.

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 17 Nov 2011 04:42:37 -0500

agreed, I must have misread your draft.

--
Jakob Heitz.