Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-01.txt

Jeffrey Haas <jhaas@pfrc.org> Tue, 29 October 2019 21:35 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 75BF7120132; Tue, 29 Oct 2019 14:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 U5fRtWgrmbVB; Tue, 29 Oct 2019 14:35:12 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4B12001E; Tue, 29 Oct 2019 14:35:12 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A8951E2D3; Tue, 29 Oct 2019 17:38:45 -0400 (EDT)
Date: Tue, 29 Oct 2019 17:38:45 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Cc: IDR <idr@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "Hannachi, Lilia (IntlAssoc)" <lilia.hannachi@nist.gov>, Susan Hares <shares@ndzh.com>
Message-ID: <20191029213844.GC10145@pfrc.org>
References: <BN6PR09MB13317B7AD6F4229F5E00FDD284610@BN6PR09MB1331.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BN6PR09MB13317B7AD6F4229F5E00FDD284610@BN6PR09MB1331.namprd09.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/id66GJvfnjJJg5HDHUzKPwYkbZw>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Oct 2019 21:35:15 -0000

Sriram,

Comments somewhat out of order from the diff:

Section 4:
While well intentioned, this is clumsy in terms of a mandate on how BGP-next
is authored.  BGP is all about incremental deployment and thus just like we
can't simply "pretend this doesn't exist" for current code, the same will be
true for future code.

Suggested text:

This document deprecates the AS_SET (type 1)  AS_PATH segment type from RFC
4271.  BGP Speakers conforming to this document SHOULD NOT* send BGP Update
messages containing this AS_SET type.  Upon receipt, BGP Speakers conforming
to this document should use the "Treat-as-withdraw" error handling behavior
as per RFC 7606.

(and similar text for confed-set)

* The case here is SHOULD NOT rather than MUST NOT because you're providing
the option for a knob to let the old behavior work.

Section 1:
"The aggregation as described above could also create traffic engineering
issues, because the precise path information for the component prefixes are
not preserved."

This is rather the whole point of the "atomic aggregate" feature of BGP-4
specs.  But it's a vestigial feature and we shouldn't fix it.  The
underlying point is when you KNOW that it's an aggregate, and there's
components you're not talking about, don't de-aggregate because you may do
Bad Things to the routes in question.  The usual presumption is that the
more specific routes are percolating far enough that this is hopefully NOT a
problem... and good luck with that, because they might get filtered.  (This
is one of the reasons the signaling is vestigial.)

The effective point here is that if you ARE doing any sort of filtering of
more specifics as part of trying to be conformant with this document, we're
hitting exactly that set of considerations.  Ideally, this wouldn't be
important.  Practically, we have outages every few months caused because
people deploy tools that deaggregate routes for traffic optimization
purposes, and those de-aggregated routes get leaked.

The implications:
- You have to provide an entire revised section 9.1.4 for RFC 4271.

Misc. open issue:
- What do you do about "atomic aggregate?"
- You're also deprecating appendix  F.6 of RFC 4271
- You're modifying recommendations for appendix F.4 of RFC 4271.

Section 3:

"Network operators" is likely the wrong voicing here, even though the advice
is to network operators.  (BGP Speakers announce routes.)

The related changed text likely needs something similar to my recommendation
for section 4 above.

:    Route aggregation that was previously performed by proxy aggregation
:    without the use of AS_SETs is still possible under some conditions.
:    When doing this, operators MUST form the aggregate at the border in
:    the outbound BGP policy and omit any prefixes from the AS that the
:    aggregate is being advertised to.  As with any change, the operator
:    should understand the full implications of the change.

This text is very imprecise.

The following things happen in proxy aggregation:
- The aggregated routes are not sent to the networks that provided
  contributors.  This is a side effect of the as-set being formed.
  + As a result, the contributing networks are expected to need the more
    specific routes that are the aggregate contributors.

How do you do this?

-- Jeff



On Tue, Oct 29, 2019 at 01:50:13PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> We have incorporated all WG comments/suggestions ...
> from the WG adoption call discussions:
> https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=PB8YtGMBvVLeAu6dot072VaDJNc 
> and also from a related thread (feedback requested):
> https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=rqY4ipWnrz2TdYWkKIeZCby9HlY 
> 
> The authors feel that the draft is now ready for WGLC.
> Do the Chairs and WG think that it is ready?  
> Chairs: Please advise if you think it needs to be presented (in Singapore). 
> 
> Thank you.
> Sriram
>    
> --------------------------------------------------
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>         Title           : Deprecation of AS_SET and AS_CONFED_SET in BGP
>         Authors         : Warren Kumari
>                           Kotikalapudi Sriram
>                           Lilia Hannachi
> 	Filename        : draft-ietf-idr-deprecate-as-set-confed-set-01.txt
> 	Pages           : 7
> 	Date            : 2019-10-29
> 
> Abstract:
>    BCP 172 (i.e., RFC 6472) recommends not using AS_SET and
>    AS_CONFED_SET in the Border Gateway Protocol.  This document advances
>    this recommendation to a standards requirement in BGP; it proscribes
>    the use of the AS_SET and AS_CONFED_SET types of path segments in the
>    AS_PATH.  This is done to simplify the design and implementation of
>    BGP and to make the semantics of the originator of a route clearer.
>    This will also simplify the design, implementation, and deployment of
>    various BGP security mechanisms.  This document (if approved) updates
>    RFC 4271 and RFC 5065 by eliminating AS_SET and AS_CONFED_SET types,
>    and obsoletes RFC 6472.
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/ 
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-deprecate-as-set-confed-set-01 
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-01  
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-deprecate-as-set-confed-set-01  
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr