Re: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities

[Acee Lindem <[e-mail]>]

Mitchell,

Erblichs wrote:
> Authors,
>
> 	1)
> 	It has come to my attention about a possible
> 	inconsistency or ordering of non-consistent
> 	options now exist.
>
> 	Let me clarify... Graceful Restart example
>
> 		This new draft introduces new options / capabilities
> 		(Graceful Restart) with bit 0 and bit 1. These two bits
> 		alone can cause confusion, but with the additional
> 		requirement that GR requires Opaque LSA support we have
> 		a THIRD bit involvement.
>
> 		In some document, there needs clarification as to at
> 		least GR, whether the Opaque bit should first be checked
> 		before either of these two other bits to validate
> 		whether GR support is possible.
>
> 			The first doc (GRACE) never suggested the Opaque
> 			bit LSA check before a GR-LSA was initially adv...
>
> 		Secondly, there needs to be a clarification as what
> 		should be done if a router originates Grace-LSAs that
> 		originated this LSA and did NOT set bit 0 
> 		(OSPF graceful restart capable)
>
> 		Thirdly, does the adv having not set bit 1 
> 		(OSPF graceful restart helper) SUGGEST all full adj 
> 		nbrs that with to enter GR and understand this bit,
> 		check that this bit was set? And not send out a Grace-LSA
> 		if it wasn't...
>
> 		Fourth, does the support of either bit assume that the other
> 		bit is supported? If we set bit 1, does that mean bit "0" must
> 		be set?
>   
As clearly stated in the document, the bits in question are informational.

> 	
> 	2) General comment / questions
>
> 	 A) What is meant by "OSPF routers MAY optionally advertise their
> optional capabilities"?
>
> 		Thus, what is "gained" by advertising say the GR bits?
>   
The infra-structure provides a mechanism for future options (e.g., the
TE capabilities). Since the bits advertise pre-date the corresponding 
functions,
we can't very well make them dependent on them. The bits (for OSPF routers
that do advertise the new capabilities) can be useful in debugging (this 
is also
stated in the document).

> 		Can a rtr optionally support its optional advs?
> 		
> 			Or stated another way..
>
> 		Can a rtr that has advertised GR functionality, support this
> functionality
> 		to only a subset of its nbrs?
> 		Ex: Can a DR only support a rtr that is a BDR doing a GR and not
> support
> 		    any DRothers doing a GR??????
>   
Nope - please read RFC 3623.

Thanks,
Acee
>
> 	Thank you,
> 		Mitchell Erblich
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf
>
>   

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf