headers
Adrian Farrel | 1 Oct 2005 12:56
Picon

Reminder: ASON Routing evaluation Last Call

Just a reminder that this WG last call ends on 2nd October.

I recall that in Paris there were a couple of comments that "few minor
editorial changes" were needed. If you don't comment during the last call,
could be that you have changed your mind.

Thanks,
Adrian
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Oct 2005 21:50
Picon
Favicon

I-D ACTION:draft-ietf-ccamp-inter-domain-rsvp-te-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Inter domain GMPLS Traffic Engineering - RSVP-TE extensions
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ietf-ccamp-inter-domain-rsvp-te-02.txt
	Pages		: 24
	Date		: 2005-10-3
	
This document describes extensions to Generalized Multi-Protocol Label
Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
(RSVP-TE) signaling required to support mechanisms for the establishment
and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
(LSPs), both packet and non-packet, that traverse multiple domains. For
the purpose of this document, a domain is considered to be any
collection of network elements within a common realm of address space or
path computation responsibility. Examples of such domains include
Autonomous Systems, IGP areas and GMPLS overlay networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-rsvp-te-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Oct 2005 21:50
Picon
Favicon

I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Extensions to GMPLS RSVP Graceful Restart
	Author(s)	: A. Satyanarayana, et al.
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-04.txt
	Pages		: 24
	Date		: 2005-10-3
	
This document describes extensions to the RSVP Graceful Restart
   mechanisms defined in RFC 3473.  The extensions enable the recovery
   of RSVP signaling state based on the Path message last sent by the
   node being restarted.  Previously defined Graceful Restart
   mechanisms, also called recovery from nodal faults, permit recovery
   of signaling state from adjacent nodes when the data plane has
   retained the associated forwarding state across a restart.  These
   mechanisms do not fully support signaling state recovery on ingress
   nodes or recovery of all RSVP objects.  The presented extensions use
   the RSVP Hello extensions defined in RFC 3209, and extensions for
   state recovery on nodal faults defined in RFC 3473.  With the
   presented extensions the restarting node can recover all previously
   transmitted Path state including the Explicit Route Object and the
   downstream (outgoing) interface identifiers.  The extensions can also
   be used to recover signaling state after the restart of an ingress
   node.  The extensions optionally support the use of Summary Refresh,
   defined in RFC 2961, to reduce the number of messages exchanged
   during the Recovery Phase when the restarting node has recovered
   signaling state locally for one or more LSPs.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Farrel | 2 Oct 2005 11:58
Picon

Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

Hi,

Here are my comments on this I-D. Most of these comments are very minor
editorial nits. We need to try to get these resolved at this stage because
it will improve the speed at which the IESG can review the I-D and reduce
the time in the RFC Editor process. However, there are a few more
substantial questions hidden in the middle of what I have written.

I suspect that this email will take some while to show up at the CCAMP
mailing list because psg (which hosts the CCAMP list) is in dispute with
my ISP. Sorry about that.

Thanks,
Adrian

====

Section 4

   The following functionality is expected from GMPLS routing protocol
s/protocol/protocols/

Section 4
   - Processing of routing information exchanged between adjacent
     levels of the hierarchy (i.e. Level N+1 and N) including
     reachability and upon policy decision summarized topology
     information.
s/and upon policy decision summarized/and (upon policy decision)
summarized
(Continue reading)

Permalink | Reply | 3 comments |
headers
dimitri papadimitriou | 4 Oct 2005 09:17

Re: Last call comments on draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt

hi adrian

Adrian Farrel wrote:

> Hi,
> 
> Here are my comments on this I-D. Most of these comments are very minor
> editorial nits. We need to try to get these resolved at this stage because
> it will improve the speed at which the IESG can review the I-D and reduce
> the time in the RFC Editor process. 

thank for commenting here this will help in progressing the document

> However, there are a few more
> substantial questions hidden in the middle of what I have written.

will provide on the list how these comments have been addressed when 
document will be re-submitted (assuming that the last call is over now)

