Subject: MOSPF - Multicast OSPF

From: Acee Lindem <[email-masked]>
Date: Mon, 9 Jan 2006 17:25:26 -0500

Consideration is being given to making MOSPF (RFC 1584)
historic - Any concerns?

Also, has anyone implemented MOSPFv3? I'm considering deprecating
the bits in the OSPFv3 updated so they could be reused if we ever ran out.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 9 Jan 2006 17:46:52 -0800

Acee,

	Is this an early April fools joke?

	Can we  / should we deprecate 1349's v2's
	TOS bits and re-use them? What about the TOS 
	metric?

	IMO, There are at least four issues here.

	1) Can you deprecate a publicly specified items
	   like the bits from a newer version?

	2) Can you re-use deprecated bits?

	3) Did any OSPFv3 implimnetation check for
	   MOSPF and do anything based on the check?

	4) Do you want to differentiate v2 and v3
	   in this manner?

	IMO, no for #2 and yes for #1, but then the
	RFC change should be moot for if you can't re-use
	them, why remove it from the spec? You could update
	the RFC that this feature is no-longer expected to 
	be used.
	
	How does all the legacy router's customers who don't
	specify that they have at least checked that bit,
	and discard or whatever based on that bit speak up?
	This could obsolete these routers, if that bit was
	used/checked and re-used.

	How do defunt companies speak up?

	Thus, sorry, but IMO, once something is publicly
	RFC documented as anything but informational or experimental,
	it should be assumed that SOMEONE is using that feature.

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 9 Jan 2006 22:05:24 -0500

Mitchell,
See inline.

>	TOS bits and re-use them? What about the TOS 
RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough,
this RFC has been obsoleted by the DSCP definitions in RFC 2474.

>	   like the bits from a newer version?
It's been done before if the function isn't used. An example from OSPFv2,
would be the TOS based routing defined in RFC 1583.

>	2) Can you re-use deprecated bits?
With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived
with different semantics. You can search the archives for a protracted 
discussion
of the differences.

>	   MOSPF and do anything based on the check?
That's what I asked. I don't know of any MOSPFv3 implementation.

>	4) Do you want to differentiate v2 and v3
Yes. There are existing implementations of MOSPF (based on OSPFv2).

>	it should be assumed that SOMEONE is using that feature.
This is simply not the case in the IETF. While each case must be 
considered individually, there
have been numerous instances of deprecation.

Thanks,
Acee

---

From: Zengjie Kou <[email-masked]>
Date: Tue, 10 Jan 2006 11:54:11 +0800

Hi,Acee
    I agree with the proposals.

Thanks
Kou.

---

From: Erblichs <[email-masked]>
Date: Mon, 9 Jan 2006 22:51:24 -0800

Acee,

	1584 specifies v2, and I know of 4 large players
	who at least checked various items such as:

	MC options bit,
	W bit within the Router LSA,
	Group membership type 6,
	etc..

	I know of many v2 implimentations Doing at least some checks for 
	these items within the recvd pkts.

	Acee, And to quote you
	"to the best of my knowledge, no new implementations."

	Which I assume that you are speaking of just v2 doing
	at least some checks....

	In OSPFv3.... 
	 "ignore lsa mospf" and the like is common. 
	Thus, if the
	code that determines this is based on a bit and that bit
	is changed for re-use, this CLI will not work. If ignore
	is not used then the re-use will start executing MOSPF
	checks..

	How many router companies have at least this 1 CLI line
	in OSPFv3 and no longer provide updates? I bet every
	OSPFv3 impliimentation has the above line or its equiv.

	Who has a line like this in their OSPFv3 CLI? Big guys
	please step up.

	Who had a line like this in their v3 CLI?

	What did they check or do if NOT ignored?????

	This is just awareness of the MOSPF functionality and
	doesn't need to be FULLY implimented to make routers 
	MIS-BEHAVE.

	Thus, its okay to deprecate, but I VOTE NO for any re-use
	that may give any bit/etc two possible public meanings..

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Jan 2006 16:48:27 -0500

