[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Hi Stephen,
On Jan 6, 2005, at 12:18 PM, Stephen Shew wrote:
<x-tad-smaller>I have read <draft-ietf-ccamp-loose-path-reopt-00.txt> and have some questions and comments.</x-tad-smaller>
<x-tad-smaller>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?</x-tad-smaller>
Correct (reference to "Make before Break" as defined in RFC3209 has been added).
<x-tad-smaller>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.</x-tad-smaller>
Downstream link traversed by the TE LSP indeed.
<x-tad-smaller>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?
</x-tad-smaller>
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.
<x-tad-smaller> 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.</x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller>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.</x-tad-smaller>
<x-tad-smaller>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?</x-tad-smaller>
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.
<x-tad-smaller>> -----Original Message-----</x-tad-smaller>
<x-tad-smaller>> From: owner-ccamp@ops.ietf.org</x-tad-smaller>
<x-tad-smaller>> [</x-tad-smaller><x-tad-smaller>mailto:owner-ccamp@ops.ietf.org</x-tad-smaller><x-tad-smaller>] On Behalf Of Adrian Farrel</x-tad-smaller>
<x-tad-smaller>> Sent: Wednesday, January 05, 2005 13:41</x-tad-smaller>
<x-tad-smaller>> To: ccamp@ops.ietf.org</x-tad-smaller>
<x-tad-smaller>> Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> This email starts a two week last call on </x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller><x-tad-smaller>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat</x-tad-smaller>
<x-tad-smaller>> h-reopt-00.txt</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> Please send your comments to the list or to the chairs by </x-tad-smaller>
<x-tad-smaller>> noon GMT on 20th January 2005.</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller>
<x-tad-smaller>> Thanks,</x-tad-smaller>
<x-tad-smaller>> Adrian and Kireeti</x-tad-smaller>