[Idr] Re: AD review of draft-ietf-idr-deprecate-as-set-confed-set-16

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

Hi John, Warren:

Warren: Thank you. You took care of most of John's comments correctly. I differ a little on two of the points as explained below. 

[JS:] >### Section 6.2

[JS:] >I get why this is a good practice. I don’t get why it’s a mandatory practice, given that as you point out in Section 6.3, there is supposed to be a discard route covering the aggregate anyway. Would it make sense to change the MUST in this section to SHOULD?

I feel that "MUST" and "MUST NOT" in Section 6.2 can be left as they are.  The reason is as follows.  Section 6.2 and Section 6.3 are talking about different things with different goals (though within the aggregation context).  Suppose AS 3 is aggregating p1/24 and p2/24 contributed by customers AS 1 and AS 2, respectively, along with p3/23 that AS A owns but *does not currently utilize*. Thereby it forms an aggregate q/22 (= p1/24 + p2/24 + p3/23).  Section 6.2 is requiring not announcing q/22 to AS 1 or AS 2 but announcing p2/24 to AS 1 and p1/24 to AS 2. So, AS 1 will not route packets with destination in its own prefix p1/24 to AS A (in case AS 1 temporarily lost connection to its own subnet p1/24). Thus, data looping between AS 1 and AS A is prevented.  OTOH, Section 6.3 is reminding (as you say) about Rule #2 of Section 5.1 of [RFC4632]. In the current example, Rule #2 requires AS A to set "next hop" for the aggregate route q/22 to null destination (so any externally received packets destined to p3/23 are null routed).

John: With above explanation, do you feel it is OK to leave the MUST and MOST NOT as they are? I'm open to suggestions.

[JS:] ### Appendix C

[JS:] >In point 1, shouldn’t it be “one or more more-specific routes” and not “multiple more-specific routes”?

What we have in point 1 is an exact quote: 

1.  Rule #2 of Section 5.1 of [RFC4632]: A router that generates an aggregate route for multiple, more-specific routes must discard packets that match the aggregate route, but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination.

That is why we kept "multiple, more-specific routes" as is.  In any case, aggregation is performed on multiple more-specific routes (never on one route).  

Sriram