Re: [GROW] Virtual Aggregation as GROW working group item

["Joel M. Halpern" <jmh at joelhalpern.com>]

I would like to see Grow work on these documents.
My inclination would be to target the for publicaiton as Informational RFCs.

I do think we need an I-D that explores / explains the applicable space 
better, so folks can evaluate the cost-benefit tradeoff of using this 
approach.  Whether that ends up dying off, becoming its own document, or 
incorporated in part into the main document, is much less of an issue 
for me.

Yours,
Joel M. Halpern

PS: I presume that there are some procedural obstacles to be overcome in 
adopting this work.  If the WG wants to do this, and if the chairs want 
some help dealing with any procedural obstacles, I am happy to help.

Paul Francis wrote:
> From:
> Paul Francis <francis at mpi-sws.org>
> To: grow at ietf.org
> Date: 04/24/2009 05:01 PM
> Subject: [GROW] Virtual Aggregation as GROW working group item
> Sent by: grow-bounces at ietf.org
>
> Gang,
>
> I would like to start the discussion of making Virtual Aggregation, which 
> I presented at the GROW meeting in SF, a working group item.
>
> A new version of the document has been posted, which mainly consists of 
> minor clarifications from folks who make up an expanded author list 
> (Zhang, Jen, and Raszuk).  It is at 
> http://www.ietf.org/internet-drafts/draft-francis-intra-va-01.txt.
>
> Note that there are two companion documents associated with this, one each 
>
> on the specifics of MPLS and IP-in-IP tunnels in support of VA.  These 
> have not been updated, though we expect them to be soon.  (These are at 
> http://tools.ietf.org/id/draft-francis-va-tunnels-mpls-00.txt and 
> http://www.ietf.org/internet-drafts/draft-xu-va-tunnels-gre-00.txt 
> respectively)
>
> I think that there are mainly two things to discuss:
>
> 1.  What additional documentation, if any, is needed (requirements, 
> scenarios, MIB, ....)?
> 2.  What should the status of the produced RFCs be (informational, BCP, 
> standard)?
>
> Regarding the first, I do think that a requirements/scenarios document is 
> a good idea, but would like to hear opinions.
>
> Regarding the second, there are arguments for and against each type. 
> Strictly speaking no protocol changes are needed (except for a case 
> involving GRE tunnels with key values, which require an extended 
> communities attribute to convey the key info).  So informational or BCP 
> could both work.  I'm inclined towards BCP, but would like to hear 
> opinions.  Even possibly we could start this as a working group item 
> without making this decision just yet.
>
> Thanks all,
>
> PF
>
> _______________________________________________
> GROW mailing list
> GROW at ietf.org
> https://www.ietf.org/mailman/listinfo/grow