Subject: Re: MOSPF - Multicast OSPF

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 11 Jan 2006 15:03:04 -0800

I missed this thread when it was on rtg-dir in December, else would have
commented there.
 
We have used MOSPF in MANET experiments in the past (Moy's
implementation) and found it was convenient in that environment.  Once
you have an efficient OSPF for MANET, why run a separate multicast
routing protocol if you can avoid it?
 
So unless there is a bit crisis, I think it may be prudent to keep the
bits for the time being, since OSPF for MANET is IPv6 only.
 
Tom

________________________________

	From: Rohit Dube [mailto:[email-masked]] 
	Sent: Tuesday, January 10, 2006 10:01 PM
	To: [email-masked]
	Subject: Re: MOSPF - Multicast OSPF

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.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Jan 2006 18:59:48 -0500

Hi Tom,

>I missed this thread when it was on rtg-dir in December, else would have
This is as good a time as any to comment. I haven't made any changes to 
the OSPFv3 update draft :^)

>routing protocol if you can avoid it?
I guess for the same reasons you run a separate multicast protocol in a 
non-MANET (wired)
environment.   However, the decision for wired networks was made a long 
time ago and
perhaps today's technologies and the differences in the MANET environment
would yield a different answer.

>bits for the time being, since OSPF for MANET is IPv6 only.
So, you feel that there is a chance that MOSPFv3 may be fully specified 
and implemented for
MANET networks sometime in the future (1-4 years). Correct? If there is 
serious
consideration of this work, I'll leave the MOSPF specific bits in the 
OSPFv3 draft. Any
other comments?

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Thu, 12 Jan 2006 18:05:28 -0800

Acee, et, al,

	Here are my first few comments. I will give you more
	this weekend if my reading is to your aggreement.

	1)
	   A.4 LSA formats
	   "defines seven distinct types of LSAs."

	   A.4.2.1 LSA Type : lists 9 types, thus seven -> nine

	2) 
	   3.1.3 Neighbor Data Structure

	Neighbor's Backup Designated Router
	
      The neighbor's choice of Designated Router is now encoded as a
      Router ID instead of as an IP address.

	Insert Backup between : Designated Router, because we are
	talking about the BDR. Or have you now the the same router
	ID for the DR and BDR? :^)

	3) 
	   3.2.1.1  Sending Hello packets

	and the DC-bit is set if
      and only if the router wishes to suppress the sending of future
      Hellos over the interface (see [DEMAND]).

	ONLY after an a "full" adj has been established ??????

	4)   transparent functional suggestions

	    to possibly improve convergence, the first hello pkt can
	    be sent the moment the interface becomes active

	    if like routers are used and their is a concern for
	    hello xmit synchronization, after the first hello is
	    sent randomize just the next hello between 0 and the
	    hello interval, then send hellos at the hello interval

	5) 
	   3.4.3.2  Network-LSAs

	"having two or more attached routers"

	to 

	having one or more attached routers each having a adjacency
	with the DR.

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

---

From: Erblichs <[email-masked]>
Date: Fri, 13 Jan 2006 11:34:12 -0800

group,

	yes, these are suggested comments to the 2740 revision..

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

>         ID for the DR and BDR? :^)

	... choice of Backup Designated Router ....
>         ONLY after an a "full" adj has been established ??????

	as I am assuming that hello supression should not be done
	until after at least 2-way state is attempted to be achieved.

	No, I am not 100% sure whether hellos should be
	sent on a DC link if their is a hello mismatch at the
	normal hello-interval or some less freq 2x interval
	should be chosen. Cost versus reliability / notification.

	Thus, it is assumed that the repeated hellos on a DC link could
	be an indication that a adj hasn't formed. Need to ask the DC
	authors..

>         having one or more attached routers each having a adjacency

	oh... should be full adjacency...

---

From: Acee Lindem <[email-masked]>
Date: Wed, 18 Jan 2006 16:37:26 -0500

Hi Mitchell,

Thanks for the comments. See inline.

>	yes, these are suggested comments to the 2740 revision..
We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, 
inter-area-prefix-LSAs,
 inter-area-router-LSAs,  AS-external-LSAs, link-LSAs, and NSSA-LSAs. 
That makes
eight - Corrected.

>	... choice of Backup Designated Router ....

Corrected.

>	be an indication that a adj hasn't formed. Need to ask the DC
The DC bit is set anytime the hello sender wants to negotiate Demand 
Circuit operation. My assumption
is that the DC specification doesn't have any unique changes for OSPFv3 
(other than the location
of the option bit in the options). BTW, you are correct that hello 
suppression doesn't kick in until
FULL state is reached.

>>            be sent the moment the interface becomes active
I don't see a need to add this to the specification.

>>        "having two or more attached routers"
Corrected.

>	oh... should be full adjacency...
New text states this.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 18 Jan 2006 18:07:59 -0800

Acee, et al,

	Just a few additional item Suggestions:

	A) A.3.2 The Hello Packet

	Neighbor Id

		Append -> (exception of D/C neighbors)

		Where I don't expect to see a hello within
		RouterDeadInterval sec.

	B) A.3.3 DD Packet field layout

		Options field is shown 1 bit to small.

	C) A.3.6
		To make the flooding of LSAs reliable, flooded
		LSAs are explicitly acknowledged.

		Shouldn't it be ... flooded LSAs are explicitly or
		implicitly acknowledged.

		Then ...

		This acknowledgment is ... 
	
			to

		The explicit acknowledgment is 

	D) C.3
		RouterDeadInterval

			before its neighbors declare the router down 

			to 

		before its neighbors declare the non D/C neighbor
		down.

		We are talking about missing hellos here..

	E) 3 items: Inline..

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

>  inter-area-router-LSAs,  AS-external-LSAs, link-LSAs, and NSSA-LSAs.
	E1) --> Group-membership-LSA was in the list 
> suppression doesn't kick in until

	E2)
	Should we explicitly add the above phrase to mention that
	only after a "full adj" : (Only ... established.) was my
	suggestion without the "???".

	And the other question I was raising is whether a mismatch SHOULD
	cause some (2x) backoff of the hello as to still reduce cost
	with D/C neighborrs.

	Seeing hellos on a D/C should say something anyway, so
	some are needed in case whatever is causing the mismatch
	is administratively fixed.
> I don't see a need to add this to the specification.

	E3)
	Yes, this is really a implementation item for
	improved convergence. I thought that this is
	a transparent change and should be a common
	sense item that should be added. I don't know
	of a single implementation argument against it.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 20 Jan 2006 12:32:42 -0500

Hi Mitchell,

>		Where I don't expect to see a hello within
This could be a slippery slope to try and incorporate every exception 
case. One could
make the same argument for graceful restart when the grace interval is 
greater than
the dead interval.  I've change this to "each router on the network with 
neighbor
state 1-Way or greater".

>		Options field is shown 1 bit to small.
Bits 8-31 - It's 24 bits as defined.

>		The explicit acknowledgment is 
Corrected (although I think the intent was clear without it).

>		We are talking about missing hellos here..
Since this section is defining RouterDeadInterval, I'm not sure we want 
to try and document
every case where it isn't applicable.

>	E1) --> Group-membership-LSA was in the list 
The format of this LSA is not documented in this specification. In fact, 
we were considering
getting rid of it completely but there was some opposition.

>	suggestion without the "???".
No - In this context, "future" means after the adjacency goes full. One 
should go RFC 1793 for
a precise definition of demand circuits.

>	of a single implementation argument against it.
There is not agreement in the WG on whether or not these little 
implementation tweaks
which have been practice for many years should be documented in an
informational RFC. I suggest you collaborate with authors of
draft-kou-ospf-immediately-replying-hello-00.txt.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 20 Jan 2006 14:56:11 -0800

