Subject: I-D ACTION:draft-ietf-ospf-cap-06.txt

From: [email-masked]
Date: Wed, 16 Feb 2005 10:24:38 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

	Title		: Extensions to OSPF for Advertising Optional Router Capabilities
	Author(s)	: A. Lindem, et al.
	Filename	: draft-ietf-ospf-cap-06.txt
	Pages		: 15
	Date		: 2005-2-15
	
It is useful for routers in an OSPF routing domain to know the
   capabilities of their neighbors and other routers in the OSPF routing
   domain.  This draft proposes extensions to OSPF for advertising
   optional router capabilities.  A new Router Information (RI) opaque
   LSA is proposed for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ospf-cap-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ospf-cap-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Feb 2005 12:25:39 -0800

Group,

	0) You specify multiple times that it is a NEW 	Router 
	information (RI) LSA in this RFC draft. Isn't it really
	just a new TLV within the Opaque LSA?

	"A new Router Information (RI) is proposed for this
	purpose."

	Thus shouldn't it really be:

	A new Router Information (RI) TLV within the Opaque
	LSA framework is proposed for this purpose".

	1) Nit:

	2. OSPF Router Information (RI) LSA

	Future OSPF features could the

		to

	Future OSPF features could use the 

	2) Bit 6 Stub Router Support

	What is broken without advertising that one may boost
	the cost of its links to attempt to remove transit
	traffic when multiple paths exist?

	What happens if the O bit isn't set in the original
	capabilitiy set? What is broken that is needed to
	set the "0" and this bit?

	What should be done / not done if this bit is set
	to 0 or 1? Crazy, should a router ignore the high
	link advertised cost if this bit is set to 0?

	FYI: If one is concerned with LSInfinity with the value
	of link cost, one could just set it abnormally high
	cost value. Shouldn't it then result in the same 
	thing?

	3) Undefined behaviour???

	This LSA TLV in my opinion really does three things. The
	first is awareness of a set of capabilities and the
	second whether the capabilities are present and third
	set within the router. If a router is capabile of
	it, I don't know why it wouldn't be set forever. I
	don't think I have ever seen a router intentionally
	supporting a degraded set of anything..

	The draft RFC does not give me the impression of
	capability awareness. It just specifies capability
	support. A router may want to wait until all the
	routers within a scope have awareness of a capability,
	and then after all are aware, turn on its capability.
	This could be done as a automatic sysnchronization.

	Specificly..
	I assume that there must be a reason why one would
	not originate this TLV with all bits set to 0. Is their
	one?

	Yes, the not sending out of this TLV is
	non awareness. The sending of this TLV with all
	bits set to 0, is forced awareness of all the bits,
	and lastly setting the bits is supported capability.

	(just interested in the non-setting of the bits)
	So, should their be any architectural differences in
	sending out this LSA with all or some bits to 0 vs
	not sending out the LSA?

	If this LSA was originated and then MaxAged / withdrawn
	voluntarily or Max sequenced, should their be a behviour
	change with the non-set bits (set to 0))?

	3b) Sorry, I see this as also being undefined.

	If a router sets different bits for the different
	flooding scopes, should the link-local set of bits
	be used in the link scope?

	You have the possibility of having an implimentation
	set different values per flooding scope. Isn't the
	area flooding LSA first flooded through a link? Thus
	if we get a area scope Opaque LSA after the link-local
	LSA and some of the bits are different, the area would
	take precendence. Else the link-would over-ride in
	the link-scope and be different outside the immediate
	links? Woooow.... 

	Sorry, the only way around this is that the bits
	themselves need a flooding scope and not based on the
	flooding scope of the Opaque LSA.  This could then
	allow the super-scope of the flooding take precendence.

	Thus, if the capability is only set for the link. That
	is simple.

	If the capability is set for the area, then link and
	area routers would get the LSA and be be synch as to
	the capability of the router.

	Lastly, all routers within the AS would recieve the
	LSA.

	The only way this could happen is to use the single
	AS scope Opaque LSA to distribute capability information
	,,, right???? 

	4) In the future, I would expect a bit to be supported
	that specifies it should be a better candidate as a
	DR BECAUSE the DR should have the superset of capabilities?
	Thus, shouldn't their be more here?

	5) Capability mismatch is one criteria that COULD determine
	that a adj should be kept or dropped? Shouldn't we have
	defined behviours with the acceptance of certain
	capabilities? For instance, with BGP, their is a term
	called transitive which allows different handling
	behaviours when unrecognized attributes are recieved.

	??6) Why would a router be interested in withdrawing or
	   changing a capability? If we consider this a rare
	   occurance, why don't we specify it as a DNA (Do Not
	   Age) LSA that doesn't needed to be repeatedly sent.
	   Thus would decrease the amount of un-ncecessary control
	   traffic within the OSPF domain?

	    The LSA for the TLV could always increment the
	    seq field and change a value.

	7) Lastly, I am just a little confused due to the multiple
	implimentations that I have seen. If a Opaque LSA changes
	one or more of its sets of TLVs, does it need to originate
	its full set of TLVs for its LSA flooding type? This is
	based on the OSPFv2 Router LSA where only 1 can be originated
	by a specific router. If they can be subsets, then only
	deltas need be originated. Thus if one capbility bit changed,
	only the capability TLV needs to be re-originated...

	Mitchell Erblich

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Feb 2005 17:01:03 -0500

>	just a new TLV within the Opaque LSA?
No - Opaque LSA are further demux'ed using opaque type and this is a new 
type
(See RFC 2370).

>	Future OSPF features could use the 
Will update.

