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

Robert Raszuk <robert@raszuk.net> Tue, 07 March 2017 15:15 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76355126DFB; Tue, 7 Mar 2017 07:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.368
X-Spam-Level:
X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdYImhLqAw1; Tue, 7 Mar 2017 07:15:46 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC56F12959A; Tue, 7 Mar 2017 07:14:11 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id v125so8257454qkh.2; Tue, 07 Mar 2017 07:14:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=R3JllnLdDMlJMC86+V6nWYZYW6tLMPn4GgHZcvI2Diw=; b=HHAvDk2CurHJjmRQEk1ic5jscBw+1bgGjncTb5PMai7qMZxoj9HJyl/7S+C6mmbSJX FZ8xl0E3S2GIpzluX+U/QazYdnmtfRVe6rXvcvxg6HUVdO6jKEWWVo78GS/hcvFqQH/f uXcggAMYmqHv886HZ467OhurnA9/hEmrBhRc59WSTS/B1AFum711EjrOUejnNipD9zZA Xf0zST+9WDe0I1cMsH2zxzsXfi9oHmRDCnKD25/enXcX2ONbxdYUW6KPDKBysteeO5ri Z2eSn4FzihJEvlnm646c+oFpY4u0G4nKHB/eG9+oCXw1gIPijIDlfaoQxrKTVUMte3OQ DsqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=R3JllnLdDMlJMC86+V6nWYZYW6tLMPn4GgHZcvI2Diw=; b=K/SvRtiWVVheLxrVhkUkjHVYR8D2wrtUrGPi+TuxPZ3ngCQV1cywSpjOY2dm0XYV7k LjUR//i4kkDXHIsC0PFc52FrRUKiqRYf9tXNiYGHfdtvkY+bHOOvhcPyj1nFBb2+unJd Ei4L3f1ppWIyd5u7CJsBbofmfmVKsN+WQjHDeP6WEAbFUz6lTiUlVm1lJAQ4VE1QaoSp tcpFn0wbXmhTcezSi4s2e0mp4Wv5rBgoWKUXq8KTi7jrQpxSIjwNtNXsz0F2HzXUcq9q Tn543nR5XNSNPTsgdKK/UbgJRVV+pk1j7MuHX9H8hF1UVW/lNnocR9zuqLU80Ah7tsf/ eJFQ==
X-Gm-Message-State: AMke39moWFuNwVZ6B5PRRObdgC/N6zPn3cjvVv6OK/1yGRhz2lqOezPO+tnMjR2yrKfrZxakbc7if/0Nzxlwiw==
X-Received: by 10.55.128.66 with SMTP id b63mr936464qkd.297.1488899650662; Tue, 07 Mar 2017 07:14:10 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Tue, 7 Mar 2017 07:14:09 -0800 (PST)
In-Reply-To: <010101d2974a$8520d060$8f627120$@ndzh.com>
References: <DAEE98CC-8483-499E-B71C-FE4C6FC15A4A@cisco.com> <20170228210627.GB17448@pfrc.org> <3eb4d853-1d44-6250-c70a-26f60eac39e6@cisco.com> <006e01d296db$a7c4c320$f74e4960$@ndzh.com> <CA+b+ERmddHoq+4FmU+Ct3MhH46om8yUt69EoQMyLnzweHF=JgQ@mail.gmail.com> <010101d2974a$8520d060$8f627120$@ndzh.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 7 Mar 2017 16:14:09 +0100
X-Google-Sender-Auth: ZSinF4Cocg-SRQ5iAEXUjWqcSYQ
Message-ID: <CA+b+ERnejrof2dfvb4YuKpWieLxWOF7mTXkZpaOgJc=y=2V+XA@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=94eb2c06654cc90089054a257677
Cc: idr wg <idr@ietf.org>, idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-extended-messages-20
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 15:15:49 -0000

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 <shares@ndzh.com>; wrote:

> Robert:
>
>
>
> <individual contributor hat on>
>
> This is a more complex change to the state machine than just extending all
> messages.
>
>
>
> Sue Hares
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *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);
> idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; 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 <shares@ndzh.com>; 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:enkechen@cisco.com]
> Sent: Monday, March 6, 2017 3:22 PM
> To: Jeffrey Haas; Alvaro Retana (aretana)
> Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org;
> Susan Hares; idr@ietf.org; 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
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>