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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 4 Nov 2019 03:45:06 +0000

Jeff,

Thank you for a careful review and comments.
Sorry for the delay in responding. My comments inline below.
I have uploaded version -02 draft with suggested changes from you
and John Heasley; so you may look at the diff file as well in datatracker:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-deprecate-as-set-confed-set-02 

> 
> 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.

Agree with you except we need to have “MUST NOT” for 
locally generated (initiated) updates with AS_SET. 
And it is “SHOULD NOT” for receipt and forwarding as you suggest.

I have tweaked the text (per your suggestion for the most part) 
in the updated -02 draft as follows: 

   “This document deprecates the AS_SET (type 1) AS_PATH segment type
   from [RFC4271].  BGP speakers conforming to this document (i.e.,
   conformant BGP speakers) MUST NOT locally generate BGP UPDATE
   messages containing AS_SET.  Conformant BGP speakers SHOULD NOT send
   BGP UPDATE messages containing AS_SET.  Upon receipt of such
   messages, conformant BGP speakers SHOULD use the "Treat-as-withdraw"
   error handling behavior as per [RFC7606].”

Yes, similar wording change has been made for confed-set. 

> 
> 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.

We are not suggesting “… doing any sort of filtering of more specifics …”.
I have removed the text you’ve cited. That text is not necessary.
So, I think we are good now.  
 
> 
> The implications:
> - You have to provide an entire revised section 9.1.4 for RFC 4271.

This is no longer relevant given my response above.
However, section 9.1.4 says (in the last paragraph):
   “If a BGP speaker chooses to aggregate, then it SHOULD either include
   all ASes used to form the aggregate in an AS_SET, or add the
   ATOMIC_AGGREGATE attribute to the route.”
We could recommend changing it to:
   “If a BGP speaker chooses to aggregate, then it SHOULD 
   add the ATOMIC_AGGREGATE attribute to the route.”

> 
> 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.
> 

I think we don’t need to change anything about ATOMIC_AGGREGATE
for the purpose of this document.

Yes, we can say “deprecate appendix  F.6 of RFC 4271”.  
We can say the same about F.4 “deprecate appendix  F.4 of RFC 4271”.  
F.4 is no longer relevant when AS_SET is deprecated.

However, I think rather than get specific about such instances, 
it better to have an overarching statement. So, the draft now includes
this statement in Section 4:

   “Wherever mentions of AS_SET or AS_CONFED_SET occur in [RFC4271] and
   [RFC5065], appropriate modification or elimination of the text must
   be made in future RFCs that would replace these RFCs, consistent with
   the deprecation of AS_SET and AS_CONFED_SET.”

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

I’ve updated the text that involved voicing network operators and moved it
down within the section. I think network operators can be proactive and 
not use AS_SET/AS_CONFED_SET even with current implementations.   

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

Yes, the new text at the top Section 3 is:

   “BGP speakers conforming to this document (i.e., conformant BGP
   speakers) MUST NOT locally generate BGP UPDATE messages containing
   AS_SET or AS_CONFED_SET.  Conformant BGP speakers SHOULD NOT send BGP
   UPDATE messages containing AS_SET or AS_CONFED_SET.  Upon receipt of
   such messages, conformant BGP speakers SHOULD use the "Treat-as-
   withdraw" error handling behavior as per [RFC7606].”
 
> 
> :    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?

I have removed the text you’ve cited. That text is not necessary
for the purpose of this draft.  

Regarding your question “How do you do this”, here is my two cents worth.
I think if AS X is aggregating (without using AS_SET) P1/24 (from cust. A), 
P2/24 (from cust. B), P3/24 (from cust. C)  and P4/24 (from cust. D) to P/22,
then AS X will announce the P/22 aggregate to its transits and later peers
(while including ATOMIC_AGGREGATE attribute in the aggregate update),
but not to the customers. AS X will announce to each of the four customers,
only the more specific prefixes contributed by the other three customers. 
In addition, RFC 4271 (sec. 9.1.4) says the following for all other ASes
(transits, peers, customers of peer, etc.) that receive the aggregate:  
 “In particular, a route that carries the
   ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated.”  

I don’t think we need to put text in the document regarding the above
since it seems to be adequately covered in RFC 4271. Your take?

Sriram

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 4 Nov 2019 16:41:09 -0500

Sriram,

>    error handling behavior as per [RFC7606].”

It will be interesting to see how the unruly mob who's demanding this draft
treats the small amount of room this wording gives such a "deprecation".
"SHOULD NOT" means "does occasionally".

