Subject: OSPFv3 Extension Future Direction (this ought to get your attention)

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Mar 2005 15:10:04 -0500

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

At the Minneapolis IETF, I presented a comparision of  the
various options we have for extending OSPFv3. The reaction to the
presentation was very positive. However, it was last on the agenda and
the OSPF WG coincided with other WGs (most notably L2VPN).

At this point, I would like to initiate more discussion. The basic
question is whether we go with a TLV based approach or continue
to add new LSAs which need to be synchronized with the LSAs
advertising topology and prefix information. A TLV based approach
is described in:

http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt

The crux of my presentation would be that this is gives us the powerful
extension capability while still allowing us to advertise information that
does not need to be synchronized in separate LSAs.

Thanks,
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 28 Mar 2005 00:48:48 -0800

All,

Let me clarify a couple of points:

1) The main purpose of the draft is to support MTR in OSPFv3. As the
existing LSA cannot be used for this extension, new LSA with flexible
encoding (i.e. TLV) are used for this purpose. 

2) The draft also can be used to support an integrated approach to carry
address-families in OSPFv3. Other AF would simply be defined in different
MT-ID. The next version of the draft would specify that.

3) MT capable router would interact with non-MT routers in default topology
using existing LSA. If all routers are MT capable one has the possibility to
use new LSAs even for default topology. This is controlled through
configuration via rfc2740compatibility. 

4) The draft does NOT propose to replace rfc2740 but simply the support of
MTR (and AF)

5) The draft _may_ be used to move to a flexible encoding for future
development of OSPFv3.

6) Future extensions are in no way tied to these newly proposed LSAs. As
appropriate, we would introduce them in yet another LSA (e.g. OSPFv3 TE LSA)
or as a TLVs/Sub-TLVs in our newly proposed LSAs.

7) deployment wise, there may be three categories

   7-a) if one does not need MTR/ AF, chances are that there is not much
motivation to move to this new encoding for them
   7-b) if MTR /AF are needed in some part of network, a coexistence of both
exiting and new LSA would exist
   7-c) if all routers are MTR-capable and MTR/AF are mostly deployed, new
LSA would be used

The discussion seems to be aimed at 5) however the original purpose of the
draft is 1) and 2). 

Thanks
Sina

-> -----Original Message-----
-> From: Mailing List [mailto:[email-masked]] On 
-> Behalf Of Acee Lindem
-> Sent: Wednesday, March 23, 2005 12:10 PM
-> To: [email-masked]
-> Subject: OSPFv3 Extension Future Direction (this ought to 
-> get your attention)
-> 
-> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-> Content-Transfer-Encoding: 7bit
-> 
-> At the Minneapolis IETF, I presented a comparision of  the 
-> various options we have for extending OSPFv3. The reaction 
-> to the presentation was very positive. However, it was last 
-> on the agenda and the OSPF WG coincided with other WGs (most 
-> notably L2VPN).
-> 
-> At this point, I would like to initiate more discussion. The 
-> basic question is whether we go with a TLV based approach or 
-> continue to add new LSAs which need to be synchronized with 
-> the LSAs advertising topology and prefix information. A TLV 
-> based approach is described in:
-> 
-> http://www.ietf.org/internet-drafts/draft-mirtorabi-mt-ospfv3-01.txt
-> 
-> The crux of my presentation would be that this is gives us 
-> the powerful extension capability while still allowing us to 
-> advertise information that does not need to be synchronized 
-> in separate LSAs.
-> 
-> Thanks,
-> Acee
->

---

From: Michael J Barnes <[email-masked]>
Date: Wed, 30 Mar 2005 12:03:30 -0800

Hey Acee,

I want to pass this thought by you personally before sending it to the 
whole list, to see what you think.

It seems to me that we should be talking about OSPFv4. Radical? Perhaps, 
but here's why I think this:

OSPFv3, while it has many improvements over OPSFv2, was still not really 
designed to be extended. I really agree with you in general about the 
future direction for OSPF, by including TLVs in certain data structures, 
etc., are great ideas, but the solutions are nasty hacks. But the point I 
really want to make is not that we shouldn't be extending v3, it's that 
IMHO the future direction of OSPF should first, be a version of the 
protocol that has been designed from the base to be extendable. OSPFv3 is 
part way there, and I agree with the ideas you presented for the future 
direction, but I just think it would be better in the long run to have a 
new version of OSPF for this.

If you're interested, I do have some specific ideas for functionality.

Is that too radical of an idea, or something that would be worth more thought?

Thanks,
Michael

---

From: Dave Katz <[email-masked]>
Date: Wed, 30 Mar 2005 13:12:47 -0700

Guess you sent it to the whole list anyhow.  ;-)

Bumping the version number is the only safe way to make significant 
changes for which backward compatibility may be problematic.  It 
doesn't even have to be a significant syntactic or semantic change to a 
protocol, though it tends to invite a whole bunch of meddling when you 
do so...

On Mar 30, 2005, at 1:03 PM, Michael J Barnes wrote:

> It seems to me that we should be talking about OSPFv4. Radical? 
> Perhaps, but here's why I think this:
>
> OSPFv3, while it has many improvements over OPSFv2, was still not 
> really designed to be extended. I really agree with you in general 
> about the future direction for OSPF, by including TLVs in certain data 
> structures, etc., are great ideas, but the solutions are nasty hacks. 
> But the point I really want to make is not that we shouldn't be 
> extending v3, it's that IMHO the future direction of OSPF should 
> first, be a version of the protocol that has been designed from the 
> base to be extendable. OSPFv3 is part way there, and I agree with the 
> ideas you presented for the future direction, but I just think it 
> would be better in the long run to have a new version of OSPF for 
> this.
>

---

From: Erblichs <[email-masked]>
Date: Wed, 30 Mar 2005 14:59:48 -0800

Oooooh,

	Why?

	Would v4 and v2 interoperate? If they did
	wouldn't we run into the same problems?

	Would v4 and v3 interoperate?

	IM limited opinion, the idea of extensibility
	is very difficult to achive.

	Would we support subsec hellos?

	Do we add two levels of IP support?

	Would we add nack support?

	Would we support overload notification?

	Would we support notification of router capibility
	like a Enterprise level router, that would
	over-ride DR election?

	Where do you stop?

	Just food for thought..

	Mitchell Erblich
	------------------------

---

From: Michael J Barnes <[email-masked]>
Date: Thu, 31 Mar 2005 11:34:17 -0800

Hi Acee,

> does not need to be synchronized in separate LSAs.

If we want to stick to enhancing v3 rather than moving forward to v4, then 
I would like to suggest that there be a separate draft for new LSAs (and 
perhaps other enhancements), similar to what is done in the MTR draft, but 
not specifically for MTR. The reason for a separate draft is so that we 
can design the new LSAs such that they more generally accomplish the goal 
of making OSPFv3 extendable, rather than just the more specific goal of 
supporting MTR. Then the MTR draft, and other drafts, can be written to 
take advantage of the new LSAs.

It is also my opinion that not too much be stuffed into the router LSA, 
because if the LSA becomes large enough that it must be fragmented, and 
when any small part of the LSA is updated a lot of unchanged information 
will be reflooded. There are ways that the synchronization can be 
addressed without putting many different pieces of data into the Router LSA.

Regards,
Michael