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

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

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