The MPLS-OPS Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 09:03 AM 11/25/2002 +0100, Roberto.Guglielmi@alcatel.it wrote:


>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.

         So how do you know what to do?

         --Tom


>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
>

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