>	cost value. Shouldn't it then result in the same 
The bit is for informational purposes (i.e. the router supports the stub 
router function
as specified in RFC 3137). Please address concerns with that RFC in a 
separate
E-mail as they are beyond the scope of the capabilities LSA.

>	supporting a degraded set of anything..
These are supported capabilies (as opposed to currently active).

>	AS scope Opaque LSA to distribute capability information
Possibly, we need some more discussion on this amongst the authors. The 
questions
on these seem to continue.

>	only the capability TLV needs to be re-originated...
While it may be interesting, there is no support for incremental LSA 
and, at least initially,
we are not originating multiple LSAs and concatenating.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Feb 2005 15:31:49 -0800

Acee  Lindem,

	As usual, you are concise with your answers.

	Its minor, but I think you are under the Opaque
	LSA framework, and the capabilities are TLVs,
	thus I didn't say Opaque LSA, but Opaque LSA
	framework.. It specifies flooding scope, etc
	and is specified from the Opaque LSA rfc..

	Ok... yes, I will ask this as a separate email..
	But same with GR... What happens if someone
	volunteers as a GR helper and doesn't declare
	the GR capability... Each capability has the
	same question, what happens if a router does
	somthing that shows the capability without 
	declaring its capability????

	A) #6 is not a future item. IMO, capability should be
	a rarely changing item. If that is so, their should
	be no need to impliment aging with respect to this LSA.

	Thus, in my opinion, this LSA should be a DNA LSA. Yes
	implimentations can impliment this without it being
	specified in the rfc..

	I just don't see them really changing or SHOULD BE
	changing once advertised. Thus, they really don't
	need to be refused on a periodic basis.

	B) This is very tricky...
	   as of 3b) My suggestion which would be a start from
	scratch. It is dictated by the embeded recieve flooding 
	scope to remove the possibility of mutiple LSAs being
	sent out with different bits set...

	It could be something like:

	Each bit expands to:

	Subtype(8 bits)
	Flooding scope (3 bits)
	transitive scope(x bits)
	reserved x bits..

	If they were ordered subtypes (1 to current non zero
	value : with the first subtype number accepted)
	(what happens if you had two #4 subtypes after each other)
	
	 Else If they were ordered begining with AS scope and sent
	in a Opaque AS flooding LSA, then...

	  Then as the Link-type only subtypes would first be
	  stripped, then area, then finally. but it would
	  happen from the bottom up (length truncations)
	  
	  Yes, upon each strip, a new length and checksum
	  would need to be computed which is not normal to
	  spec. Or one or more fields per subtype gets 0'ed.
	  Length would stay the same, but checksum would
	  change.
	  
	xx) Else if, the same LSA always gets flooded to a AS
	scope and only the TLVs that are relevent to the
	scope are used. Then the reciever would have to
	determine which flooding scope is current and check
	the appropriate flooding bit.

	Else, if multiple LSA flooding scopes are used, their
	then becomes a issue..

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

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Feb 2005 16:29:27 -0800

Group,

	their is a capability draft that includes
	informative capbility bits that apply to
	GR.

	1) What happens if a router impliments GR funtions
	without advertising this fact?

	2) How does the capability information bits
	effect the architecture of the GR functionality?

	3) What is the difference from setting 0 capability
	bits in the capability LSA vs not sending out the
	capability LSA?

	4) What is the stickyness of the GR bits? Under
	what conditions would GR informative bits be
	set and unset after boot?

	5) What should the flooding scope of these GR
	  be and at what different flooding scopes effect
	  the GR support???

	6) If no routers in a area have the GR capability
	 bits set, should the router attempt to follow GR
	 procedures or bypass GR??

	7) If GR bits are set by routers in the area and
	   no helpers are identified as part of the GR
	   spec, should we do anything different?

	Mitchell Erblich

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Feb 2005 16:29:34 -0800

Group,

	Acee asked me split out these concerns from the
	capability draft...  bit #6.

	1) What happens if RFC3137 is supported and
	not advertised in the upcoming draft as a
	informative capability?

	2) What should be diff between advertising
	  a "0" infmormative bit in the capability LSA
	  and never sending out the advertised capability LSA?
	  basicly Not yet supporting the capability
	  Opaque LSA..

	3) Why is the capability bit needed? What will
	   it fix by advertising it in the capability
	   Opaque LSA known as a RI?

	4) Do you expect a router once advertising this
	   bit in the capability RI LSA, to unadvertise
	   the bit by clearing and resending the LSA?
	   Basicly, once set, what is the reason for it
	   to be changed?

	5) What should the flooding scope of the bit
	   #6 be and how does different flooding scopes
	   effect the implimentation of support of
	   3137?

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Feb 2005 13:59:48 -0500

Hi Mitchell,

Since the graceful restart capability predates the capability draft, the
bit in the TLV are for informational purposes only. So an OSPF 
implementation
could certainly support graceful restart without supporting the 
capabilities
draft. However, if an OSPF implementation supports the capabilites LSA
it should correctly advertise its capabilities. It it didn't, I'd 
consider it a bug.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Fri, 18 Feb 2005 14:01:46 -0500

Hi Mitchell,

Since the stub router capability predates the capability draft, the
bit in the TLV are for informational purposes only. So an OSPF 
implementation
could certainly support stub router without supporting the capabilities
draft. However, if an OSPF implementation supports the capabilites LSA
it should correctly advertise its capabilities. It it didn't, I'd 
consider it a bug.

Note that an implementation may support configuration options to disable
a capability and that would be one reason for re-origination of the 
capabilities
LSA.

Thanks,
Acee