RE: G.RSVP-TE in OTN - Refresh mechanism

["Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>]

Diego,

The full paragraph reads:

   During this waiting period, all Hello messages MUST be sent with a
   Dst_Instance value set to zero (0), and Src_Instance should be
   unchanged.  While waiting, the node SHOULD also preserve the RSVP and
   MPLS forwarding state for (already) established LSPs that traverse
   the link(s) between the node and the neighbor.  In a sense with
   respect to established LSPs the node behaves as if it continues to
   receive periodic RSVP refresh messages from the neighbor.  The node
   MAY clear RSVP and forwarding state for the LSPs that are in the
   process of being established when their refresh timers expire.
   Refreshing of Resv and Path state SHOULD be suppressed during this
   waiting period.



The clear intent is that established LSPs SHOULD not be torn down due to a
loss of refresh messages when RSVP knows that the control channel is not
functional. LSPs that are not yet fully established MAY be torn down.

Still, all of this is in the context of using this optional procedure. Does
this apply when the optional procedure is not used, but a control channel
failure is detected by other means, e.g. LMP?

Michael

> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: Wednesday, September 11, 2002 3:14 AM
> To: mmandelberg@fwion.com
> Cc: ccamp
> Subject: RE: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> 
> Hi Michael,
>             thank you for your advice, but IMHO that section 
> postulates
> that refresh messages are in fact used(quoted from the draft)
> 
> "In a sense with respect to established LSPs the node behaves as if it
> continues to
>  receive periodic RSVP refresh messages from the neighbor."
> 
> that as fas as I understood means that refresh messages are 
> sent between
> two neighbouring TNEs.
> 
> My question is: is there a consensus in this WG to eliminate 
> this need, for
> those LSP that are inherently hard state (SDH/SONET, WDM, G.709)?
> 
> Best regards,
>              Diego.
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: diego.caviglia@marconi.com
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> ----------------------------------------------------------------
> Fatti non foste a viver come bruti
> ma per seguir virtute e canoscenza
> 
> Dante Alighieri Inferno Canto XXVI
> 
> 
> 
> "Michael I Mandelberg(Isaac)" <mmandelberg@fwion.com>@ops.ietf.org on
> 10/09/2002 20.42.32
> 
> Sent by:  owner-ccamp@ops.ietf.org
> 
> 
> To:   ccamp@ops.ietf.org
> cc:
> 
> Subject:  RE: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> This is addressed in the case of a loss of the control 
> channel (section 9
> in
> draft-ietf-mpls-generalized-rsvp-te-08.txt). However, this is in the
> context
> of the RSVP Hello protocol.
> 
> I assume that the same rule applies if relying on LMP for 
> control channel
> management. I think that this should be stated explicitly in 
> the document.
> 
> 
> Michael Mandelberg
> FirstWave Intelligent Optical Networks, Inc.
> 11800 Sunrise Valley Drive, 15th floor
> Reston, Virginia 20191
> (703) 390 - 9401, x 1008
> mmandelberg@fwion.com
> 
> 
> 
> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: Tuesday, September 10, 2002 4:52 AM
> To: ccamp@ops.ietf.org
> Subject: G.RSVP-TE in OTN - Refresh mechanism
> 
> 
> Hi all,
>               some time ago there was an argument, on the ML (see
> http://ops.ietf.org/lists/ccamp/ccamp.2001/msg00374.html) 
> about whether it
> was feasible to retain the possibilty to set the refresh 
> timer to infinite,
> a proposed alternative was to ignore the elapsing of the 
> refresh timer.
> 
> I feel these capacities are very useful especially in a 
> Transport Network
> enviroment.
> 
> What is the consensus on the possibility to eliminate the 
> need of refresh
> message in G.RSVP-TE?
> 
> Best Regards,
>                              Diego.
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> Diego Caviglia
> Optical Network - ASON strategy
> E-mail: diego.caviglia@marconi.com
> Tel: +39 0 10 6003 808
> Via A. Negrone 1A 16153 Genoa (Italy)
> ----------------------------------------------------------------
> Fatti non foste a viver come bruti
> ma per seguir virtute e canoscenza
> 
> Dante Alighieri Inferno Canto XXVI
> 
> 
> 
> 
>