[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
Hello Ravi,
Thanks for your email.
I guess I can agree that Control Channel Management can be a 'light weight'
protocol. But wouldn't it then make sense to make Control Channel Management
optional ? Maybe some products want to use a standard routing protocol like
OSPF, RIP, I-ISIS etc.
On the 'faster' part of Control Channel Management: why does it need to be
fast (assuming it is indeed faster, which can be questioned) ?
My feeling is that the only answer you can give is 'for fault management'.
Correct ?
However, fault management is an optional procedure in LMP. It does not make
sense to me to make something mandatory that is only useful for something
that is optional.
Declaring fault management optional makes sense in my mind because a lot
of products don't need LMP's fault management. They can do with SONET/SDH
in-band 'RDI/REI' (Remote Defect Indication/Remote Error Indication)
or with OTN in-band 'BDI/BEI' (Backward Defect Indication/Backward Error
indication).
Best regards,
Michiel
> Ravi Ravindran wrote:
>
> michiel,
> i don't think i could really respond to your query's relating to SONET/SDH. Coming to the usage of control channel management, its only that one could leverage on the faster light weighted hellos of LMP which is order msec, compared to sec's in normal routing protocol, for faster recovery of
> control channel failures.
>
> Ravi S. Ravindran
> Nortel Networks, Ottawa
>
> -----Original Message-----
> From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> Sent: Monday, April 15, 2002 10:54 AM
> To: Ravindran, Ravi [CAR:0V13:EXCH]
> Cc: 'Manoj Sontakke'; Jonathan Lang; ccamp@ops.ietf.org
> Subject: Re: Question on LMP.
>
> Hello Ravi, Manoj,
>
> > This is reiterating manoj's question, do we need some kind of association
> > between the routing protocol and the LMP which is supposed to provide a
> > reliable control channel for the control plane protocols.
>
> 1. Do you also set up a control channel between neighbors switching at VC-12 /
> VT-1.5 level ? In this case there is no DCC channel between the neighbors.
>
> 2. Do you also set up a control channel between neighbors in case there is
> a transparent cross connect in between that does not implement LMP/GMPLS ?
> I.e. the data link is actually a 'serial compound link'.
>
> Example of my second point, assume e.g. datalink is VC-4:
> +------+ +------+ +------+ +------+
> | T-|--->--|-C--C-|--->--|-C C-|--->--|-T |
> | | A | | B | | C | |
> | | | | | | | |
> | NE-1 | | NE-2 | | NE-3 | | NE-4 |
> +------+ +------+ +------+ +------+
>
> NE-2 does not implement LMP nor GMPLS. It simply is a fixed through-cross-
> connect for this data link. In this case, I'm assuming NE-1 and NE-3 need to be
> considered as switching neighbors that switch under GMPLS control.
>
> > If we do not have
> > this, during a control channel failure (assuming a case where we have
> > multiple active control channels and physical interfaces between two
> > nodes), the control plane protocols would have to rely on the routing
> > protocol to detect the failure and reroute the packets, making the control
> > channel management of LMP less efficient.
>
> *If* we need for some reason a control channel between switching neighbors,
> why don't we use an LSP to implement this control channel ? Why inventing
> again a new mechanism ?
>
> But stepping back a bit, why do we need a 'reliable control channel' at
> all ? Why are normal routing protocols not sufficient ?
>
> Thanks,
>
> Michiel
>
> --
> +------------------------------------------------------------------+
> | Michiel van Everdingen |
> | Systems Engineer |
> | Lucent Technologies - Optical Networking Group |
> | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 |
> | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 |
> | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com |
> +------------------------------------------------------------------+