Subject: RE: LSP in transit LSR MIBs

From: "Leonid Dubinsky" <[email-masked]>
Date: Tue, 3 Jul 2001 11:46:07 +0300

Tom,
I'm not sure I explained it right.
Consider LSR B which is transit node for an LSP, it has to RRO vectors:
one describing path from ingress to B (from PATH message) and other RRO
for path from egress to B. As far as I understand, mplsTunnelTable does
not contain two pointers into ARHopTable to store this information. So
how should these two RRO lists be stored? The same concern can be
applied to TSpec as compared to Flowspec.
Best Regards,
    Leonid Dubinsky.

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Monday, July 02, 2001 4:03 PM
To: Leonid Dubinsky; [email-masked]
Subject: RE: LSP in transit LSR MIBs

At 05:35 PM 7/1/2001 +0300, Leonid Dubinsky wrote:
>Hello Tom,
>Thanks for your response.
>That's clear you'll have to store cross-connects to mantain the LSP
>itself.
>Storing LSP information in the TE MIB is possibly the most logical
>possibility, but still there are things which should be split in
>transit, and the MIB does not support such splitting (e.g., it would be
>nice to divide RRO to "upstream" and "downstream" parts, show both
>"requested traffic parameters" from RSVP-TE PATH and "allocated
>parameters" from RSVP-TE RESV, etc.)
>What do you think is the most logical placement of this stuff in the
LSR
>MIB tables?

         RRO/ERO separation on a per-tunnel basis is already
done in the MPLS-TE-MIB. Take a look at the different
HOP tables in the MPLS-TE-MIB. RRO/ERO is not used for
non-TE LSPs (i.e.: they are set up using LDP), so it is
not available in the LSR MIB.

         --Tom

>Best Regards,
>     Leonid Dubinsky.
>
>-----Original Message-----
>From: Thomas D. Nadeau [mailto:[email-masked]]
>Sent: Sunday, July 01, 2001 4:56 PM
>To: Leonid Dubinsky; [email-masked]
>Subject: Re: LSP in transit LSR MIBs
>
>
>
>          Transit LSPs should be stored in the LSR-MIB as
>Insegment(s)-XC-Outsegment(s) entries. Thus, if you
>start at the ingress, you can follow the LSP
>across the network to the egress. If the
>transit LSP is used to carry traffic for a particular
>TE tunnel, then the MPLS-TE-MIB *may* contain that
>information at transit LSRs. This is not mandatory,
>but most implementations I know of are doing it since
>the information is available (via RRO/ERO).
>
>          --Tom
>
> >I've read the drafts LSR MIB and TE-MIB, but I was unable to figure
out
> >from them where transit LSR should store information about LSPs
passing
> >through it. Should it be placed in mplsTunnelTable?
> >Anyone has any thoughts on this?
> >Best Regards,
> >     Leonid Dubinsky.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 03 Jul 2001 09:03:53 -0400

>for path from egress to B.

         How would these be two different RROs? The LSP should only
have one RRO for the currently signaled path. I think that
you are confused about how the LSPs are signaled. A single
ERO is sent in the forward direction, and a single RRO is
returned in the reverse direction.

>As far as I understand, mplsTunnelTable does
>not contain two pointers into ARHopTable to store this information.

         Right, the currently signaled RRO is contained in
the table. In your example, which looks like the following

         A ... B ... C
         tunnelA -------->

the RRO table at B for tunnelA from A-C would
contain an entry in the RRO table that was A,B,C.
It can form this by using the ERO in the forward
direction, and the RRO in the reverse direction
to construct the entire path taken by the tunnel.

         --Tom

>So how should these two RRO lists be stored? The same concern can be

---

From: Jack Brennen <[email-masked]>
Date: Tue, 03 Jul 2001 09:45:37 -0400

> returned in the reverse direction.

I think that Leonid was referring to the same thing as this
paragraph from 4.4.3 of the RSVP-TE draft:

  "Note that each node along the path will now have the complete route
   from source to destination.  The Path RRO will have the route from
   the source to this node; the Resv RRO will have the route from this
   node to the destination.  This is useful for network management."

Thus a transit node has two completely independent RROs; by combining
the two RROs, one complete route from ingress to egress is given.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 03 Jul 2001 10:27:20 -0400

>the two RROs, one complete route from ingress to egress is given.

         Sorry, that is what I meant. The Path RRO + the Resv RRO == the
RRO from my last discussion.  Anyway, the point was that they are
viewed as one in the same thing in the MPLS TE MIB; the actual
path. The computed and specified paths are also available, but
at the head-end only.

         --Tom