> I suspect that this email will take some while to show up at the CCAMP
> mailing list because psg (which hosts the CCAMP list) is in dispute with
> my ISP. Sorry about that.
> 
> Thanks,
> Adrian
> 
> ====
> 
> Section 4
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Petch | 6 Oct 2005 12:36

Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

Adrian

I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags.  This has reflect
(31) while RFC3471 has reflect as bit 0.

As Joan says, "The BITS as specified look backwards when viewing the TLV".

This is fine if one is MSB, the other LSB (although that might be worth adding a
note about).

 Tom Petch

----- Original Message -----
From: <jcucchiara <at> mindspring.com>
To: "Adrian Farrel" <adrian <at> olddog.co.uk>; <tnadeau <at> cisco.com>;
<ccamp <at> ops.ietf.org>
Cc: <bwijnen <at> lucent.com>; <jcucchiara <at> mindspring.com>
Sent: Friday, September 30, 2005 4:13 AM
Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

>
> hi Adrian,
>
> Please see comments inline below, I have snipped parts where we
> are in agreement.
>
> thanks, joan
>
>
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
jcucchiara | 10 Oct 2005 03:55
Picon

Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt


Adrian,

Please add a note as to why the bits are reversed for the managed object.

Thanks,
   Joan

----- Original Message -----
From: Adrian Farrel <adrian <at> olddog.co.uk>
To: Tom Petch <nwnetworks <at> dial.pipex.com>; Thomas D. Nadeau
<tnadeau <at> cisco.com>; <ccamp <at> ops.ietf.org>
Cc: <jcucchiara <at> mindspring.com>
Sent: Sunday, October 09, 2005 7:18 AM
Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

> Hi Tom,
>
> > I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags.  This has
> reflect
> > (31) while RFC3471 has reflect as bit 0.
> >
> > As Joan says, "The BITS as specified look backwards when viewing the
> TLV".
> >
> > This is fine if one is MSB, the other LSB (although that might be worth
> adding a
> > note about).
>
> You are both right.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian Farrel | 9 Oct 2005 13:01
Picon

Fw: 64th IETF - DRAFT Agenda

Hi,

Early plans have CCAMP scheduled as 
MONDAY, November 7, 2005
0900-1130 Morning Session I 
RTG  ccamp      Common Control and Measurement Plane WG

This may get changed.

Cheers,
Adrian
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 9 Oct 2005 13:18
Picon

Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

Hi Tom,

> I am still unsure about MSB/LSB in IANAGmplsAdminStatusFlags.  This has
reflect
> (31) while RFC3471 has reflect as bit 0.
>
> As Joan says, "The BITS as specified look backwards when viewing the
TLV".
>
> This is fine if one is MSB, the other LSB (although that might be worth
adding a
> note about).

You are both right.
We have reversed the order of the bits in the IANA MIB and also filled the
gap with "reserved" bits.

Cheers,
Adrian
Permalink | Reply | 4 comments |
headers
jcucchiara | 10 Oct 2005 15:03
Picon

Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt


----- Original Message -----
From: Adrian Farrel <adrian <at> olddog.co.uk>
To: <jcucchiara <at> mindspring.com>; Tom Petch <nwnetworks <at> dial.pipex.com>;
Thomas D. Nadeau <tnadeau <at> cisco.com>; <ccamp <at> ops.ietf.org>
Cc: <bwijnen <at> lucent.com>
Sent: Monday, October 10, 2005 6:40 AM
Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

> Hi Joan,
>
> > Please add a note as to why the bits are reversed for the managed
> object.
>
> No, no, no, no! :-)
>
> I said...
>
> > > You are both right.
> > > We have reversed the order of the bits in the IANA MIB and also filled
> the
> > > gap with "reserved" bits.
>
> That means we have changed the order from what it used to be to what you
> have asked for.

Okay, sorry for my confusion.

-Joan
(Continue reading)

Permalink | Reply | 0 comments |

Gmane