Re: [Idr] WG Last Call on Extened Message Support

[Randy Bush <[e-mail]>]

dear reviewer #2:

excuse, this has been in an edit buffer for weeks.

> [I-D.ietf-sidr-bgpsec-protocol<https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-27#ref-I-D.ietf-sidr-bgpsec-protocol>
> is now RFC 8205 (thanks for updating the reference). It has removed the normative/any reference to
> draft-ietf-idr-bgp-extended-messages. So presumably BGP Sec does not need draft-ietf-idr-bgp-extended-messages. 
> Can we have an update on this?

extended-messages authors had $dayjobs and did not have the stamina for
the level of dos in the sidr wg.  they were desperate to get bgpsec our
the door and idr was holding them hostage.  and it's not like bgpsec is
just around the corner.

> Can the introduction of draft-ietf-idr-bgp-extended-messages be
> updated to introduce on the real reasons/needs?

would you like it if we threw in bgp-ls?  no extra charge.

> §3 says "A peer which does not advertise this capability MUST NOT send BGP
>    Extended Messages, and BGP Extended Messages MUST NOT be sent to it."
> 
> Fine. Text in §4 should probably be aligned with the above .e.g.
> 
> OLD: A BGP speaker
>    MAY send Extended Messages to its peer only if it has received the
>    Extended Message Capability from that peer.
> 
> NEW:
> A BGP speaker
>    MAY send Extended Messages to its peer only if it has sent and received the
>    Extended Message Capability to and from that peer.

the intent was to allow simplexity, use of extended messages in one
direction only.  in retrospect, this may be too subtle/clever.  it could
be as you suggest if no one wants simplexity.

> "   Applications generating information which might be encapsulated
>    within BGP messages MUST limit the size of their payload to take the
>    maximum message size into account."
> 
> I don't see what new behavior is been defined here. If there is none, I would suggest to remove this sentence

it was added to reaffirm what to you is obvious.  unless you really
object, i see no harm in leaving it.

>    A BGP announcement will, in the normal case, propagate throughout the
>    BGP speaking Internet; and there will undoubtedly be BGP speakers
>    which do not have the Extended Message capability.  Therefore,
>    putting an attribute which can not be decomposed to 4096 octets or
>    less in an Extended Message is a likely path to routing failure.
> 
> The issue is not specific to attributes bigger than 4096 octets, but to BGP message whose length is bigger than 4096, irrespective of the size of each attribute.
> Please elaborate on what you mean by "an attribute which can not be decomposed to 4096 octets"

a prefix announcement with 200 researcher-invents-massive-attribute? :)
[ nanog joke ]


> ---
> "   It is RECOMMENDED that BGP protocol developers and implementers are
>    conservative in their application and use of Extended Messages."
> 
> What does this mean exactly? That they don't use this extension? That they don't use this extension unless XX_TO BE SPECIFIED_XX?
> 
> ---
>   Future protocol specifications will need to describe how to handle
>    peers which can only accommodate 4096 octet messages.
> 
> Why is this limited to future specifications? A priori, using existing BGP mechanism (AFI/SAFI, attributes, * communities) one could exceed the size of 4096 octets. How does the BGP speaker supposed to behave in this case? This should be described in this specification. Note that this is not a case of error handling, as every BGP speaker is behaving as specified.
> ----
> Depending on the above specification, a section describing the operational consequences in a network (such as the Internet, BGP Enabled ServiceS/VPN networks) is probably needed. Possible consequences could be BGP NLRI being removed in the middle of such network, or (extended) community (such as Route Targets) been removed. Both having significant consequences on the availability provided by the network.
> 
> ---
> §4
> OLD: The Extended Message Capability only applies to all messages except for the OPEN message.
> Probably
> NEW: The Extended Message Capability applies to all message types except for the OPEN message (type 1).
> ----
> §8
> 
> "This extension to BGP does not change BGP's underlying security issues »
> 
> Before evaluating this, I think this document should first specified how a BGP messages bigger than 4096 octets is handled when it needs to be sent to a received not supporting this extension.
> 
> Nits:
> OLD : to reduce compexity
> NEW : to reduce complexity

i took some edits, tyvm.

randy