Subject: Queries regarding LMP.

From: rajesh <[email-masked]>
Date: Wed, 25 Jul 2001 11:28:33 +0530

Hi,

     Have a few queries regd LMP.

Q1)  Regd the applicability of LMP...

draft-many-gmpls-architecture-00.txt states that

"   For instance, the traditional IP routing model assumes the
   establishment of a routing adjacency over each link connecting two
   adjacent nodes. Having such a large number of adjacencies is not
   scalable at all. Each node needs to maintain each of its adjacencies
   one by one, and link state routing information must be flooded in
   the topology for each link.

   To solve this issue the concept of bundling was introduced.
   Moreover, the manual configuration and control of these links, even
   if they are unnumbered, becomes totally impractical. The Link
   Management Protocol (LMP) was specified to solve these problems. "

a) Can one assume that LMP makes sense ONLY in the case of a large
     number of parallel links and link bundling...

      and an implementation of GMPLS neednot have LMP if no link
      bundling is used ??

      The above maybe the case when using lower end SONET ADM,
       DXCs...

b) Under what other conditions would one require LMP (ie other than
      link bundling) ?

Q2) Suppose one does NOT need to use LMP but then one needs to use
         OSPF extensions to support TE
(draft-kompella-ospf-gmpls-extensions-01.txt) ,

        then one may need to do a  correlation of Link Ids between 2
TE nodes.

       a) Is there a standard recommended way to do this correlation ??

             E.g OSPF - Link Local Signaling
                    or OSPF - link scope LSA ?

Q3) Section 9 of draft-ietf-mpls-lmp-02.txt   says that LMP messages
         are encoded as IP packets and also suggests protocol number
140.

          What would be the destination IP address of an LMP packet ??

           A multicast or is it got from an IGP ??

Q4) In LMP, if a Link Id correlation has been done,  and If the link ids

         on one of the ends or both change... How is this change taken
into
         account ??

         Eg for i = 1,2
                          Port i, Node 1 connected to Port i, Node 2

          If one interchanges the connection then one has to recorrelate

           the Link Id mappings..

Thanks in advance,
Rajesh

---

From: Jonathan Lang <[email-masked]>
Date: Wed, 25 Jul 2001 10:17:02 -0700

Following up on Martin's comments...

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 8:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Queries regarding LMP.
> 
> 
> Q1) a) & b) LMP is useful for auto-discovery of links and monitoring of
> control and data link health. To determine whether LMP is useful or not,
> one has to look at the operational aspect of product deployment and
> maintenance, i.e. what tools the vendor wants to implement to facilitate
> provisioning and maintenance of their customers network. In a small
> network, a vendor may be able to get away with manual configuration of
> links. In an opaque network, it is also easy to pinpoint link failures.
> However, in a truly optical network, there needs to be mechanisms to
> isolate faults (which LMP provides).
> 
> Usefulness of LMP is not directly tied to use of link bundles. Link
> bundles are mostly used to reduce the flooding of link information
> generated by the routing protocol.
To add further, when GMPLS labels map to physical resources (i.e., ports or
fibers), LMP can be used to exchange these labels so that there is a common
understanding of the mapping.  Even if man ual configuration is used, LMP
provides a mechanism to verify the accuracy (it is not uncommon for manual
configuration to be in error...).

> 
> Q3) Destination address can be multicast or any valid IP address of
> destination node (most likely the NodeID of the destination node).
Note that the protocol Id suggestion of 140 has been removed in the latest
version as this value MUST be assigned by IANA.  140 has been used in
interops for the time being, but this shouldn't be considered as the final
protocol id.

Q4) Recorrelation of Link Ids can be done by reverifying the link and/or
resending the LinkSummary message.

Thanks,
Jonathan 

> 
> -----Original Message-----
> From: rajesh [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 1:59 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Queries regarding LMP.
> 
> 
> Hi,
>

---

From: Bala Rajagopalan <[email-masked]>
Date: Wed, 25 Jul 2001 14:54:29 -0400

Hello,

> From: Lyndon Ong [mailto:[email-masked]]
> Hi,
> 
>> By the same token, is there really a need for fast keep-alive 
> for all situations, esp. for in-band DCC control channels 
> where there is a link layer protocol in use that can monitor 
> control link health?  Keep-alive is just further overhead in 
> that situation, especially when there may be hellos in the 
> signaling and routing protocols going on at the same time.

For in-band DCC, the SONET/SDH procedures can help in
detecting link down situation. However, a keep-alive also tells
if the neighbor discovery process running is up or down. Perhaps
 the neighbor discovery Hello messages can be sent over a 
coarser time period. W.r.t routing
protocols, the idea is not to create an IGP adjacency over
each link (and hence no IGP hello over each link).

Regards,

Bala

---

From: "Lyndon Ong" <[email-masked]>
Date: Wed, 25 Jul 2001 11:36:49 -0700

Hi,

I thought that this was why the fault localization piece of LMP was made negotiable, since it was not necessary to support this in opaque networks.

By the same token, is there really a need for fast keep-alive for all situations, esp. for in-band DCC control channels where there is a link layer protocol in use that can monitor control link health?  Keep-alive is just further overhead in that situation, especially when there may be hellos in the signaling and routing protocols going on at the same time.

Cheers,

Lyndon

--

On Wed, 25 Jul 2001 12:34:38   Zhi-Wei Lin wrote:
>Hi Martin, comments in-line
>
>
>Martin Dubuc wrote:
>> 
>When you say "truly optical network", do you mean a network that has no
>O/E/O (no 3R) at all? or is there some 3R at the edge?
>
>As for mechanisms to isolate faults, I think this capability is already
>part of networks. For example, SONET has mechanisms such as trace
>identifiers, AIS/RDI signals, and tandem connection points for doing
>this. OTN (G.709) also has these defined. In addition, OTN has defined 6
>flexible layers for TCM and 2 fixed layer for TCM (section and path). 
>
>I think LMP is not necessary for fault isolation, but it could be
>another mechanism that may be used (if one so chooses). 
>
>> 

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com