Subject: [rrg] Recommendation

From: Tony Li <[email-masked]>
Date: Fri, 26 Mar 2010 12:33:51 -0700

Hi all,

For those that weren't able to attend, the recommendation of the RRG is that
the IETF pursue work in:

- AIS (Aggregation in Increasing Scopes)

- ILNP 

- Automating renumbering

Full slides are available here:
http://www.ietf.org/proceedings/10mar/slides/RRG-0.pptx

Also, in the interests of leaving a permanent record of the work done, we
would like to encourage authors to move their documents to be full-fledged
RFCs.  If you are interested in this, please contact the chairs promptly.

Regards,
Lixia & Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Mar 2010 09:46:58 +1300

> Automating renumbering

I'd like to flag the fact that "Renumbering still needs work"
(draft-carpenter-renum-needs-work-05.txt) by Ran Atkinson,
Hannu Flinck, and me has been approved as an Informational RFC
by the IESG, and is now in the RFC Editor queue.

That document is a done deal, but I hope it may act as useful
input.

Regards
   Brian Carpenter

On 2010-03-27 08:33, Tony Li wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Mar 2010 10:44:02 +1300

> - AIS (Aggregation in Increasing Scopes)

For my education, does this require any standards action,
or is it just a small matter of implementation?

    Brian

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 26 Mar 2010 16:31:32 -0700

> or is it just a small matter of implementation?

my personal opinion is that you can do all of the AIS things without
any standards, however, if you wanted to have a simpler method to
configure this across an ASN then a protocol would be helpful
(probably having a standardized protocol that works across vendors)
and that'd include some ietf work, yes?

-Chris

---

From: Tony Li <[email-masked]>
Date: Fri, 26 Mar 2010 19:32:27 -0700

> and that'd include some ietf work, yes?

Concur, and there's also the need for more explicit documentation.  This is
sufficiently complicated that it needs a cookbook explanation so that
operators can implement this (without making their heads hurt).

There's also a small matter of operational experience that needs to be
gained (at scale) and should be documented.  Experience suggests that we
will learn some things the hard way in this process.

Regards,
Tony