Subject: Fwd: [mpls] Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt

From: JP Vasseur <[email-masked]>
Date: Tue, 23 Jan 2007 22:47:24 -0800

Hi,

We had comments from one vendor so far (to be addressed in the next  
revision). No other comment ?

Thanks.

JP.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: November 14, 2006 9:06:51 AM EST
> To: [email-masked]
> Subject: [mpls] Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt
>
> Hi,
>
> As discussed last week, there's a need to document this behavior,  
> implementor's feed-back is more than welcome on this ID.
>
> Thanks.
>
> JP.
>
> Begin forwarded message:
>
>> From: JP Vasseur <[email-masked]>
>> Date: September 13, 2006 6:01:12 PM EDT
>> To: [email-masked]
>> Cc: Adrian Farrel <[email-masked]>, George Swallow  
>> <[email-masked]>, Loa Andersson <[email-masked]>
>> Subject: Fwd: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt
>>
>> Dear WG members,
>>
>> Some of you might recall the in-depth discussion that we had some  
>> time ago wrt to Soft Preemption. I think that we got a pretty  
>> clear consensus on the proposed solution. There was still a  
>> remaining issue related to the definition of "Hard Preemption"  
>> used in the ID. More precisely, some of you required  
>> clarifications on RFC3209 with regards to the behavior of a node  
>> upon the reception of a Path Error. Thus we have produced this ID,  
>> the aim of which is simply to clarify this aspect, thus hopping to  
>> be able to move forward on the Soft Preemption ID (of course, we  
>> will produce a new revision of the Soft Preemption ID referring to  
>> this new ID, once we'll get a consensus).
>>
>> Thanks.
>>
>> JP, Adrian and George.
>>
>> Begin forwarded message:
>>
>>> From: [email-masked]
>>> Date: September 10, 2006 3:50:01 PM EDT
>>> To: [email-masked]
>>> Subject: I-D ACTION:draft-vasseur-mpls-3209-patherr-00.txt
>>> Reply-To: [email-masked]
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> 	Title		: Node behavior upon originating and receiving
>>>                           Resource ReserVation Protocol (RSVP)  
>>> Path Error message
>>> 	Author(s)	: J. Vasseur, et al.
>>> 	Filename	: draft-vasseur-mpls-3209-patherr-00.txt
>>> 	Pages		: 8
>>> 	Date		: 2006-9-10
>>> 	
>>> The aim of this document is to describe a common practice with  
>>> regard
>>> to the behavior of a node sending a Resource ReserVation Protocol
>>> (RSVP) Path Error message and to the behavior of a node receiving an
>>> RSVP Path Error message for a particular Multi-Protocol Label
>>> Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP).
>>> This text does not define any new protocol extensions.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-vasseur-mpls-3209- 
>>> patherr-00.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] 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
>>> "get draft-vasseur-mpls-3209-patherr-00.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> 	[email-masked].
>>> In the body type:
>>> 	"FILE /internet-drafts/draft-vasseur-mpls-3209-patherr-00.txt".
>>> 	
>>> NOTE:	The mail server at ietf.org can return the document in
>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>> 	command.  To decode the response(s), you will need "munpack" or
>>> 	a MIME-compliant mail reader.  Different MIME-compliant mail  
>>> readers
>>> 	exhibit different behavior, especially when dealing with
>>> 	"multipart" MIME messages (i.e. documents which have been split
>>> 	up into multiple messages), so check your local documentation on
>>> 	how to manipulate these messages.
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID: <[email-masked]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls