Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20

[Robert Raszuk <[e-mail]>]

Sue,

I don't understand your point of "more complex".

Current proposal extends single message type. I indicated that future
defined messages needs also to have an option to be extended with proposed
capability.

That's all.

Thx,
Robert



On Tue, Mar 7, 2017 at 2:55 PM, Susan Hares <[e-mail]> wrote:

> Robert:
>
>
>
> <individual contributor hat on>
>
> This is a more complex change to the state machine than just extending all
> messages.
>
>
>
> Sue Hares
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, March 7, 2017 5:09 AM
> *To:* Susan Hares; Randy Bush
> *Cc:* Enke Chen; Jeffrey Haas; Alvaro Retana (aretana);
> [e-mail]; [e-mail]; idr wg
>
> *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
>
>
>
> Hi Sue, Authors,
>
>
>
> Current draft says:
>
>
>
> *"Currently, the Extended Message Capability only applies to UPDATE
> messages."*
>
>
>
> I would like to ask authors to change the below restriction to also
> consider future BGP messages still compliant with RFC4271 RFC. I would
> therefor propose to extend the above sentence with:
>
>
>
> *"The Extended Message Capability applies to UPDATE messages as well as if
> required to any new BGP messages."*
>
>
>
> - - -
>
>
>
> I am less concerned in making Extended Message Capability applicable to
> OPEN or KEEPALIVE messages. IMHO Capabilities from OPEN should be moved to
> new BGP message (BGP CAPABILITIES MESSAGE) which would by design allow
> their dynamic nature along the lines of current dynamic capabilities
> proposal except outside of messing up with OPEN.
>
>
>
> For NOTIFICATION as Enke already pointed there is good reason for it to be
> extended. Alternatively a new provision for signalling the errors between
> peers should be provided in new message (example: BGP OPERATIONAL message).
>
>
>
> Thx,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 7, 2017 at 1:42 AM, Susan Hares <[e-mail]> wrote:
>
> Enke and IDR WG:
> <WG chair hat on>
> If there is enough concern about the extended messages covering all
> messages versus UPDATE messages,  I will need to do  1 week call on this
> topic.
> <WG Chair hat off>
>
> Sue Hares
>
> -----Original Message-----
> From: Enke Chen [mailto:[e-mail]]
> Sent: Monday, March 6, 2017 3:22 PM
> To: Jeffrey Haas; Alvaro Retana (aretana)
> Cc: [e-mail]; [e-mail];
> Susan Hares; [e-mail]; Enke Chen
> Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
>
> Hi, Folks:
>
> I see benefits and no drawbacks for the "BGP-Extended Message Capability"
> to cover all the message types, that is, requiring a speaker that
> advertises the capability to be able to receiving large messages of any
> type.  While the requirement for the large message is driven by the UPDATE
> message, other messages (such as NOTIFICATION or OPEN) can potentially
> exceed the 4K message size as well. It is better to deal with this issue
> once.
>
> Clearly a large UPDATE message may require a large NOTIFICATION message,
> e.g., for carrying a malformed attribute.
>
> Regarding the OPEN message, as BGP capabilities are carried inside the
> OPEN message and a number of capabilities are AFI/SAFI specific and thus
> have the "multiplier"
> effect on the message size, potentially the OPEN message may exceed the
> message size in the future. This "extended message capability" can be used
> in a couple of ways to deal with the large OPEN message if the capability
> is made to mean support for all message types:
>
>    o A speaker can remember the capability from its previous OPEN, and
> infer that
>      the large message is most likely supported over the current session,
> and send
>      the large OPEN message if needed. (It can back off from sending the
> large OPEN
>      based on NOTIFICATION message.)
>
>    o A speaker can send a normal OPEN, and once it determines from the
> received
>      OPEN message that the large message capability is supported by the
> remote
>      speaker, the speaker can close the connection and start with a large
> OPEN.
>
> Admittedly these mechanism are not as elegant as the one that bumps the
> BGP version.
> They can be just as effective (especially the first one) in practice.
>
> Thanks.  -- Enke
>
> On 2/28/17 1:06 PM, Jeffrey Haas wrote:
> > Alvaro,
> >
> > I'm not speaking for the authors.  However, a few comments on your
> writeup:
> >
> > On Thu, Feb 23, 2017 at 07:17:05PM +0000, Alvaro Retana (aretana) wrote:
> >> M1. Section 4. (Operation): “An implementation that supports the BGP
> >> Extended Messages MUST be prepared to receive an UPDATE message that
> >> is larger than 4096 bytes.“  Only UPDATEs?  I know that the most
> >> likely case for exceeding the 4k size is an UPDATE, but why are the
> >> other messages not considered?
> >
> > The fundamental issue is with regards to not only the basic behavior
> > of RFC 4271 and its earlier RFC 1771 but also to BGP Versioning.
> >
> > Those RFCs set the expectation that version 4 of BGP will have at most
> > a 4k packet size.  Capability advertisement, an extension on top of
> > BGP, isn't a required feature - although it's certainly very common
> these days.
> >
> > Thus, for backward compatibility reasons, OPEN messages must be no
> > bigger than 4k if we're still BGP-4.
> >
> > I don't think there's an argument for larger KEEPALIVE messages. :-)
> >
> > Similarly, the NOTIFICATION with no restrictions for version
> > compatibility reasons.  *However*, once BGP has reached the
> > Established state, it is possible for it to send longer NOTIFICATION
> > messages, if we permitted it and the feature was duly negotiated.
> > This is probably not the best idea because it will still be necessary
> > to be able to deal with an old speaker in such cases.
> >
> > Also, most implementations don't dump that much information in the
> > NOTIFICATION Data section.  Putting sufficient semantics on the
> > content would start to get messy.  We don't want XML or backtrace over
> that message.
> >
> > The case for UPDATE is clear.
> >
> > The remaining message with some potential motivation is ROUTE-REFRESH.
> > The basic refresh message is likely to be able to hold AFI/SAFI sets
> > for some time.  The ORF feature that is built upon refresh already
> > deals with sending its filters over the course of multiple messages.
> > So, there's not a lot of motivation.
> >
> > And that's the messages we have so far.  While I can see new messages
> > being defined that may want it, I don't think there's a strong
> > argument for it today.
> >
> >> Also, what does “prepared to receive”
> >> mean, and how can “MUST be prepared to receive” be enforced?  Given
> >> the discussion in Section 5 (Error Handling), you might want to add
> >> something like “…even if the Capability is not advertised”.
> >
> > If the capability hasn't been negotiated, then the expectation is that
> > it's a PDU error and the session should be dropped.  See prior
> > comments about BGP versioning.
> >
> >> M2. Section 5 (Error Handling).  “A BGP speaker that has the ability
> >> to use extended messages but has not advertised the BGP Extended
> >> Messages capability, presumably due to configuration, SHOULD NOT
> >> accept an extended message.  A speaker MAY implement a more liberal
> >> policy and accept extended messages even from a peer that has not
> >> advertised the capability.”  This paragraph troubles me a lot because
> >> it is in direct contraction with Section 3: “A peer which does not
> >> advertise this capability MUST NOT send BGP Extended Messages, and
> >> BGP Extended Messages MUST NOT be sent to it.”.  However, I think
> >> that John Scudder’s reasoning [3] makes sense ("keep the session up
> >> at (almost) all costs", and there’s clear precedence in the WG) for
> >> the case where the sender did advertise the Capability, but I’m not
> >> convinced on the case where it didn’t – please include something like
> John’s explanation in the text.
> >
> > John can own this one.  I find the case a little weaker.  It vaguely
> > makes me want a probe message to verify that I can indeed get a
> > full-sized PDU through.
> >
> >> M5. Section 5 (Error Handling).  “The inconsistency between the local
> and
> >> remote BGP speakers MUST be reported via syslog and/or SNMP.”   SNMP?
> >> AFAIK, there’s no object that can report this inconsistency since
> >> there’s no NOTIFICATION generated.  In the proposed text by Gunter
> >> Van De Velde [4], SNMP and syslog were mentioned as examples – I
> >> suggest you follow that path (no need for all the “flowery language”)
> >> and just reference mechanisms by example to avoid having to point at
> how it would be done.
> >
> > IMO, "brought to the attention of the operator.  Example mechanisms
> > might include syslog or SNMP notifications."
> >
> > While you're correct that no IETF standard MIB object covers such a
> > scenario, we shouldn't be proscriptive about some vendor deciding they
> > want it in their enterprise implementation.
> >
> > At some point, we need similar boilerplate language for yang
> notifications.
> >
> >> M7. What about transition/migration/partial deployment?  What should
> >> the behavior be if, for example, an Extended Message UPDATE is
> >> received from a peer, but can’t be propagated to others because they
> >> don’t support Extended Messages (think route reflectors or simple
> >> eBGP -> iBGP)??  There should be some guidance for the general case
> >> (i.e. when the total size is
> >>> 4k due simply to the total amount of information, and not because a
> >> single attribute, for example, is really big), and some requirements
> >> looking forward to potential new messages/attributes that
> >> specifically rely on Extended Messages.
> >
> > I'm not sure such guidance belongs in this document.  We already have
> > scenarios wherein normal protocol machinery can result in messages
> > that are too large.  The expected behavior is "treat as withdraw" to
> > the next downstream, similar to the BGP Error handling RFC.
> >
> > Examples of this include AS_PATH or CLUSTER_LIST attributes needing to
> > add a new entry on a full PDU.
> >
> >> M7.2. What should the default be for this extension?  Should it be
> enabled by default or not?
> >
> > IMO, there are good reasons to not turn it on for existing BGP
> > deployments but alternatively good reasons once the extension is
> > widely enough present in a given topology.  The latter example includes
> bgpsec.
> >
> > -- Jeff
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>