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

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

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