Re: Revised draft minutes

Arthi Ayyangar <arthi@juniper.net> Tue, 16 March 2004 16:10 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08324 for <ccamp-archive@ietf.org>; Tue, 16 Mar 2004 11:10:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H8m-0001EL-00 for ccamp-archive@ietf.org; Tue, 16 Mar 2004 11:10:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H86-00017X-00 for ccamp-archive@ietf.org; Tue, 16 Mar 2004 11:09:23 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B3H7G-0000yb-00 for ccamp-archive@ietf.org; Tue, 16 Mar 2004 11:08:30 -0500
Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3GpU-000O6e-3L for ccamp-data@psg.com; Tue, 16 Mar 2004 15:50:08 +0000
Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Gof-000Nry-9h for ccamp@ops.ietf.org; Tue, 16 Mar 2004 15:49:17 +0000
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i2GFnDBm088501; Tue, 16 Mar 2004 07:49:14 -0800 (PST) (envelope-from arthi@juniper.net)
Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i2GFnDJ20707; Tue, 16 Mar 2004 07:49:13 -0800 (PST) (envelope-from arthi@juniper.net)
Date: Tue, 16 Mar 2004 07:49:13 -0800
From: Arthi Ayyangar <arthi@juniper.net>
To: Adrian Farrel <adrian@olddog.co.uk>
cc: ccamp@ops.ietf.org
Subject: Re: Revised draft minutes
In-Reply-To: <095801c409bb$c78a7210$1100050a@Puppy>
Message-ID: <20040316073255.T80297@zircon.juniper.net>
References: <095801c409bb$c78a7210$1100050a@Puppy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Hi Adrian,

Just a couple of minor corrections below.

thanks,
-arthi

> Lou Berger presented an overview of work on Segment
> Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>   He also talked about what still needs to be done (next
>   steps), including more usage scenarios, more explanatory
>   text and see if the WG will adopt this work.
>
>   Arthi Ayyangar asked if the association object is required
>   even if we are only doing segment recovery (as opposed to
>   e2e).  She had follow up questions that Kireeti asked her
>   to take to the list.
---------> To the above you may want to add, "Arthi asked why couldn't we
extend the Detour Object to achieve the same".

>   Adrian polled for support of accepting this as a WG draft.
>   There was moderate support and no objection.
>
> ---
> Lou Berger went over Extensions to GMPLS RSVP Graceful
> Restart
> draft-aruns-ccamp-rsvp-restart-ext-00
>
>   He emphasized that egress restart is already covered in
>   RFC3473 and this work has no effect on that functionality.
>   He gave a brief overview and listed open issues.
>
>   Next steps include merging with other restart drafts and
>   seeing if this work can become a WG draft.
>

>   Arthi said that she feels that the document focuses too
>   much on the ERO. She feels that the draft should address
>   other issues and concerns with the mechanism.
-------> Replace with: "Arthi said that the text at the beginning of the
draft seems to talk only about the recovery ERO, although using the
RecoveryPath one can recover many objects besides the ERO. So the text
should be clarified to this effect."

>     Lou asked if she would like to contribute text.

-------> There was a discussion on adjacent node restart. "Arthi
asked why adjacent node restart was an issue being addressed in RSVP. She
pointed out that before this becomes an issue to be solved in RSVP, we would
first need to check if adjacent node restart even works for IGPs."

>   The chairs then asked for other discussion to go to the
>   list.
>
> ---
> Zafar Ali talked about Extensions to GMPLS RSVP Graceful
> Restart
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt
>
>   Kireeti said that he appreciated the honesty of the
>   authors in acknowledging other work.
>
>   Nurit Sprecher asked about the relationship to FRR and
>   similar issues.
>
>     Adrian agreed that these were important issues and had
>     been raised on the list in recent days. He asked the
>     authors to make sure that they cover the points in the
>     draft.
>
> ---
> Zafar then covered modifications to Hello procedures
> 1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
> 2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>   He wants to go forward with draft 1 above.
>
>   Adrian polled and there was some interest and no strong
>   objection.
>
>   Kireeti said that this work cannot be informational if
>   it has - or proposes - changes to a standard.
>
>   Zafar also wants draft 2 to be a WG document.
>
>   Kireeti said that we need to take this to the list, but
>   Zafar also needs to socialize the work he is doing so that
>   people may decide whether or not this is work we want to
>   do.
>
> ===
> Everything Else
> ---
> Emmanuel Dotaro gave status of Multi-region protection -
> draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
>
>   He briefly covered changes since previous versions.
>
>   He proposes that we may need to make changes to the
>   charter to include all of this work. In particular to
>   include in the charter the complete set of GMPLS
>   mechanisms for integrated control planes, and not only
>   multi-layer recovery (as it stands today).
>>   Adrian suggested that the authors need to get more people
>   involved in this important work and revisit this later.
>
> ---
> Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
> draft-vasseur-ccamp-isis-te-caps-00.txt
>
>   He would like to have this accepted as a WG document.
>
>   Adrian asked to hold off on this until after the OSPF talk
>   below.
>
> ---
> Seisho Yasukawa
> draft-vasseur-ccamp-ospf-te-caps-00.txt
>
>   He would like to have this accepted as a WG document.
>
>   Regarding both drafts, Kireeti is not sure that this work
>   belongs in this WG. The decision is driven by the
>   generality of its applicability. If we do take it on, their
>   needs to be a functional specification (independent of IGP)
>   as well.
>
>   He asked that further discussion be taken to the list.
>
> ---
> The Following presentations were postponed as we ran out
> of time. Adrian made a couple of brief comments as follows:
>   ---
>   Zafar Ali - Explicit Resource Control and Tracking
>   draft-zamfir-explicit-resource-control-bundle-03.txt
>
>     This work concerns identification of component links in
>     EROs and RROs.
>
>     A small group is currently examining other issues
>     concerning identification of component links in all
>     aspects of GMPLS. A draft is expected soon. Please mail
>     Adrian or the list, if you want to be involved in this
>     work.
>
>   ---
>   Lou Berger - Alarm Reporting
>   draft-berger-ccamp-gmpls-alarm-spec-01.txt
>
>     This draft is stable and complete in the view of the
>     authors.
>
>     A quick poll showed some support for this being a WG
>     document, and no opposition. This will be taken to the
>     list.
>