Subject: [mpls] MPLS LSP Discovery

From: János Csatári <[email-masked]>
Date: Fri, 20 May 2011 12:00:15 +0200

Dear Authors!

I am newbie to this mailing list and I hope that I ask my question in
an appropriate place. If this is not that place, then please take my
apologies and ignore this message.

I am János Csatári, a student at the University of Szeged in Hungary,
and I work as Network Engineer here, too. Lately, we discovered a very
interesting problem in our project, and since it is very close to MPLS
(well, it IS fully MPLS :) ) I humbly decided to ask for your help. I
applied a lot of ideas from the MPLS Network Management - MIBs, Tools,
and Techniques book (which helped me a lot during the research),
especially the MPLS-LSR and MPLS-TE MIB fields, and I have a little
"problem" in those particular field.

My job is to create a Java plug-in for the Géant3 network to provide
an MPLS-Tunnel discovery method. I studied the MPLS-TE and MPLS-LSR
RFCs, and created a layered domain model for the project. The idea was
to utilize the MPLS-TE for Tunnel discovery (this is ready and works
fine), but we wanted to get an insight to the very basics of the MPLS
mechanism. Then I started to study the MPLS-LSR MIB to acquire data
which can "help" to understand the topology or the tunnels.

I used a lot of things from that chapter in that book, I connected the
appropriate MIB tables and created the LabelToLabel rules according to
the acquired information. However, I discovered a very interesting
thing, or maybe the purpose why I am inspecting this MIB (tunnel
discovery) is inappropriate. I humbly ask for you help in that
question.

I created a document with example cases, diagrams and tables, which is
attached (http://cid-35a88678eaeb8048.office.live.com/view.aspx/Nyilv%c3%a1nos/Observations%20of%20the%20MPLS.docx).
Long story short: Is this layer useless to provide the topology of the
Tunnels, or its only purpose is to provide full connectivity in the
domain? Because I figured out, that for every entry in the OSPF
routing table there is an LSP made to that network(host) from every
other router, that does not have direct connection to that.

Yours sincerely,
János Csatári

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 20 May 2011 07:50:55 -0400

Hi,

> "problem" in those particular field.

	Don't waste your time with that book. *)

> other router, that does not have direct connection to that.

	I'd suggest taking a different approach. Rather than discovering the LSPs via the LSR-MIB and then mapping each one "upwards" to the applications like TE, L2VPN, L3VPN, PWs, etc.... I would recommend you start at the applications and work your way down. The reason is two-fold. Firstly, the set relationship is a (very) many-to-one in terms of LSPs -> applications. That means that if you are doing root-cause-analysis based in some alarm, and start at the LSPs to find the affected VPNs, you are going to be spending a lot of wasted time rifling through the LSPs that are irrelevant. The other thing is that in general, most LSPs are put there based on IP routes and so their persistence can be relatively low. So for example, they might change after you have discovered them, making your correlation inaccurate.

	The other thing you must realize about the LSPs in the MPLS network is that there are generally no "connections" per se; they are generally connection-less "paths" that come and go as routing changes.  There are of course connection-oriented paths (i.e.: RSVP-TE paths for example), but they are relatively few compared to the rest (generally speaking).

	I hope that helps. If not, feel free to contact me.

	--Tom

> 
> Yours sincerely,
> János Csatári
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>