The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Jun> msg00197



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

Address Message in LDP

  • From: "Santosh Gupta" <santoshg@daewoo.dti.daewoo.co.kr>
  • Date: Thu, 8 Jun 2000 17:29:21 +0530
  • Cc: <mpls@UU.NET>
  • Organization: Daewoo Telecom

Jim,

> On Wed, Jun 07, 2000 at 12:30:54PM -0700, Eric Gray wrote:
>
> <snip>
>
> > Of course it is not the only way.  For one thing,
> > it is possible to configure this information.
> >
> > (Bob does not have my warped sense of humor - if
> > he meant "required" he would not have said "useful")
> >
> > > My goal is to get an answer about "non-Directly Connected
> > > LSRs" and how they guarantee that they are distributing
> > > labels and installing them on the correct interfaces.
> > >
> > > The way to get the above answer may involve or mimic the way
> > > we deal with mappings over parallel links between two
> > > directly connected LDP peers.
> >
> > There are numerous issues with this.  One of them is
> > the assumption of multiple parallel links between two
> > LDP peers - which necessarily implies the use of the
> > platform wide label space (as Shahram points out).
>
> Even though the downstream sessions uses a plateform wide label space that
> STILL doesn't solve the problem when one of the upstream session receives
a
> mapping.  The upstream needs to decide if the downstream session that it
> received the label from is running over the link that corresponds to the
TRUE
> next hop.

If the TRUE next hop is one of the 2 interfaces, then it should be the TRUE
one. But in case if it is not one of the 2 interfaces which are not directly
connected then you can choose any one of the 2 and it will work. You install
the
Incoming interface/label ---------> Outgoing Interface/Label
into the switch. Once data starts coming, it doesnt matter if it goes to the
peer on link1 or link 2 if you have seperate LDP sessions on both, though
one of the paths might be less costly.

santosh
>
> Jim
> --
> James R. Leu
>