The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

At 2:45 PM -0500 2/27/01, Bala Rajagopalan wrote:
>Hello,
>
>>
>>
>>  1. You need to specify both ingress and egress identifiers
>>  for two reasons:
>>	a) On broadcast media (think GigE, 10 GigE) when a router has
>>  multiple interfaces attached to the same switch, you want the RSVP
>>  packet and MPLS LSPs to use the correct adjacency. And the only way
>>  to get that is to specify a pair. This scenario is commonly used in
>>  POP architectures where there are two GigE switches in the middle and
>>  each router has one link to each GigE switch and the GigE switches
>>  are interconnected.
>
>What is the meaning of "correct adjacency" here? Specifically,
>is there any reason for distinguishing between such adjacencies
>ariori at the source? (Or, is there any reason why this
>sort of decision cannot be left as a local
>matter to previous hop node?)

You have two routers that are connected to an ethernet switch via 
multiple interfaces on each side. The head end LSR has calculated an 
explicitly routed path that is strict.

For one to be able to specify a strict path in a LAN environment you 
need to be able to specify both ingress and egress interfaces. This 
is a matter of correctness, IMHO.

Now does this matter? Based on the POP architectures that I have 
seen, this is a case that occurs for redundancy reasons fairly often, 
so the correctness does matter.

Even though the broadcast media is shared, the packet treatment 
mechanisms are not shared and you need to be able to deliver 
deterministic service.

>  >
>>  2. I just asked a simple question with respect to fast reroute: How
>>  do you do it when you have unnumbered interfaces. At first thought, I
>>  thought it would be very hard to do, after thinking about it for a
>>  few minutes I think if you make certain assumptions and make
>>  extensive use of the IGP-TE database, you can possibly get by. But
>>  why? Why are we arguing over 4 more bytes in the signaling message.
>>  We don't have 56K leased line links any more. OC192c has become the
>>  standard and 768c is right around the corner. I don't see any point
>>  it haggling on four bytes. Hence we defined the EERO.
>
>Actually, I'm just trying to understand the motivation and problem w.r.t
>reroute. It would really help if you can describe the
>problem in some detail.


Think of an unnumbered ERO of the form <1,1,1,1,1,1,1,1>

Now somewhere in the middle, an LSR wants to calculate a fast reroute 
LSP. Normally, one would ask the TE database the simple question of 
avoid my next hop and would give the router ID of the next hop, but 
in this case, first you have to find out who the router at the end of 
the egress interface is. This is not hard, then you need to find out 
who the router that is right after the immediate hop. This second one 
is harder since you have to make a query into the TE database, to 
find that. Then you have to make a third query into TED, to calculate 
an LSP that avoids the immediate next hop but merges as soon as 
possible with the main LSP. And finally, you calculate an ERO that 
now is a mixture of both numbered and unnumbered interfaces possibly 
and initiate signaling. As I describe here, this is not undoable, but 
at what cost.

If one adds the extra four bytes of router ID as part of the ERO (as 
we did in the EERO) this whole thing becomes trivial to implement.

I am advocate for putting enough bits on the wire to make 
implementation simpler.


Bora