Subject: grow: WGLC for draft-ietf-grow-collection-communities-02.txt

From: David Meyer <[email-masked]>
Date: Wed, 3 Mar 2004 23:14:04 -0800

This note starts the working group last call for 
	draft-ietf-grow-collection-communities-02.txt. The last
	call will end on 17 Mar 2004 at 1700 PST. Please send
	comments to the list.

	Thanks,

	Dave
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: Pekka Savola <[email-masked]>
Date: Sun, 7 Mar 2004 18:11:03 +0200 (EET)

> 	call will end on 17 Mar 2004 at 1700 PST. Please send

a pretty good document; with a bit of more text on 
applicability/caveats, this is probably done.

substantial
-----------

==> there seems to be a big operational problem here, which should
probably be discussed a bit more.  That is, a researcher/average guy
usign route collection data has no way of knowing whether the
communities in the database reflect this BCP or not.  I.e., one could
be led to believe that one should interpret the communities using the
definitions of this BCP, even though the communities were the ones
used internally by the exporter -- leading to misinterpretation of
data.

There are probably a few fixes to this:
 - route collector scrubs out all communities form the incoming 
routes, unless when setting up or reconfiguring the peer they have 
agreed to use these communities, or

 - require the use of a specific AS number to designate that these 
communities are special.  But then the data would not be as useful.

6.  Acknowledgments

   The community encoding described in this document germinated from an
   interesting suggestion from Akira Kato at WIDE. In particular, the
   idea would be to use the collection community values to select paths
   that would result in (hopefully) more efficient access to various
   services. For example, in the case of RFC 3258 [RFC3258] based DNS
   anycast service, BGP routers may see multiple paths to the same
   prefix, and others might be coming from the same origin with
   different paths, but others might be from different region/country
   (with the same origin AS).

==> this draft is an obvious way to try to "standardize" the use of 
community values -- or rather, move towards a more homogenous set of 
them.  Shows pretty clearly especially in this section..  I have no 
objection to this, but maybe a bit more of "truth in advertising" 
would not hurt.

editorial
---------

  scope of redistribution of routes within a providers network, and to
   it's customers and peers. Communities are also used for a wide

==> s/it's/its/

   Internal more specific routes are those routes which are frequently 
   used for circuit balancing purposes, IGP route reduction, and also

==> s/circuit/circuit load/

   In this section we provide standardized RFC 1997 [RFC1997] community
   values for the categories described above. RFC 1997 communities

==> s/standardized/suggested/ (or something softer like that)?

   For example, the encoding for a national route over a terrestrial   
   link in AS 10876 from the Fiji Islands would be:

==> are there actually even terrestrial links to Fiji?  :)

   Note that a configuration language might have allow the specification
   of this community as 10876:4338 (0x1F2 == 4338 decimal).

==> s/have allow/require/ ?

   The two-octet AS specific extended community attribute encodes the   
   service provider's two octet Autonomous System number assigned by
   IANA in the Global Administrator field, and the Local Administrator
   field may encode any information.

==> IANA does not assign AS's directly, so one should reword this a 
bit.

5.  Intellectual Property

==> RFC3667 (AFAIR) includes a new kind of IPR boilerplate, but this 
isn't all that strongly required for now AFAIK.

            Finally, routes exported to a route collector SHOULD also
   be tagged with the NO_EXPORT community (0xFFFFFF01).

==> this is an operational, not an implementation, requirement, so 
s/SHOULD/should/ ?

   [HOUSTON]       Huston, G., "Interconnection, Peering, and

==> s/HO/H/

   [VLPS]          Kompella, K., et. al., "Virtual Private LAN
                   Service", draft-ietf-l2vpn-vpls-bgp-00.txt,
                   Work in Progress.

==> this might result in the work being blocked, suggest moving to 
Informational.

9.2.  Informative References

==> many of these are "process" documents, which aren't probably 
needed in the document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: David Meyer <[email-masked]>
Date: Sun, 7 Mar 2004 16:54:48 -0800

Pekka,

>> objection to this, but maybe a bit more of "truth in advertising" 

	I'm not sure what you mean. Can you expand just a bit?
	Much appreciated. 

	Thanks,

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Mar 2004 08:48:47 +0200 (EET)

> 	I'm not sure what you mean. Can you expand just a bit?

