Subject: [Idr] comment on draft-ietf-idr-bgp-extended-messages

From: li zhenqiang <[email-masked]>
Date: Thu, 8 Jun 2017 05:25:47 +0000

Hello,

This doc, https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-extended-messages/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=>, extends the maximum update message size of BGP beyond 4096 bytes to 65535 bytes. My comment is about its transport. BGP is TCP based and TCP relys on IP to do fragmentation and reassembly if needed. But IP fragmented packets  may be droped by some nodes in the network due to security rules or to improve the tansport preformance.  So sometimes the BGP speakers may not receive some fragmented extended update messgaes. This deployment problem should be considered.

Best Regards,
________________________________
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Jun 2017 08:41:11 +0200

Hi,

Wouldn't TCP simply retransmit missing data if drops are accidental ?

If drops are "by design" due to as you said security rules I am afraid such
path is not going to carry BGP session.

//RR.

On Jun 8, 2017 07:26, "li zhenqiang" <[email-masked]> wrote:

Hello,

This doc, https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-
extended-messages/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dbgp-2Dextended-2Dmessages_&d=DwMGaQ&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=plGpWzcW7ppWguHBC4w6PyEGZRLkmX7MJ1vUTVNOpZs&s=0pin7tGPbPq5n1iayUcdxrEXuvzvTPplWdQkXERikBo&e=>
, extends the maximum update message size of BGP beyond 4096 bytes to
65535 bytes.
My comment is about its transport. BGP is TCP based and TCP relys on IP to
do fragmentation and reassembly if needed. But IP fragmented packets  may
be droped by some nodes in the network due to security rules or to improve
the tansport preformance.  So sometimes the BGP speakers may not receive
some fragmented extended update messgaes. This deployment problem should be
considered.

Best Regards,
------------------------------
[email-masked]

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: li zhenqiang <[email-masked]>
Date: Thu, 8 Jun 2017 07:14:23 +0000

Yes, TCP will retransmit the missing data. But IP fragmentation will occur again if the BGP message size isn't cut down. The receiver can't get the missing data.
This issue is specific to BGP extended message because the extended update message may be fragmented by IP when it traverses the network from the source to the destination. BGP messages don't need to be fragmented by IP have no such problem.

Best Regards,

