Subject: RE: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

From: "Stephen Shew" <[email-masked]>
Date: Thu, 6 Jan 2005 12:18:20 -0500

I have read <draft-ietf-ccamp-loose-path-reopt-00.txt> and have some
questions and comments.

1. The actual reoptimization procedure is not specified as this is done via
the make before break method or some other way.  Only the triggers to cause
reoptimization are specified.  Is this correct?

2. In mid-point explict notification mode where a link or node is specified,
I am unsure what link is being referred to.  Because this is an LSP, it is
either the link upstream to to the mid-point node or the one downstream.  Is
there some RSVP convention that distinguishes this?  I think it is
downstream but don't know for sure.

3. Again in mid-point explict notification mode it is not clear what is
meant by "the TE database must be updated".  Does it mean that the link or
node is removed from the local TE database so that the first upstream node
that expands the ERO can compute around the link/node?  If so, then it is
necessary to indicate what the link and node are for the non-packet LSP
case.  That is, I am assuming that the RSVP signaling process (control) is
separated from the bearer plane (e.g., a SONET cross connect).  It is the
identity of the control "node" that is put into the PathErr whereas the
bearer "node" has a different identity.

To do this, I would suggest that the IF_ID ERROR_SPEC object (from
[RFC3473]) and all of the TLVs it may contain including from
draft-ietf-ccamp-crankback-03.txt be added to the PathErr message when
Error sub-codes 7&8 are used.  This will enable the actual link to be known.
In the case of node, Type 8 (NODE_ID) would identify the bearer node.

For security reasons, if the LSP spans domains, the OSPF_AREA or
AUTONOMOUS_SYSTEM TLVs could be used when error subcode 8 is passed
upstream.

4. In the same context as point 3, does the head-end LSR do anything to its
TE database based on the link or node Error sub-codes?

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 05, 2005 13:41
> To: [email-masked]
> Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
> 
> 
> This email starts a two week last call on 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat
> h-reopt-00.txt
> 
> Please send your comments to the list or to the chairs by 
> noon GMT on 20th January 2005.
> 
> Thanks,
> Adrian and Kireeti

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Jan 2005 04:32:14 -0500

Hi Stephen,

On Jan 6, 2005, at 12:18 PM, Stephen Shew wrote:

> 1. The actual reoptimization procedure is not specified as this is 
> done via the make before break method or some other way.  Only the 
> triggers to cause reoptimization are specified.  Is this correct?
>

Correct (reference to "Make before Break" as defined in RFC3209 has 
been added).

> 2. In mid-point explict notification mode where a link or node is 
> specified, I am unsure what link is being referred to.  Because this 
> is an LSP, it is either the link upstream to to the mid-point node or 
> the one downstream.  Is there some RSVP convention that distinguishes 
> this?  I think it is downstream but don't know for sure.
>

Downstream link traversed by the TE LSP indeed.

> 3. Again in mid-point explict notification mode it is not clear what 
> is meant by "the TE database must be updated".  Does it mean that the 
> link or node is removed from the local TE database so that the first 
> upstream node that expands the ERO can compute around the link/node? 

No since no such reroute by intermediate node is proposed here as the 
mechanism is entirely targeted for head-end reoptimization. The point 
here is just for a node to update its TED so as to take into account 
the notification of the link that will be removed for maintenance, 
should further path computation be required. Note that such procedure 
is usually followed by current implementations in other contexts.

>  If so, then it is necessary to indicate what the link and node are 
> for the non-packet LSP case.  That is, I am assuming that the RSVP 
> signaling process (control) is separated from the bearer plane (e.g., 
> a SONET cross connect).  It is the identity of the control "node" that 
> is put into the PathErr whereas the bearer "node" has a different 
> identity.
>
> draft-ietf-ccamp-crankback-03.txt be added to the PathErr message 
> when  Error sub-codes 7&8 are used.  This will enable the actual link 
> to be known.  In the case of node, Type 8 (NODE_ID) would identify the 
> bearer node.
>
> 4. In the same context as point 3, does the head-end LSR do anything 
> to its TE database based on the link or node Error sub-codes?
>

As in the previous case: note of course that the Head-end would not 
update its TED in the context of inter-area/AS TE if the link/node to 
be maintained does not reside in the head-end area.

Thanks for your comments.

JP.