The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-Nov> msg00069



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: LSP hierarchy reflected in MIBs

  • From: Roberto.Guglielmi@alcatel.it
  • Date: Mon, 25 Nov 2002 09:03:34 +0100
  • CC: mpls-ops@mplsrc.com
  • Resent-Date: Mon, 25 Nov 2002 04:41:56 -0500
  • To: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
  • X-MIMETrack: Itemize by SMTP Server on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at11/25/2002 09:12:57,Serialize by Router on ITMAIL02/IT/ALCATEL(Release 5.0.8 |June 18, 2001) at11/25/2002 09:13:09,Serialize complete at 11/25/2002 09:13:09



Thomas D. Nadeau wrote:

> At 04:22 PM 11/21/2002 +0100, Roberto.Guglielmi@alcatel.it wrote:
>
>> Hello everyone,
>>
>> the draft-ietf-mpls-lsp-hierarchy-08.txt describes how to set up two 
>> different LSP to create a hierarchy of such LSPs. The document states:
>> "2. Abstract
>>   .....A way to create such a hierarchy
>>   is by (a) a Label Switching Router (LSR) creating a Traffic
>>   Engineering Label Switched Path (TE LSP), (b) the LSR forming a
>>   forwarding adjacency (FA) out of that LSP (by advertising this LSP as
>>   a Traffic Engineering (TE) link into the same instance of ISIS/OSPF
>>   as the one that was used to create the LSP), (c) allowing other LSRs
>>   to use FAs for their path computation, and (d) nesting of LSPs
>>   originated by other LSRs into that LSP (by using the label stack
>>   construct)....."
>>
>> What is not clear to me is how this LSP hierarchy is reflected inside 
>> the MIBs.
>> Suppose I want to set up two nested LSPs beginning both at the 
>> ingress node
>> for example to transport ETS flows within an MPLS domain.
>> The Ingress node should push two labels on L2 packets.
>> I have the following questions:
>>
>> 1)    Is the LSR MIB sufficient? Or is the TE MIB necessary?
>>       From my point of view the LSR is sufficient: the 
>> mplsOutSegmentTable contains the top label,
>>       while the mplsLabelStackTable contains the bottom label.
>
>
>         I think that all that you would see is a bunch of LSPs that
> might all use the same outgoing label (with perhaps a different label
> stack).
>
>> 2)    When the Ingress node receives the Resv message of the inner 
>> LSP, how are the MIBs populated,
>>       with what information and how the two nested LSPs are matched?
>>
>> 3)    What information is used to refer to the entry inside the MIB 
>> relating to the outer LSP?
>
>
>         The LSR MIB treats all LSPs the same way.
>
>         --Tom


Thanks Tom,
what it's not clear to me is how the node receiving the Resv message 
decides whether to create a new entry in the LSR MIB or to integrate the 
information of an existing entry with a an entry in the 
mplsLabelStackTable. My doubt arises from the fact that the received 
Resv message is always the same both in case of an LSP that has to be 
tunnelled in another LSP and in case of an LSP that is not suppoesed to 
be tunnelled.

Regards Roberto

>
>
>> Thanks a lot for spending your valuable time to fill my lacks.
>> Regards, Roberto
>>
>>
>> -------
>> The MPLS-OPS Mailing List
>> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>
> Success is relative; the more success, the more relatives. -Anonymous
>
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml