Subject: draft-manral-ospf-router-lsa-unknown-type-02

From: Vishwas Manral <[email-masked]>
Date: Wed, 19 Jan 2005 02:57:06 -0800

Hi folks,

I would want to progress the following draft to completion: -

http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown
-type-02.txt

Would we want to leave it as it is, make it an individual submission to
IESG, or first make a WG draft and submit then it to IESG?

Thanks,

Vishwas

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Jan 2005 21:22:30 -0500

Vishwas Manral wrote:

> http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown-type-02.txt
>
>  
>
> Would we want to leave it as it is, make it an individual submission 
> to IESG, or first make a WG draft and submit then it to IESG?
>
Any opinions on this draft?

Speaking as a WG member I'd support it. We'll schedule 5-10 minutes in 
Minneapolis to
discuss.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Tue, 25 Jan 2005 16:05:03 -0800

Group,

	Sorry about my late reply. I have a bad cold. :-(

	If I was to agree that we should process/forward
	unknown LSA link types, I think the wording specified
	in the draft is abit ambiguous..

	Router LSA link-types 1,2, 3, and 4 are defined
	in RFC2328. However, a router may imploy a superset
	of link-types say supporting additional link-types,
	say link-type 5 for wireless links.. 

	Thus, shouldn't the "should now read" deal with
	RFC 2328 Router LSA link-types unknowns and router-id
	router LSA link-type unknowns with link-type 6 or more?????

	So, does the "Unknown Link Types are ignored" (last
	sentance  in ""2. Changes for OSPFv2"") deal
	with the RFC2328 unknowns or router-id router unknowns? 
	I assume it is the later..

	NOW, .........

	When we have a stub area.. FYI, the original reason
	for stub areas (Moy OSPF books) was to reduce the
	memory requirments..

	1) simple case first..

	Doesn't it make sense that if ALL the link-types
	within a ROUTER LSA are RFC2328 unknown that the LSA just
	consumes memory and CPU cycles.. Thus, in my opinion
	these LSAs should not be present in the routers within
	a stub area.

	  or that all the routers within the area match
	  the router-id router LSA link-type unknown..

	  I have been considering whether this ADJ should even
	  be up if the router ONLY originates Router LSAs
	  with unknown link-types??? Is it acting basicly
	  as a passive adj? We can't send data packets over
	  the link, but we should be able to recieve data
	  packets.. Thus, I think we have a 1-way data link.
	  
	2) This falls into a subcategory of #1. If some of the
	link-types are known within a Router LSA, the unknowns
	should be stripped from the Router LSA. This should
	reduce the flooding overhead and memory requirements.
	It does require a memory copy to reduce the size of the
	router LSA. 

	The assumption here is that the unknown link-types
	should be stripped. However, should they been originated
	in the first place??? Should displays (implimentation
	dependent) identify routers that generate router LSAs
	with unknown link-types?

	Thus, their are at least, LSA origination, flooding,	
	and SPF issues that need to be addressed for the
	two definitions of "unknowns" and stub/not stub areas.

	Mitchell Erblich

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Jan 2005 11:48:19 -0500

Hi Mitchell,

I don't think we want to do anything for stub areas. This draft was
a result of RFC2328 not specifying what an should be done with
unknown links types. We could have either reject the LSA or
ignore the unknown types. The opinions on the list were overwhelmingly
in favor of the latter. My opinion is that even with this draft we are
going to be extremely conservative in our introduction of new link
types.

Furthermore, stub areas are protected from externally scoped
advertisements. Note that router LSAs are area scoped and presumely
each OSPF routing domain (and surely every area) is administratively
controlled by a single party. Hence, the network administrator should have
control over whether or not new links types are deployed in a stub area.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Jan 2005 13:02:55 -0800

Acee Lindem and et. al..

	Yes and No..
	I don't always agree with the general consensus.

	The stub area type is the easist to defend when
	it comes to the limited accepted link-types.
	However, it can and does apply to non stub areas,
	as presented below.

	Only 4 router LSA link-types are RFC2328 defined and should be
	used dealing with SPF calcs. If the undefines then
	deal with metric and monitoring, then I could
	understand the acceptance of unknowns, due to the
	fact that they can do no routing harm..

	First, did any of your consensus see the
	two different Router LSA's with unknown link-types?????

	If we expound on on accepting, flooding,  etc with
	your philosphy.. Then their is a RFC2328 section
	that hasn't been addressed. Section 13.2 specifies
	that when the body of a LSA has changed, it triggers
	a SPF calculation.... Did anybody see this???

	By flooding the Router LSAs with unknown link-types
	any change with one unknown, the withdrawl of the
	unknown, etc.. will trigger SPF calculations..

	The end result can't change, but must be run to
	be in Spec with the RFC. Do you really suggest running
	additional SPF calcs when the end result is the
	same?????? If they are stripped of unknowns this
	becomes a non-issue. Any change in the body dealing
	with unknown link-types is ignored, because only
	the stripped Router LSA is compared.

	Thus, IMO, a default area type dealing with
	 router link-type 
	(due to the fact thar Router LSAs are area scope),
	MUST ONLY accept the RFC2328 4 defined link-types.
	
	A router can literally dump huge amounts of unknown
	Router LSA contents which according to you must be
	flooded throughout the area without being able to
	do any verification on the contents. It's just opaque
	data.

	IFF new router link-types need to be supported,
	Shouldn't they be allowed as NEW capabilities???
	With the new capabilities, they would need accompaning
	RFC information..

	Thus, IMO this is the most conservative approach
	that could be taken.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Jan 2005 16:11:04 -0500

Remember that the implementation of the calculation is a local matter.
In this case, the implementation can be "use the previous result" and it 
will still be consistent with the spec.

Yours,
Joel M. Halpern

At 04:02 PM 1/26/2005, you wrote:
>         same??????

---

From: Acee Lindem <[email-masked]>
Date: Wed, 26 Jan 2005 17:28:50 -0500

Mitchell,

See inline.

>	the stripped Router LSA is compared.
For MTR (multi-topology routing) one should be smarter and actually
determine what has changed before doing an SPF. Anyway, this is somewhat
implementation specific.

>	MUST ONLY accept the RFC2328 4 defined link-types.
Then you are advocating rejecting the LSA?

>	With the new capabilities, they would need accompaning
We intend to be conservative in defining new link types and they will 
require standards
action.

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Jan 2005 17:21:06 -0800

Group,

	IMO, all router LSA link-types greater than
	4 should be stripped upon reciept if they deal
	with determination of routing. 

>Then you are advocating rejecting the LSA?

	If ALL the link-types are undefined, yes
	then drop the entire router LSA after acking it.
	I don't have a compelling thought why we would
	really want to store this type of opaque data in
	our LSDB or consume bandwidth flooding it to MAYBE
	another router within our area that MIGHT understand
	it.

	And Murphys law says that each Router LSA WOULD contain
	as much as 16 bits count of undefined link-types.

	The initial assumption is that without clarifying
	information, that the undefined link-type does
	inflict routing changes. IMO, this should localize 
	any possible routing iregularities to within 1 hop
	of the router(s) originating the unknown link-types.

	As new router LSA link-types accepted, accompaning
	should be a stated capability. With this capability,
	their would need to be some form of acceptance criteria
	as either dealing with the Router LSA and/or the
	adjancency formation.

> determine what has changed before doing an SPF. Anyway, this is somewhat

	If I accept part of this reasoning, then lets fix it here!
	Then why shouldn't this draft RFC include a section 13.2 
	that specifies that some
	LSA body changes (ie: additions, subtraction,
	modification of unknown Router LSA link-types) do not
	necessitate the triggering of a SPF calc.

	Enough said...

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

---

From: Erblichs <[email-masked]>
Date: Wed, 26 Jan 2005 17:33:32 -0800

Joel Halpern,

	I did NOT write the OSPF spec.. I am just reading what it
	says and it is incorrect with respect to unknown link-types.

	The spec says that if the LSA body has changed, trigger
	a SPF calc..

	* Adding a unknown link-type to a Router LSA that
	  didn't previously have one,

	* Removing a unknown link-type,,,

	* Adding additional unknowns...

	* Changing a unknown from one unknown to another unknown..

	All these are changes to the LSA body and would
	nessitate a SPF calc according to the SPEC. Since,
	we are addressing unknowns within this draft RFC, I
	would expect us to specify this an an exception to
	the section, 13.2..

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