From: Robert Raszuk<mailto:[email-masked]>
Date: 2017-06-08 14:41
To: li zhenqiang<mailto:[email-masked]>
CC: draft-ietf-idr-bgp-extended-messages.all<mailto:[email-masked]>; idr wg<mailto:[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
Hi,

If drops are "by design" due to as you said security rules I am afraid such path is not going to carry BGP session.

//RR.

On Jun 8, 2017 07:26, "li zhenqiang" <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Best Regards,
________________________________
[email-masked]<mailto:[email-masked]>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Jun 2017 10:30:46 +0200

> This issue is specific to BGP extended message

I don't think so. Today max BGP message size is 4K and typical WAN MTU 1500
bytes. So it may get fragmented anyway.

If TCP keeps retransmitting same or resized segment and reaches max
retransmissions value the connection will be terminated.

//R.

On Thu, Jun 8, 2017 at 9:14 AM, li zhenqiang <[email-masked]>
wrote:

> Yes, TCP will retransmit the missing data. But IP fragmentation will occur
> again if the BGP message size isn't cut down. The receiver can't get the
> missing data.
> This issue is specific to BGP extended message because the extended update
> message may be fragmented by IP when it traverses the network from the
> source to the destination. BGP messages don't need to be fragmented by IP
> have no such problem.
>
> Best Regards,
> *From:* Robert Raszuk <[email-masked]>
> *Date:* 2017-06-08 14:41
> *To:* li zhenqiang <[email-masked]>
> *CC:* draft-ietf-idr-bgp-extended-messages.all
> <[email-masked]>; idr wg <[email-masked]>
> *Subject:* Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
> Hi,
>
> If drops are "by design" due to as you said security rules I am afraid
> such path is not going to carry BGP session.
>
> //RR.
>
>
>
>
> This doc, https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ext
> ended-messages/
> , extends the maximum update message size of BGP beyond 4096 bytes to 65535 bytes.

---

From: li zhenqiang <[email-masked]>
Date: Thu, 8 Jun 2017 09:05:30 +0000

I checked the configurations of some routers  in my product network. The WAN MTU for Juniper's routers is 4484, and 4470 for Huawei's routers.

From: Robert Raszuk<mailto:[email-masked]>
Date: 2017-06-08 16:30
To: li zhenqiang<mailto:[email-masked]>
CC: draft-ietf-idr-bgp-extended-messages.all<mailto:[email-masked]>; idr<mailto:[email-masked]>
Subject: Re: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
> This issue is specific to BGP extended message

I don't think so. Today max BGP message size is 4K and typical WAN MTU 1500 bytes. So it may get fragmented anyway.

If TCP keeps retransmitting same or resized segment and reaches max retransmissions value the connection will be terminated.

//R.

On Thu, Jun 8, 2017 at 9:14 AM, li zhenqiang <[email-masked]<mailto:[email-masked]>> wrote:
Yes, TCP will retransmit the missing data. But IP fragmentation will occur again if the BGP message size isn't cut down. The receiver can't get the missing data.
This issue is specific to BGP extended message because the extended update message may be fragmented by IP when it traverses the network from the source to the destination. BGP messages don't need to be fragmented by IP have no such problem.

Best Regards,

//RR.

Best Regards,

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Jun 2017 13:45:29 +0200

Sorry, but MTU is not dependent on the router vendor, but on the circuits
specifications you get from carriers to construct your WAN. Our circuits
(usually emulated ones) are guaranteed to carry 1500 byte packets
regardless of routers used on both ends.

//R

On Thu, Jun 8, 2017 at 11:05 AM, li zhenqiang <[email-masked]>
wrote:

> I checked the configurations of some routers  in my product network. The
> WAN MTU for Juniper's routers is 4484, and 4470 for Huawei's routers.
>
> *Date:* 2017-06-08 16:30
> <[email-masked]>; idr <[email-masked]>
> *Subject:* Re: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
> I don't think so. Today max BGP message size is 4K and typical WAN MTU
> 1500 bytes. So it may get fragmented anyway.
>
>> Yes, TCP will retransmit the missing data. But IP fragmentation will
>> occur again if the BGP message size isn't cut down. The receiver can't get
>> the missing data.
>> This issue is specific to BGP extended message because the extended
>> update message may be fragmented by IP when it traverses the network from
>> the source to the destination. BGP messages don't need to be fragmented by
>> IP have no such problem.
>>
>> Best Regards,
>> , extends the maximum update message size of
>> BGP beyond 4096 bytes to 65535 bytes. My comment is about its transport.
>> BGP is TCP based and TCP relys on IP to do fragmentation and reassembly if
>> needed. But IP fragmented packets  may be droped by some nodes in the
>> network due to security rules or to improve the tansport preformance.  So
>> sometimes the BGP speakers may not receive some fragmented extended
>> update messgaes. This deployment problem should be considered.
>>
>> Best Regards,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 08 Jun 2017 18:45:19 +0100

Robert Raszuk wrote:
> Sorry, but MTU is not dependent on the router vendor, but on the
> circuits specifications you get from carriers to construct your WAN. Our
> circuits (usually emulated ones) are guaranteed to carry 1500 byte
> packets regardless of routers used on both ends. 

mtu is dependent on both the router interface characteristics and the
underlying circuit characteristics:  it's not just vendor-dependent,
it's specific to the hardware used on the particular interface.

I don't think this fragmentation argument is very important in the
context of draft-ietf-idr-bgp-extended-messages because BGP is just
sending out data in a tcp stream, and the MTU management is handled at
the TCP level.  So TCP won't attempt to put a 65535-byte update message
into a single TCP packet which is then fragmented; it will stream out a
series of packets of packetlen=MTU until the update has been fully
transmitted.

This behaviour is confirmed in rfc4271, section 3:

> BGP uses TCP [RFC793] as its transport protocol.  This eliminates the
>    need to implement explicit update fragmentation, retransmission,
>    acknowledgement, and sequencing.

Fragmentation happens occasionally in practice if there is a path mtu
mismatch between sender and receiver bgp speaker.  Generally speaking,
if it happens and there's a problem with transmitting the fragments,
then the bgp session will fail outright because most bgp implementations
will bundle lots of updates into a single TCP packet of size == MTU.

I.e. the concern that was raised is not an actual problem.

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 8 Jun 2017 18:43:17 +0000

TCP does not create IP fragments.
TCP splits its data into correctly sized full IP packets.
If you see IP fragments in the network, then it is because of MTU mismatch.
TCP uses Path MTU detection to find the smallest MTU on its path in order to avoid fragmentation.
People often block the ICMP messages necessary for path MTU detection, so it doesn't always work well.
Regardless, the size of the IP packets is unrelated to the BGP message size.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of li zhenqiang
Sent: Thursday, June 08, 2017 12:14 AM
To: robert <[email-masked]>
Cc: idr <[email-masked]>; draft-ietf-idr-bgp-extended-messages.all <[email-masked]>
Subject: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages

Best Regards,

//RR.

Best Regards,

---

From: li zhenqiang <[email-masked]>
Date: Fri, 9 Jun 2017 03:11:44 +0000

Thank you all for discussion and clarification.

I got the key point for my concern. BGP can use the extended message. When TCP gets the BGP message, TCP cuts the message into segments according to the MTU or MSS of its own, and then passes the segments to IP. TCP itself can not guarentee the segments it emits to the IP small enough to avoid fragmentation, because the MSS or MTU determined by the sender and receiver may be bigger than the MTU in the middle path. Path MTU is not a reliable way neither as you explained. So when fragmentation happens occasionally in practice, the operator has to do something to solve this, such as by configuring the MTU or MSS on the BGP speaker small enough to avoid IP fragmentation.

Best Regards,

From: Jakob Heitz (jheitz)<mailto:[email-masked]>
Date: 2017-06-09 02:43
To: li zhenqiang<mailto:[email-masked]>; robert<mailto:[email-masked]>
CC: idr<mailto:[email-masked]>; draft-ietf-idr-bgp-extended-messages.all<mailto:[email-masked]>
Subject: RE: Re: [Idr] comment on draft-ietf-idr-bgp-extended-messages
TCP does not create IP fragments.
TCP splits its data into correctly sized full IP packets.
If you see IP fragments in the network, then it is because of MTU mismatch.
TCP uses Path MTU detection to find the smallest MTU on its path in order to avoid fragmentation.
People often block the ICMP messages necessary for path MTU detection, so it doesn't always work well.
Regardless, the size of the IP packets is unrelated to the BGP message size.

Thanks,
Jakob.

Best Regards,

//RR.

Best Regards,

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 09 Jun 2017 08:37:29 +0100

li zhenqiang wrote:
> So when fragmentation happens occasionally in practice, the operator has
> to do something to solve this, such as by configuring the MTU or MSS on
> the BGP speaker small enough to avoid IP fragmentation.

yes, precisely.  It happens during normal BGP operation from time to
time and is certainly annoying, but most operational people have run it
at one time or another.

Nick