Subject: RE: New Internet Draft on ERO

From: Bala Rajagopalan <[email-masked]>
Date: Tue, 27 Feb 2001 09:24:56 -0500

Hi,

This is all rather mysterious. Following up
on Jonathan Lang's and Yakov's earlier questions,
could you please describe what the problem is
w.r.t fast reroute?

Also, in your draft, what's the need to specify
both ingress and egress interface identifiers
for EERO hops? isn't one of them enough?

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 6:49 PM
> To: Yakov Rekhter
> Cc: Bora Akyol; [email-masked]
> Subject: Re: New Internet Draft on ERO
> 
> 
> At 3:14 PM -0800 2/26/01, Yakov Rekhter wrote:
> >Bora,
> >
> >>  My question is as follows:
> >>
> >>  How do you do fast reroute when you have unnumbered 
> interfaces in the
> >>  ERO as in the unnumbered draft? What out of band 
> information is added
> >>  to what's in the ERO when we do CSPF? Is everyone doing 
> it the same
> >>  way?
> >>
> >>  If we use the (newly defined) EERO then fast reroute is 
> the same for
> >>  both numbered and unnumbered interfaces and it actually 
> becomes quite
> >>  easy.
> >
> >Could you point me to the MPLS WG document(s) that specifies
> >how to perform fast re-route ?
> >
> >Yakov.
> 
> Well, there was the ID from George Swallow that we discussed in San 
> Diego. And then there were some discussions on the list that I 
> participated in 1998. Vishal Sharma et al, produced IDs on that 
> subject as well.
> 
> 
> Maybe it is time that we write a BCP on that topic. Would this fall 
> into CCAMP or MPLS? In the last IETF, **all** of the fast 
> reroute/recovery schemes were sent to CCAMP AFAIK.
> 
> I know how we implemented fast reroute and I am sure you know of at 
> least two implementations.
> 
> So if there is interest on the WG, I can volunteer to put together a 
> group of people to write such a BCP.
> 
> But my original question still stands,
> 
> how do you do fast reroute when you have unnumbered interfaces? It is 
> possible to do, but becomes much easier if you have the router ID as 
> part of the ERO subobject as we did in our EERO specification. Please 
> see draft-akyol-mpls-exp-ero-00.txt
> 
> 
> Regards
> 
> Bora
>

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Feb 2001 09:18:31 -0800

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.

	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.

I hope I cleared the "mystery" for you and Jonathan ;-)

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Feb 2001 11:36:56 -0800

Bora,

> each router has one link to each GigE switch and the GigE switches 

Could you tell us how the head-end LSR would be able to figure out
the "correct adjacency" in the scenario you described above.

> 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.

Yakov.

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Feb 2001 11:56:17 -0800

>the "correct adjacency" in the scenario you described above.

Yes

By consulting the IGP TE database (TED).

>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