The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00351



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

New Internet Draft on ERO

  • From: Bora Akyol <akyol@pluris.com>
  • Date: Tue, 27 Feb 2001 11:56:17 -0800
  • Cc: Bora Akyol <akyol@pluris.com>, mpls@UU.NET

At 11:36 AM -0800 2/27/01, Yakov Rekhter wrote:
>Bora,
>
>>  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.
>
>Could you tell us how the head-end LSR would be able to figure out
>the "correct adjacency" in the scenario you described above.

Yes

By consulting the IGP TE database (TED).

>  >	b) Specifying both ingress and egress is more explicit and
>>  leaves no guesswork.
>>
>>  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.
>
>We aren't arguing over 4 more bytes - the issue is whether
>it is truly necessary. And so far you've yet to construct a
>case that shows that it is necessary.


1.It clearly associates an unnumbered interface with a router thereby 
guaranteeing uniqueness.

2. You don't need to infer anything from the order of the objects in 
the ERO, the association of an unnumbered interface to a router is 
clear.

3. It makes ERO processing code much simpler as it removes all of the 
Abstract Node case (and its associated lookups) from the common path.

4. I believe it improves the chance of both fast reroute and MPLS 
interoperating.

We wrote this draft because we had to make certain decisions and 
assumptions while developing our own RSVP-TE implementations about 
the ERO. We think that the idea of clearly specifying the 
router/interface identifiers and the association between them makes 
the implementation (and hence the network) more robust.


Also see the email that Vach Kompella (one of the co-authors) send to 
the MPLS mailing list for more reasons.


Bora