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

Acee Lindem <acee@cisco.com> Tue, 12 December 2006 17:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBdF-0001mf-P0; Tue, 12 Dec 2006 12:41:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBdF-0001ma-06 for ospf@ietf.org; Tue, 12 Dec 2006 12:41:33 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBdC-0005XU-KN for ospf@ietf.org; Tue, 12 Dec 2006 12:41:32 -0500
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 12 Dec 2006 09:41:30 -0800
X-IronPort-AV: i="4.09,525,1157353200"; d="scan'208"; a="450510652:sNHT49465516"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kBCHfTho028148; Tue, 12 Dec 2006 09:41:29 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBCHfTOV027116; Tue, 12 Dec 2006 09:41:29 -0800 (PST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:41:29 -0500
Received: from [10.82.208.75] ([10.82.208.75]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:41:28 -0500
Message-ID: <457EE9C8.1070901@cisco.com>
Date: Tue, 12 Dec 2006 12:41:28 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Erblichs <erblichs@earthlink.net>
Subject: Re: [OSPF] Extensions to OSPF for Advertising Optional Router Capabilities
References: <457EE558.C26ACBB9@earthlink.net>
In-Reply-To: <457EE558.C26ACBB9@earthlink.net>
Content-Type: text/plain; charset="ISO-8859-2"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Dec 2006 17:41:28.0981 (UTC) FILETIME=[C1044450:01C71E14]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2634; t=1165945290; x=1166809290; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Re=3A=20[OSPF]=20Extensions=20to=20OSPF=20for=20Advertising=2 0Optional=20Router=09Capabilities |Sender:=20; bh=hjWEksMnoGrky0hPr0Rn0Ymy1NwkguPSJofB5/1dbo0=; b=BkuEWIv0Ke6MMk+yb1iNxsgODQkR2fVNw6kceyKdhXtUzGWQYGba6i9D0Slt0rdxsCFS1yQY qlCJNtfH/yE1JMsNJcO1MdRwpd3hEth6Q+Hf+CFKx1soNAJhfOFAvmdq;
Authentication-Results: sj-dkim-7; header.From=acee@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

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
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>
>   

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf