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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Jeff,

Sorry it took me time to respond. My responses are inline.
I'll look forward to connecting with you in Singapore and going over the key points.

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

Yes, AA says "never deaggregate". 
But IMO, it seems correct to say that AA is vestigial.
I think ASes perhaps pay little attention to it because they do not usually
have a need to deaggregagte something that was aggregated elsewhere.
That is why aggregation seems to be working fine with AGGREGATE alone 
and without inserting AA or AS_SET in the Update.
Please see my explanation in an earlier post: 
https://mailarchive.ietf.org/arch/msg/idr/BxaurATmHTUIxlE8lulR36Y5nF0 

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

I don’t think AA will be more mandated due to the removal of sets.
IMO, AA can also be possibly deprecated as I tried to explain above.

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

I am happy to work with you to exactly chart out these details.
We can discuss this in person in Singapore.

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

See my response above. We can make it right.


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

I trust this cannot be new to operators. Hard to imagine that those who
aggregate prefixes are sending only the aggregate to their downstream customers 
and not sending the components, i.e., the more specific prefixes.

… snip …

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

OK. Yes.

>
>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!)

“We didn't have to filter the less specific to the *providers*” ?
Did you mean *customers* instead?
Less specific (aggregate of customer routes) is meant to be 
sent to the providers (upstream).

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

I see not much harm if P1/22 is installed at the customer’s AS.
They need reachability for the rest of the P1/22 (besides the P1/24).
Likely, the aggregating AS announced the other components of
the aggregate P1/22 to the customer. Data traffic gets routed to those more 
specifics and the less specific (P1/22) is only a backup route in the customer's AS.

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

Referring to your * -- you may be right that AS operators 
(your customers) are smart :)
P1/22 gets installed and is a backup route in the customer's AS. 
There no harm and no need to filter it. 
The more specific routes (P1/24 and other components of P1/22) are primary.

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

When P1/24 reachability goes away, shouldn’t the aggregating AS
re-aggregate without the P1/24? Then the looping wouldn’t 
occur except may be for a short transient period. 
Additionally, at present, doesn’t the recovery happen fast?
Companies employ live standby BGP session etc. for fast recovery.

Thanks.

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