Mitchell,
See inline.

>	W bit within the Router LSA,
And they can continue to do that even if we make RFC 1584 historic.

>	OSPFv3 impliimentation has the above line or its equiv.
Since support for unknown types is implicit in OSPFv3, I would argue 
that this configuration
is completely unnecessary.

>	that may give any bit/etc two possible public meanings..
I'm less worried about code to ignore MOSPF protocols constructs (bits, 
LSA types,
etc). In fact, deprecating them since there are MOSPFv3 implementations 
may allow
any MOSPF specific code to be removed from OSPFv3 implementations.

Acee

---

From: Erblichs <[email-masked]>
Date: Tue, 10 Jan 2006 14:59:49 -0800

Acee,

> any MOSPF specific code to be removed from OSPFv3 implementations.

	No.  Assume that their are routers out their with no
	code updates possible.

	Assume that someone in University has distributed over
	the world MOSPF OSPFv3 support in Zebra, a fork of
	Zebra, or a fork of the Merit consortiums implimnetation,
	or whatever. Why wouldn't you make this assumption?

	Don't change the code because my assumption is that
	their are legacy routers out their that have NO ONE
	to update the code.

	Second, some companies won't remove "obsolete" code
	because the customer expects the old check and says
	what if everything works fine and I add a OLD router
	into my network, will this old router cause my NEW ones
	to fail?

> >        "ignore lsa mospf" and the like is common.

	Then WHY WHY WHY are CLI lines like these in the code
	and what do they do if NOT ignored? If they check bits
	that you re-use, then don't you agree that this would
	severely break a legacy router??? Else, the failure
	could be random, and almost impossible to trace.

	BTW, I somewhat AGREE that it SHOULD BE un-necesary, except,
	I have seen implimentations that would MININALLY spit out
	a message if seen and NOT ignored? Would you minimally
	want your buffers to fill up with bogus messages?

	Also, unknown types sometimes trigger a message. Why
	shouldn't we just ignore them? It is because we recieve
	them, process them, and want to know what is uncoded
	for being recieved on our system.

	thus, IMO, a CLI should be : ignore lsa unknown
	which should be sufficent enough and if not ignored
	generate a message for the above reasons..

	With routers having upwards of GBs of memory and Ghz
	CPUs, a few extra lines should fall into the "who cares
	category", compared to what happens if...

	Thus, if it isn't causing any problems, why fix it?

	Now mix the legacy routers with a set of updated
	routers. Do the legacy routers behave properly? 

	THUS, The only thing that would somewhat satisfy me is
	with any re-use. Before the re-use, have a suite of
	source publicly available tests that checks for 
	abnormalies. Make these tests available. And find out
	whether their are heterogenous problems. If their is 
	even 1, it should be assumed that it is "just the tip 
	of the iceberg".

	Thus, is it really worth it for re-use? 
	Are their no alternatives? 

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Jan 2006 21:34:25 -0500

Mitchell,

>	or whatever. Why wouldn't you make this assumption?
I would have heard about it :^)

>	into my network, will this old router cause my NEW ones
This assumes someone has implemented and deployed MOSPFv3.

>	even 1, it should be assumed that it is "just the tip 
Since we're respinning RFC 2740 anyway, it makes sense to deprecate the 
protocol
constructs that are necessary. No sense in leaving these in OSPFv3 if no 
one is using
them.

Thanks,
Acee

---

From: Rohit Dube <[email-masked]>
Date: Tue, 10 Jan 2006 22:01:01 -0800

Also note that back in Nov 2002, we had dropped any further protocol work on
MOSPF (v2) at the WG meeting.

If anybody has a real problem with deprecating the bits (because they are
implementing MOSPFv3), now would be a good time to step forward.

Best,
--rohit.