The acknowledgement section describes how wonderful these community 
values are for path selection purposes, e.g., anycast services.

However, such uses are beyond the scope of the current document, 
right? :-)  It's all about exporting for data collection, in which 
case path selection etc. are irrelevant.

So, it seems that this method appears to give BCP on not only the
exported communities, but also on how to organize your internal
community values.

I don't have objection to that, but if the ultimate goal would be to
try to get coherence to the community values used for various ISPs for
marking the routes (not a bad goal in itself), it might be better not
to try to disguise the proposal as a "data collection communities" if
it's all the "communities".

---

From: David Meyer <[email-masked]>
Date: Mon, 8 Mar 2004 07:18:10 -0800

>> values are for path selection purposes, e.g., anycast services.

	Ah, I see. Kato-san had pointed out that if you had such
	information, perhaps you use if for such applications.

>> case path selection etc. are irrelevant.

	Understand. See above.

>> exported communities, but also on how to organize your internal

	It started out as the former, but many folks have
	mentioned the latter as an application.

>> it's all the "communities".

	No disguising intended. The document was written to
	standardize the communities received for BGP data
	collection purposes. However, if folks decide that they
	would like to use these encodings for their internal
	community structure, that would certainly not be
	prohibitied.

	Given all of that, do you think (a). I should remove the
	part about path selection (it was really just an
	application you could do in the event you were using
	these encodings internally), (b). change the title, or 
	(c). other?

	Thanks,

	Dave

---

From: David Meyer <[email-masked]>
Date: Mon, 8 Mar 2004 10:10:37 -0800

>> applicability/caveats, this is probably done.

	The terabytes (or more) of data out there certainly do
	not reflect this draft. That will not change. 

>> communities are special.  But then the data would not be as useful.

	Neither is feasible. The first destroys information that
	people are using, and the second would destroy a great
	deal (like close to all) of the untility of doing
	this. We need to start somewhere, so this doc is that
	stake in the ground.  

	BTW, the best we're (those of us in the data
	collecting/archiving biz) going to be able to do is
	document  which peers do use this scheme (although it
	seems that it will be obvious as soon as one starts
	looking at communities).

>> objection to this, but maybe a bit more of "truth in advertising" 

	Again, I'm not sure what we're talking about here.
	This document describes community values for BGP data
	collection; if the classification and encoding scheme
	described here turns out to be useful to folks for their
	internal community structure, great. However, that is
	their choice. Finally, the document certainly doesn't
	attempt to prohibit that outcome. 

	I haven't changed the above text because I don't see your
	point. If you can describe it in a different way maybe I
	will understand.

>> ==> this might result in the work being blocked, suggest moving to 

	All done, thanks. BTW, citation to [EXTCOMM] is also a
	normative reference to a I-D, so we'll probably block on
	that too. 

	Thanks,

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Mar 2004 18:22:29 +0200 (EET)

Merging the two threads...

>       seems that it will be obvious as soon as one starts

OK.  Then I guess what we end up with just noting this as a particular 
problem, and that's it.

Maybe add into introduction, as second-to-last pargraph, something 
along the lines of:

   Note that those that are doing data analysis are likely to have 
   hard time trying to figure out which ASs have exported their 
   routing information using these communities and which not.  Unless 
   care is observed (e.g., by the route collectors documenting which 
   peers have stated they export these communities), different 
   communities could be easily confused, leading to wrong analysis and 
   research based on the data.

[.....]

> 	community structure, that would certainly not be

OK.
 
> 	these encodings internally), (b). change the title, or 

I don't have much preference in any way.  The easiest fix, unless 
others feel differently, might be inserting some handwaving  around 
the path selection (as it being out of scope, but potentially useful), 
and rewrite this:

                                               These communities are
   not (necessarily) intended for internal use by service providers.
   Rather, they are meant to mirror the information that many service
   providers carry today, and to be a standardized representation of
   that information.

to a new paragraph (to make it more visible) like:

   These communities represent a significant part of information 
   carried by service providers as of this writing, and could be 
   useful in the internal use by service providers.  However, such use
   is beyond the scope of this memo.

---

From: David Meyer <[email-masked]>
Date: Tue, 9 Mar 2004 08:38:14 -0800

>>    is beyond the scope of this memo.

Will do. Thanks for the comments. Dave
_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/