Re: RSVP Restart (was Re: update GMPLS signaling documents)

[Gopal Kailad <gkailad@acm.org>]

Hi Yakov,


Yakov Rekhter wrote:

>Gopal,
>
>[clipped...]
>
>>>>>>If a node supports PSC as well as TDM or LSC interfaces, it
>>>>>>might want to advertise different set of parameters in the
>>>>>>RESTART_CAP object for data LSPs as opposed to SONET/WDM
>>>>>>LSPs which form bearer channels in transport networks.
>>>>>>Currently this is not possible.
>>>>>>
>>>>>>>Can you give us explicit examples as to why and what do
>>>>>>>you gain by giving different values for PSC, TDM ?
>>>>>>>
>>>>>>In case of PSC devices, it may be OK to remove state that
>>>>>>is not resynchronized at the end of the recovery period,
>>>>>>
>>>>>and the recovery period advertised might reflect that.
>>>>>
>>>>>>
>>>>>>But for LSPs in transport networks, one might want to
>>>>>>have a different recovery period to avoid any LSP from
>>>>>>going down because of recovery timer expiry.
>>>>>>
>>>>>There is no requirement for a node to advertise exactly the
>>>>>same Restart_Cap on all the interfaces. So, on PSC interfaces
>>>>>the node could advertise that it will remove the state that
>>>>>isn't syncronized at the end of the recovery period, while
>>>>>on the TDM interface precisely the same node could advertise
>>>>>that the LSPs would be kept even after the recovery time expires.
>>>>>
>>>>But to set up LSPs over TDM/LSC interfaces, the PSC interface
>>>>is going to be used for signaling - since control and data
>>>>planes are decoupled!  So, how will this help?
>>>>
>>>Help with what ? You asserted that it "is not possible" for
>>>"a node that supports PSC as well as TDM and LSC interfaces..
>>>to advertise different set of parameters in the RESTART_CAP
>>>object for data LSPs as opposed to SONET/WDM LSPs."
>>>
>>>I pointed out to you that your assertion is incorrect, as
>>>there is no requirement for a node to advertise exactly the
>>>same Restart_Cap on all of its interfaces.
>>>
>>I believe your assertion is misleading - If two nodes A and
>>B have multiple TDM/LSC links (with out of band signaling)
>>between them as well as a PSC link, (they are all unnumbered
>>interfaces), there will be only one Hello adjacency between
>>A and B, resulting in just one Restart_cap object advertised
>>in each direction.
>>
>>In that case, how can one advertise different values in the
>>Restart_cap object for TDM/LSC LSPs as opposed to data LSPs?
>>
>>Since there is only one adjacency, the suggestion above to
>>treat the node failure as control channel failure does not
>>work either, as the restarting node might want to get
>>resynchronized for data LSPs.
>>
>>I believe your assertion is possible only if all interfaces
>>are numbered.  
>>
>
>That is incorrect - what I described is possible if only the
>control channel is numbered (note that a control channel, just
>like any other link, could have multiple IP addresses assigned to it).
>
Good point - but this would result in more configuration work
for the operator.

Anyways, there are other problems as well and it appears that
just being able to advertise a separate set of Restart/recovery
timers for transport network sessions may not be enough, making
this a non-issue.  Please see my other email on transport
networks and RSVP.

Thanks,

Gopal



>
>
>>If so, this is a huge constraint - please
>>refer draft-ietf-ipo-carrier-requirements-00, sec 7.4.
>>
>
>In the context of UNI the (multiple) IP addresses assigned
>to a control channel could be locally defined. As such
>
>
>it would meet the requirements of section 7.4 of the draft
>you mentioned.
>
>
>
>Yakov.
>