>    add the ATOMIC_AGGREGATE attribute to the route.”

Minimally, that's necessary.

I think we'll find that makes things more annoying than set elements at some
point down the line.  The motivation to remove sets is that origin
validation gets difficult/impossible.  You'll find most implementations
don't have a way to test for atomic aggregate in policy at all.

Why would you care?  AA says "never deaggregate".  At some place in the
network, a given prefix may be encountered with and without AA set.  In one
of these cases, it used to be the case that the path was shortened from a
calculated standpoint (this is a side effect of proxy aggregation - as-sets
are length one for the whole set).  And now they're differently comparable.

This is an edge case.  But once this thing ships as an RFC, I'll set a timer
for the incoming request for a knob to deal with its consequences.

> for the purpose of this document.

I'll wait on others to comment here.  It's been my observation over nigh 20
years of BGP that even the inventor of the feature didn't fully understand
what it did.  And now, courtesy of removing sets, it'll be more mandated
than before.

>    the deprecation of AS_SET and AS_CONFED_SET.”

You're making an intrustive change to RFC 4271.  Handwaving details and
leaving them up to generally clueless implementors to intuit was is meant
here is not something we should ship.

For my part, I'll strongly suggest to the chairs that we do not pass this
document through WGLC without this dealt with.  Too many of us spent too
many cycles on RFC 4271 and the consequences of sloppy wording thereafter
not to do so.

[impacts of proxy aggregation]
> (while including ATOMIC_AGGREGATE attribute in the aggregate update),

Implication for RPKI, it is the originating AS and is permitted in the ROA
to originate such a shortened route.

> but not to the customers. 

To do so, configuration related to the aggregation now must be pushed to the
ASBR connections of the component routes.

Previously, the set would obviate the need for this.

You've changed the required operational model of such aggregation.  

> AS X will announce to each of the four customers,

This point is correct, and should be documented, because it interacts with
the operational model change above. 

We didn't have to filter the less specific to the providers, but we do now.
That is likely to be a prefix filter.  We need to ensure that the more
specifics get propagated.  That prefix filter has to be correctly specified
vs. the filter on the less specific.  (I.e. don't just reject >= /22 to the
peers!)

> since it seems to be adequately covered in RFC 4271. Your take?

You also now have the fun of what happens when the route gets around to the
back door of such an aggregated service provider.

Simplified example:

   Internet --- Aggregating --- Customer
      |                            |
      +----------------------------+

The customer announces P1/24.

Aggregating upstream, that peers with customer, generates P1/22, a less
specific of the more specific P1/24.  It announces it upstream to the
Internet, and suppresses P1/24.

The customer at some point receives P1/22.  This covers their internal
address space of P1/24.

Previously, when AS_SETs were used, P1/22 would have been dropped by the
Customer automatically as a loop.  This no longer happens.

It is a BCP that providers should filter routes that cover their address
space.  Filtering out P1/24 and longer is easy.  What do they do about
P1/22?  What filtering construct says "this overlaps my /24?"  You've
created a new policy need, I think. *

If the internal P1/24 reachability goes away, we may end up in temporary
forwarding loops until the Internet converges.  (Internal traffic heads
toward the Internet via the /22 to eventually arrive back through the
Aggregating ISP.)  Alternatively we end up with some new need to filter
outbound traffic for routes we know we announce.

-- Jeff

* There's a chance I'm missing the obvious here.  Generally, my customers
are more clever about using our policy than I am. :-)

---

From: john heasley <[email-masked]>
Date: Mon, 4 Nov 2019 23:06:15 +0000

> created a new policy need, I think. *

Which BCP is that?  It is quite common that a provider announces their
assigned aggregate and multi-homed customers announce the prefixes
assigned to them from that aggregate.  Perhaps I am mis-understanding
you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 5 Nov 2019 14:49:17 -0500

> assigned to them from that aggregate.  Perhaps I am mis-understanding

The dangerous of using acronyms.

My meaning was that it's a best common practice in the operational sense,
not that someone wrote and RFC that has received that capital letter
blessing.

If you network is a more specific in that aggregate, what policy construct
are you using to detect that your prefix is being covered in a less specific?

-- Jeff

---

From: john heasley <[email-masked]>
Date: Tue, 5 Nov 2019 21:03:40 +0000

> not that someone wrote and RFC that has received that capital letter

IETF BCP or otherwise :)

> are you using to detect that your prefix is being covered in a less specific?

All one can reasonably do is verify the origin of the shorter aggregate in
the DMZ or, preferrably, origin validation.  Am I missing something?