Subject: Regarding draft-ietf-ospf-5to7-01.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Sun, 22 Sep 2002 05:23:35 -0400

Hi Pat,

Two small comments: -

a) Shouldn't the translator now set the E-bit in its router LSA into the
NSSA area because according to step 3 Section 3.5 of the NSSA draft none of
the translated NSSA LSA's would be considered for the routing table
calculation and the entire purpose of 5to7 would be defeated.

I couldn't find the fact stated in the draft. Or did I miss it?

b)  Regarding the translator election for the elected translator, we could
as well just have the guy with the lowest router-id become translator this
can be done without actually adding any change to packets and can be done as
part of the 7to5 translator election.

Thanks,
Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sun, 22 Sep 2002 06:49:57 -0400

Regarding a) I guess we already do it for NSSA anyway setting the E-bit, so
it would already be done for the type5to7 already, so the issue would not
hold.

Thanks,
Vishwas

-----Original Message-----
From: Manral, Vishwas [mailto:[email-masked]]
Sent: Sunday, September 22, 2002 2:54 PM
To: [email-masked]
Subject: Regarding draft-ietf-ospf-5to7-01.txt

Hi Pat,

Two small comments: -

Thanks,
Vishwas

---

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Tue, 24 Sep 2002 08:40:45 -0700

Vishwas,

>a) Shouldn't the translator now set the E-bit in its router LSA
>into the NSSA area because according to step 3 Section 3.5 of the
>NSSA draft none of the translated NSSA LSA's would be considered
>for the routing table calculation and the entire purpose of 5to7
>would be defeated.

Yes the E-bit should be set. Fortunately, since the translator is
one of the NSSA's ABRs, it will have a routing table entry. It just
won't have one that reflects its ASBR status, which it should. I
will check the draft and make the change.

>b)  Regarding the translator election for the elected translator,
>we could as well just have the guy with the lowest router-id become
>translator this can be done without actually adding any change to
>packets and can be done as part of the 7to5 translator election.

The NSSA Translator election algorithm in the current draft is
somewhat subtle. When I wrote the 5to7 draft I surmised that the
performance criteria used to configure one NSSA ABR as a 7to5
translator over another NSSA ABR would also apply to picking
the same NSSA ABR as the 5to7 translator. The RFC 1587 NSSA
translator was simply chosen as the one with the highest router ID.
The current NSSA draft documents that translators should be chosen
based on performance requirements, not router ID. That is why it
makes them configurable. Other than splitting the translator
processing load, I can't see any performance benefit to picking the
default 5to7 translator as the one with the lowest router-id.
Furthermore, I think it is best if the network implementor can
simply rely on the highest router ID being the translator in both
cases. If he has multiple NSSA ABRs, he may want to lock in the best
performing translator by manipulating the router ID.

Pat