Acee, et al,

	This is getting messy..

	I guess you raised to me what seems like a bigger
	question. Should generic protocol RFCs (Ex:2740) at 
	the time of creation or modificiation attempt to
	generate an illusion of completeness?

	If this is so, then yes, I would like to see at least
	all exceptions to common expected practices that could
	be "hidden" within one of tens of RFCs.

	Yes, I would like to see a Reference to Graceful Restart
	within this spec, if and only if (iff) it is a publicly
	documented spec AND it is(to become) common. Else,
	how would the people who read the V2 or V3 specs just
	know of its existance.

	Ex: So, who can find me in what RFC totally stubby area
	support is defined? NSSA is Ref in v3 and v2.

	And, i think we SHOULD make these RFCs with as minimal
	amount of ambiguity as possible and cross-reference them
	as freq as possible, to make sure that ALL curently supported
	implimnetations support a common set of features.

	Thus, if major changes were being done, yes, I would
	also suggest incorporation how each LSA type with its
	various scope is handled in stubs, totally stubby,
	not so totally stubby, etc area interactions.

	So, the RFC had/has the GM LSA as one of the 9 types
	and a separate RFC defines its processing, so I did
	see a need to include it, because it is slated for
	removal. But as it should be clear, at best IMO it
	should at most go to reserve with the type value and
	not reused. It could then be covered with other unknown
	types as you stated in a earlier email.

>I've change this to "each router on the network with
> neighbor
> state 1-Way or greater".

	Yes, I agree, this is more accurate, But it looses
	the implicit hello pkt to hello pkt field exchange.

> every case where it isn't applicable.

	Why not? :) 
	Actually, in general, I would expect us to list at least
	A FEW exceptions as we see them and indicate in a footnote
	that the list may not be ALL encompassing.

	Else, we should consider it as an equiv as a Architectural
	constant.

> informational RFC.

	If "little implemenatation tweaks" are common public 
	practice, then at least they should be documented/ standardized, 
	IMO.

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 20 Jan 2006 18:01:29 -0500

Mitchell,

>	be "hidden" within one of tens of RFCs.
When the exception needs to be documented for the specification to be 
correct, I'll
add it or re-word the text. I am not going to document every exception 
every time
a given protocol construct is mentioned. As Editor, I'll make the 
determination of
whether or not a suggestion adds value or simply bulk.

>	support is defined? NSSA is Ref in v3 and v2.
RFC 3101 is the definitive source for OSPF NSSA. The OSPFv3 unique encodings
and protocol processing are included in the draft. If any are missing, 
please bring them
forward.

>	the implicit hello pkt to hello pkt field exchange.
This section describes the hello packet format.

>	Else, we should consider it as an equiv as a Architectural
I disagree. It isn't really necessary. If one is going to implement 
demand circuits one must
consult RFC 1793. I'd reconsider if you can garner the support of 
others. Otherwise, give it
up.

>	practice, then at least they should be documented/ standardized, 
My previous suggestion on who to collaborate with still holds.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 23 Jan 2006 20:16:27 -0800

Acee,
		This is an example of items that IMO SHOULD have
		at least mention the new area type within
		the V2 and V3 mods to OSPF.
	
		FYI to readers: Well known OSPF implimentors
		had publicly documented an area type
		known as "Totally Stubby" that removes
		all Type-3 LSAs, except a single type-3
		to advertise the default route. This was
		done YEARS ago.
		
		3101 now has the ImportSummmaries
		of the NSSA RFC that covers the usage
		of Type-3 LSAs and when NOT-ENABLED,
		transforms support for the "Totally Stubby"
		area type.

		---->RFC 3101 Suggested line addition.

		2.7 Optionally Importing Summary Routes
		"This alternate type-3 behaviour is part of a 
		sub-area type known as "Totally Stubby".
		--------------

		So, In general I would have expected that the
		original and newer v3 specs to explicitly mention
		the sub, NSSA, and the totally
		stubby area type, with the last one mentioning a
		possible change of behaviour of LSA type-3s. This
		is because alot of readers will not associate the
		well known area type of "Totally Stubby", with
		this new change.

		Mitchell Erblich
		===================

---

From: Acee Lindem <[email-masked]>
Date: Tue, 24 Jan 2006 13:57:44 -0500

Mitchell,

>		sub-area type known as "Totally Stubby".
Characterizing an NSSA or stub area with ImportSummaries enabled as a 
"Totally Stubby"
is not necessary to understand or implement the NSSA specification. I 
believe the
term was coined by my current employer and later adopted by other 
vendors. However,
that doesn't mean it needs to be part of the standard. Notice that 
nobody has you configure
these as new area types. I did add "ImportSummaries" to appendix C.2.

Any other opinions?

Thanks,
Acee