[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zebra
Subject:    [zebra 5912] Re: on-going NSSA.
From:       dglasspool () csscience ! com
Date:       2000-11-28 23:36:54
[Download RAW message or body]

Dear Gleb:

I hope everything is going well with your developments!

Our NSSA implementation is now directed towards the basic 35 rules in
the original RFC-1587 and with "HOOKS" for the 74 rules in the UPDATE
draft...and being ready for implementation when it becomes an RFC.

We will have a lot of check-in's by the end of the week.

I have a small favor to ask of you;  could you review the text attachment to
determine if we should forward a question to the IETF committee?

We want to make certain that any "shared" AS connection with an ABR that
serves many NSSAs is "shared" with all.

Please provide your comments, and

	Best Regards

		Dick Glasspool
["ietf.txt" (text/plain)]

Is the following "clarification" helpful for OSPF-NSSA?

ref:  RFC-1587 and "draft-ietf-ospf-nssa-update-09.txt"

Purpose of "clarification";

To establish that when there are many connected areas that are all NSSA's
and that have "shared" AS connections (one ABR), the AS is accessable to all. 

Add to section 3.4 ??

In the event one NSSA-ABR has multiple NSSA connections, the ABR could be
the elected translator for all, for any number, or none of the connected
NSSAs.  Furthermore, in the event it has any attached AS connections, the
routes to each AS may be advertised by flooding the Type-7 LSA for each AS into
ALL of the NSSAs connected, but with only the first one with the P-bit set.

For any of the NSSAs for which the ABR is the translator, all the P-bits are
cleared in the Type-7 LSAs, and the ABR performs the translation as usual. When 
the ABR is not the translator, only one of all the other elected translators will
see the P-bit, and translate the Type-7 into a Type-5, for AS-flooding.

I



[prev in list] [next in list] [prev in thread] [next in thread]