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

[Jeffrey Haas <[e-mail]>]

Sriram,

On Mon, Nov 04, 2019 at 03:45:06AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> 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].”

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


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

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.

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

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.

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

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]
> 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),

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,
> only the more specific prefixes contributed by the other three 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!)

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

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


> 
> Sriram
>