The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Aug> msg00150



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

generalized MPLS signaling question

  • From: Kireeti Kompella <kireeti@juniper.net>
  • Date: Wed, 16 Aug 2000 11:07:08 -0700 (PDT)
  • Cc: akullber@netplane.com, mpls@UU.NET

Hi Eric,

> 	I'm afraid that this doesn't help, too much,
> in understanding how this might be done.  For one
> thing, if the interface ID sub-object type you've
> defined in the unnumbered draft (I am assuming you
> refer to draft-kompella-mpls-unnum-00) is intended
> to be used to identify LSPs, then it should maybe
> have been defined as a larger than 16-bit field.

Yes, that's the draft.  If you really think that 65536 is
too small, it's easy enough to make this a 24-bit number.

> 	For another, there's an issue with how an LSR
> might interpret an IPv4 prefix in an ERO when there
> are multiple routes to that prefix - including one
> or more that traverse an LSP.  In fact, there is 
> nothing to prevent having more than one LSP at any
> LSR that extends toward an IPv4 prefix, is there?   

That applies as is to interfaces.  One could have several
interfaces and/or LSPs identically numbered between two
routers.  The fact that they are identically numbered means
you don't care which one is used.  With in-band signalling,
there is no issue; with out-of-band signalling, you'd need
to bundle the links, and use the Link ID so both ends agree
on which link to use.

> 	So, I guess the question comes down to "is there
> a reason why a user might want to force the path to
> follow a particular LSP even when routing would prefer
> a different path?"  I think the answer is yes.

I agree completely that choosing a path is necessary.
a) Number the interfaces and LSPs distinctly; or
b) Run unnumbered
to force the path the way you choose.  Or

c) Bundle the interfaces and LSPs, and use the Link ID
to make both ends use consistent links.

These approaches work for both interfaces and LSPs.  A
session ID mechanism only works for LSPs; also, it isn't
enough to extend RSVP EROs to include session IDs, you also
need to carry the session ID in the IGP to be able to compute
the paths you want to force (options a and b).

Question: what does a session ID offer that can't be done
with an "interface index"?

Kireeti.