Subject: Re: [Idr] WGLC for draft-ietf-idr-deprecate-as-sets

From: Larry Blunk <[email-masked]>
Date: Fri, 01 Apr 2011 13:29:16 -0400

On 03/31/2011 04:54 AM, Jeffrey Haas wrote:
> O
>
> P.S. At the time I was becoming involved in BGP standards, the archives were
> somewhat divided between Merit and, I think ANS?
> _______________________________________________
>

    The following archives have a number of discussions
on AS_SET's  in BGP4.

ftp://ftp.ietf.org/concluded-wg-ietf-mail-archive/bgp/

  -Larry

---

From: Warren Kumari <[email-masked]>
Date: Sun, 24 Apr 2011 12:59:16 -0400

After integrating some (off-list) comments (and discussions with the chairs) it was determined that we have enough changes that rev'ing the doc and restarting LC is the right thing to do...

By far the largest change in the doc is the addition of Appendix A (helpfully provided by Sriram).

There were also numerous wording changes, some nits, etc.
For your clicking pleasure, the latest version is at: https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/

And the diff: http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-02.txt&url2=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-03.txt

Please review this new version (-03) and:
a: let us know if the draft is still acceptable and 
b: if the addition of Appendix A helps or hurts the doc.

I appreciate everyone's time and review on this -- I'm sure y'all are almost as tired of this doc as I am :-P

W

On Mar 30, 2011, at 3:04 PM, John Scudder wrote:

> Folks,
> 
> This is to start a working group last call for draft-ietf-idr-deprecate-as-sets-02.  Please send comments by April 13, 2011.
> 
> http://tools.ietf.org/html/draft-ietf-idr-deprecate-as-sets-02
> 
> Thanks,
> 
> --John
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 24 Apr 2011 18:22:01 -0400

In message <[email-masked]>
Warren Kumari writes:
>  
> After integrating some (off-list) comments (and discussions with the
> chairs) it was determined that we have enough changes that rev'ing the
> doc and restarting LC is the right thing to do...
>  
> There were also numerous wording changes, some nits, etc.  For your
> clicking pleasure, the latest version is at:
> https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-sets/
>  
> And the diff:
> http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-02.txt&url2=http://www.ietf.org/id/draft-ietf-idr-deprecate-as-sets-03.txt
>  
>  

Warren,

Please remove this sentence (which you just added to "Security
Considerations") "Future work will update the protocol to remove
support for the AS_SET path segment type of the AS_PATH attribute."
This would consitute a change to WG charter that is not approved and
therefore the draft cannot go forward with this sentence.

The following sentence in the appendix is also inaccurate "An AS
should proxy aggregate only prefixes which belong to its
administrative domain."  Consenting adults may aggregate prefixes for
which they both have components of the aggregate, though you should
word it differently in the next iteration.  The key is to have
agreement from the other party, exchange more specifics, and both
aggregate only the more specifics to any peer but each other.  This
works for two or more administrative domains though the consenting
adults analogy get a little wierd so we shouldn't go there.

Proxy aggregation is by definition aggregating someone else's prefix,
so the sentence "An AS should proxy aggregate only prefixes which
belong to its administrative domain." contains a contradiction.  The
point is aggregate only more specifics.  Proxy aggregation should be
with consent of other parties and adequate consideration of
consequences.  It may be necessary to proxy aggregate without consent
if some provider routinely leaks out tons of more specifics and has
proven to be clueless and/or unresponsive.

I'm also not fond of the title.  The word "depricate" should be absent
in the title or anywhere else.

Curtis