The MPLS WG Archive

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

At 11:51 AM 4/17/2003 +0200, riza.cetin@alcatel.be wrote:


>"Thomas D. Nadeau" wrote:
>
> > At 09:38 AM 4/16/2003 +0200, riza.cetin@alcatel.be wrote:
> >
> > >"Thomas D. Nadeau" wrote:
> > >
> > > > >5. How can we represent label-stacking in LDP via this MIB. The
> > > > >label-stacking could be either
> > > > >- LDP LSPs over RSVP-TE tunnels.
> > > > >- PWE-LDP (Martini) LSPs over core LDP/RSVP - LSPs.
> > > > >
> > > > >Suggestion - Each core LSP (LDP/RSVP) can be represented by an 
> if-index
> > > > >in the IF-MIB. If we include the if-index in the above tables then we
> > > > >can find out whether the LSP goes via a physical-interface or a
> > > > >'tunnel-interface'.
> > > >
> > > >          I don't understand how assigning an IfIndex to an LSP is 
> going to
> > > > work.  This sounds like something that is implementation-specific.
> > >
> > >MPLS-TE MIB (draft-ietf-mpls-te-mib-09.txt) allows for defining an 
> MPLS tunnel
> > >as an interface.
> > >mplsTunnelIsIf object is set to true(1) for tunnels to be used as 
> interface
> > >and an entry is created in the ifTable with the ifIndex of the tunnel.
> > >
> > >Below is the text from the MPLS-TE-MIB.
> > >
> > >mplsTunnelEntry OBJECT-TYPE
> > >    SYNTAX        MplsTunnelEntry
> > >    MAX-ACCESS    not-accessible
> > >    STATUS        current
> > >    DESCRIPTION
> > >         "An entry in this table represents an MPLS tunnel.
> > >           An entry can be created by a network administrator
> > >           or by an SNMP agent as instructed by an MPLS
> > >           signalling protocol. Whenever a new entry is
> > >           created with mplsTunnelIsIf set to true(1), then a
> > >           corresponding entry is created in ifTable as well
> > >           (see RFC 2863). The ifType of this entry is
> > >           mplsTunnel(150)."
> > >
> > > >
> > > > The label stack is represented either in the LSR MIB as it is
> > > > defined today.  If you want to see the application-specific label,
> > > > then look in the PWE3 MIBs as a short-hand. The PPVPN-MPLS-VPN MIB is
> > > > also going to be modified to show the VPN label as well.  However,
> > > > in either case, the ingress labels should be available in the LSR MIB
> > > > as a point of reference.
> > > >
> > >
> > >How would you represent the tunneling LDP into RSVP-TE at the ingress 
> LSR of
> > >the RSVP-TE tunnel?
> >
> >          You would show the LSP in the LSR MIB being switched to
> > the TE label.
> >
> > >Where would you store the labels (LDP label and RSVP label) that need 
> to be
> > >pushed? In the label stack table of the LSR-MIB or higher layer.
> >
> >          In the LSR MIB's XC table.  The question above asked how to do 
> LDP/TE.
> > The forwarding/label stacking is different from the interface stacking
> > used to accomplish this. The ifStack looks like:
> >
> >          Outgoing Interface:
> >
> >          TE
> >          MPLS
> >          underlying layer (enet for instance)
> >
> >          Incoming Interface:
> >          MPLS
> >          underlying layer (enet)
> >
> >          The cross-connection on a switch to do this might be:
> >
> >          Incoming LDP label, incoming interface -> NULL outgoing label
> >
> >          NULL incoming label -> outgoing TE tunnel label, outgoing TE 
> interface
> >                  XC defines a push with the incoming LDP label in the
> >                  label stack table.
> >
>
>In this case, mplsLdpDownLabel object (defined in the mplsLdpDownLabelTable of
>Neil's proposal) will be LDP label (inner label) while
>mplsLdpDownLsrOutSegmentPointer object (of the same mplsLdpDownLabelTable 
>entry)
>points to an out-segment entry configured with the REVP-TE label. Would it 
>not be
>confusing?

         That is how it works; the outgoing label is owned by the TE 
application.

         --tom




> >          So the resulting outgoing label stack would be LDP label/TE label.
> > However, that would go out of the TE interface/MPLS interface.
> >
> >          --tom
> >
> > >Regards, Riza.
> > >
> > > >
> > > >          --Tom
> > > >
> > > > 
> http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X
> >
> > http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X


http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X