Subject: RE: I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt

From: "Ash, Gerald R (Jerry), ALARC" <[email-masked]>
Date: Mon, 27 Dec 1999 18:06:46 -0500

All,

Here is some additional background information on the attached internet
draft announcement for
http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-00.txt
An earlier version of this draft is located at:
http://www.ietf.org/internet-drafts/draft-ash-crlsp-modify-00.txt
This earlier draft is being progressed to the Informational RFC track, per
the agreement of the MPLS working group chairs.

Right now the essential material from the earlier draft has been
incorporated into Appendix C of the CR-LDP draft, which is located at:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-03.txt
We plan to remove Appendix C from the CR-LDP draft and make a reference to
the Informational RFC instead.  This Informational RFC indicates that the
protocol extensions (flag) is in the CR-LDP draft and makes reference to it.

Please let us know of any questions or comments.
Thanks,
Jerry Ash
------------------------------------------------------------
Gerald R. (Jerry) Ash
AT&T Labs
Manager, Standards Strategy
Room MT E3-3C37
200 Laurel Avenue
Middletown, NJ 07748
USA
Telephone  732-420-4578
Fax            732-368-6687
Email          [email-masked]
------------------------------------------------------------

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Monday, December 27, 1999 6:43 AM
> To:	IETF-Announce; @[email-masked]
> Cc:	[email-masked]
> Subject:	I-D ACTION:draft-ietf-mpls-crlsp-modify-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiprotocol Label Switching Working
> Group of the IETF.
> 
> 	Title		: LSP Modification Using CR-LDP
> 	Author(s)	: J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi,
>                           D. Fedyk,  D. Skalecki, L. Li
>  	Filename	: draft-ietf-mpls-crlsp-modify-00.txt
> 	Pages		: 8
> 	Date		: 23-Dec-99
> 	
> After a CR-LSP is set up, its bandwidth reservation may need to be
> changed by the network operator, due to the new requirements for the
> traffic carried on that CR-LSP [2].  This contribution presents an
> approach to modify the bandwidth and possibly other parameters of an
> established CR-LSP using CR-LDP [3] without service interruption.
> The LSP modification feature can be supported by CR-LDP with a minor
> extension of an _action indicator flag_ [3].  This feature has
> application in dynamic network resources management where traffic of
> different priorities and service classes is involved.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-crlsp-modify-00.txt
> 
> 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-ietf-mpls-crlsp-modify-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-ietf-mpls-crlsp-modify-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.
> 		
>

---

From: wei sun <[email-masked]>
Date: Tue, 28 Dec 1999 11:08:22 -0500 (EST)

Hi,

I have two doubts:

1. Why a new label is always assigned at every hop? In the case the LSP
after modification is just the same as the old one, can we just use the
old labels?

2. The release of the old labels works in an in-order fashion --- from
ingress node to egress node. Any reason for that?

Sorry if I miss something. Thanks,

Wei

---

From: Vasanthi Thirumalai <[email-masked]>
Date: Wed, 29 Dec 1999 12:58:03 -0500

Wei,
	See comments below:
> after modification is just the same as the old one, can we just use the

	I would think that  the authors motivation to suggest that a new label be
assigned in the scenario that you have mentioned is that there will not be a any
new procedures required at the LSRs to track new and old characteristics of the
LSP and also, this is a simpler way of doing it. Anyway, why  do you think one
would try to re-setup an LSP with exactly the same parameters as the original
one?

> ingress node to egress node. Any reason for that?

	My guess is that this is done to ensure that traffic is switched from the
old-LSP to the new one seamlessly. If it is not done in an in-order fashion an
LSR may release the label mapping corresponding to an old LSP even before the
new one is completely setup. 

-Vasanthi
-- 
------------------------------------------------
Vasanthi Thirumalai         Phone: 732-949-3787
Lucent Technologies         Room : 2J-643
101 Crawfords Corner
Holmdel, NJ-07733
------------------------------------------------

---

From: wei sun <[email-masked]>
Date: Wed, 29 Dec 1999 22:27:00 -0500 (EST)

Hi,

> would try to re-setup an LSP with exactly the same parameters as the original

Thanks for the comments. I guess my question is: In the case the LSP is
the same as the old one, can we just use the old labels without a re-setup
process? Since it's called modification, we should be trying to reuse as
much as possible instead of re-setting up a whole new LSP.

The answer I can think of is that the case above is just a special case,
and there is no way for us to know before hand that the LSP after
modification will be exactly the same.

Wei