Subject: RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-cr lsp -modify-03.txt"

From: "Sharma, Prem" <[email-masked]>
Date: Fri, 13 Apr 2001 14:33:21 -0700

Hi Don,
 
I feel, the requirement that CRLSP modification procedures described in the 
draft, are applicable to strictly routed LSPs only, is a MAJOR requirement.
This is just not there in the draft. Do you folks want to address this in
the 
next revision of the draft?
 
One more thing, in my opinion, nothing precludes that modifications should
not be 
allowed on loosely routed hops. There could be a requirement. This is a
different
case that current draft doesn't address that.
 
Thanks.
Prem

-----Original Message-----
From: Don Fedyk [mailto:[email-masked]]
Sent: Friday, April 13, 2001 8:21 AM
To: Loa Andersson
Cc: Sharma Prem; manoj juneja; [email-masked]
Subject: RE: RE: Valid Race Condition related to draft "draft-ietf-mpls-cr
lsp -modify-03.txt"

Loa 

The draft was targeted for strictly routed LSP ingress to egress 
that are generated by constraints. The function it provide is 
defining the behavior of TLVs defined to correlate the paths 
attributes. The downstream nodes recognize this as a path 
request for the same LSP, with changed attributes, allowing path 
processing to continue where it might otherwise be aborted. 
Your solution below yields non optimal paths in many cases 
and provides the motive for the draft. The paths share LSPid. 

Don 

> -----Original Message----- 
> From: Loa Andersson [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, April 12, 2001 10:04 AM 
> To: Fedyk, Don [BL60:2868:EXCH] 
> Cc: Sharma Prem; manoj juneja; [email-masked] 
> Subject: Re: RE: Valid Race Condition related to draft 
> "draft-ietf-mpls-crlsp -modify-03.txt" 
> 
> 
> Don, 
> 
> do I understand you correctly that the draft is applicable only in 
> the situation where you have a strictly routed LSP ingress to egress? 
> If so I rest my case, but I also fail to see why we need the draft. 
> Just "locally" set up your alternate paths, signal that the traffic 
> will be sent on the new path, switch over the traffic and tear the 
> old path down. Nothing modificational (is ther such a word?) about 
> it. 
> 
> /Loa 
> 
> ----- Original Message ----- 
> > Loa, Sharma, Manoj: 
> > 
> > Let me see if I can clarify my position on this. 
> > My mail has been backed up lately. Sorry for the delay. 
> 
> > > -- 
> > > Loa Andersson 
> > > Chief Architect, 
> > > Utfors Research, Architecture and Future Lab (URAX) 
> > > Utfors AB 
> > > Råsundavägen 12 
> > > Box 525, 169 29 Solna 
> > > Office          +46 8 5270 2000 
> > > Office direct   +46 8 5270 5038 
> > > Mobile          +46 70 848 5038 
> > > Email           [email-masked] 
> > > WWW             www.utfors.se 
> > > 
> > 
> 
>

---

From: "Loa Andersson" <[email-masked]>
Date: Mon, 23 Apr 2001 13:05:32 +0200

All,

some comments to this discussion.

I agree with Perm, if the draft is only applicable to LSPs where every
node is explicitly routed, that needs to be explicitly state early in
the draft. Also know from some offsets communication that "the 
explicit routed only" approach  is under some debate.

Given that we can have LSPs where other constraints are important, I
would
be interested in combining dynamic routed CR-LSPs (routed on other 
constraints than explicit nodes), with one explicitly routed node, 
e.g. for performance measurements. I would also be interested to be 
able to make those  measurements at different places, a reason for 
changing (modifying) the LSP, drop one explicitly routed node and 
replace with another.

I'm not concerned over have the loosely routed part of an LSP staying
alive of the strictly routed part goes away :-), but given that I can
retry if the a node in the loosely routed part of the LSP NAK a
request,
but not if an explicitly routed node does it. Need to distinguish
between
cases. Of course this is not a problem if explicit routed only.

It is not only CR-LDP that sets up CR-LSPs, it is much more common to
do so by RSVP-TE, hence my reflection on the need to something for 
RSVP-TE.

/Loa