Re: [OSPF] Removal of MOSPF from OSPFv3
Vincent Nogues <vincent.nogues@teamlog.com> Fri, 03 August 2007 07:12 UTC
Return-path: <ospf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGrLG-0005ZZ-1Z; Fri, 03 Aug 2007 03:12:58 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGrLD-0005ZL-Rg for ospf@ietf.org; Fri, 03 Aug 2007 03:12:55 -0400
Received: from smtp-rennes1.teamlog.com ([194.206.222.69] helo=mail1-rennes1.teamlog.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGrLA-00086l-GS for ospf@ietf.org; Fri, 03 Aug 2007 03:12:55 -0400
Received: from teamlog.com by paris.teamlog.com (x.x.x/x.x.x) with ESMTP id l737C55J019280; Fri, 3 Aug 2007 09:12:05 +0200
Message-ID: <46B2D4AC.9080608@teamlog.com>
Date: Fri, 03 Aug 2007 09:09:32 +0200
From: Vincent Nogues <vincent.nogues@teamlog.com>
Organization: TEAMLOG
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Erblichs <erblichs@earthlink.net>
Subject: Re: [OSPF] Removal of MOSPF from OSPFv3
References: <66A3A59B-F3DA-437C-9107-67C36A4B93F7@redback.com> <4B7DAC3FEFD35D4A96BDD011699050140A4245F9@zrtphxm1.corp.nortel.com> <93E269EB-87EB-4B6F-B212-B3E15C049B55@redback.com> <46B21BEF.F72A2FB2@earthlink.net> <D6ACB2DD-BBB5-44FA-9B41-B7B4FB594810@redback.com> <46B25A86.72B967B9@earthlink.net>
In-Reply-To: <46B25A86.72B967B9@earthlink.net>
X-MIME-Autoconverted: from 8bit to quoted-printable by mail1-rennes1.teamlog.fr id l737C55J019280
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 15dcd85cefdc68de5c59786f9c752931
Cc: OSPF List <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>
Content-Type: multipart/mixed; boundary="===============1985302798=="
Errors-To: ospf-bounces@ietf.org
I don't know any MOSPF implementation for IPv6. However, maybe, we will developp such an implementation in the coming months. This project is not yet definitive, so I would appreciate if this removal could be postponed.
Thanks,
---------------------------------------------------
Vincent NOGUES
---------------------------------------------------
Erblichs a écrit :
Yes Acee, I think we did, Are you 100% sure that NO-ONE generated a MOSPF implimentation OR used it for something ELSE OR if this bit is set is going to do WEIRD things. If not then WHY NOT be as careful as possible? I just think that this isn't the ONLY thing in the current or future that COULD/SHOULD be DEPRECATED. We could let a larger audience OUTSIDE of this mail alias be AWARE that this/these things are intended to be DEPRCATED/REMOVED. It has been around for years? Document it for 6 months, and set a clock, and MAYBE have implimentations check whether this bit is set? However, this last bit introduces the chicken and egg problem, That's why it needs to be a 1-time FYI msg if generated. Then get rid of it... Then the issue comes into play about routers no longer having their supftware updated who IGNORE this bit once it is re-used. Mitchell Erblich ------------------ Acee Lindem wrote:Mitchell, We've discussed this before (at least once). Nobody (to the best of my knowledge) has implemented MOSPF for OSPFv3. If they have, they should come forward with a complete specification since there were things missing from RFC 2740 (e.g., the definition of the group LSAs). Thanks, Acee On Aug 2, 2007, at 2:01 PM, Erblichs wrote:Acee Lindem and group, IMO, OSPF needs to have some form of formal DEPRECATION policy. WOULD it be more prudent to suggest first generating some type of DEPRECATED statement? This is common in OSs when a feature is about to be removed in one of the next releases. Doing so ONLY in the context of a mail alias limits the notification to a limited audience. IMO, that COULD be done by checking the bit in the hello and if set generating the msg one time per intf. In theory, the DEPRECATE statement would suggest sending a email to the ospf@ietf.org mailing list identifying the manufacturer and the box in question. This could be done for 1 release time of say 6 months to VERIFY that no-one is using that bit.. Currently I believe the v3 spec says to ignore a capability bit that is not understood. So, it would quietly ignore if that bit is set. IFF this suggestion would be followed, then the appropriate sections within the RFC get changed to state that this item is being DEPRECATED, and that anyone wishing to notify of any possible conflict should send a email to the ospf@ietf.org mail alias. THis would cover ALL users who MIGHT be using a non-conformant and/or legacy (not currently in business) router and people who read the ospf RFCs but do not subscibe to the mail alias. In the legal sense, I believe this would be equal to "Due Diligence". Mitchell Erblich -------------------- Acee Lindem wrote:Hi Dan, On Aug 1, 2007, at 10:22 AM, Daniel Joyal wrote:This also has an impact to the OSPFv3 MIB which has multicast- specific objects that would need to be removed.Yup. ospfv3MulticastExtensions and ospfv3IfMulticastForwarding could be removed. Anything else? Thanks, Acee-Dan-----Original Message----- From: Acee Lindem [mailto:acee@redback.com] Sent: Tuesday, July 31, 2007 6:03 PM To: OSPF List Subject: [OSPF] Removal of MOSPF from OSPFv3 MOSPF has never really been fully specified in RFC 2740 and, to the best of my knowledge, has never been implemented. Hence, we again had some discussions about removing it from the respin. I've made the changes but have not submitting them. I've also attempted to reclaim the MC-bit in the prefix options since this was never fully specified either and has proved to be grossly inadequate to separate unicast and multicast topologies. Please send comments ASAP. If I don't hear any serious dissent I'll submit the update and we'll do a quick re-WGLC. Thanks, Acee *************** *** 82,89 **** addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand ! circuit support, Not-So-Stubby Areas (NSSAs), and the multicast ! extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. --- 82,89 ---- addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand ! circuit support and Not-So-Stubby Areas (NSSAs) are also supported in ! OSPF for IPv6. *************** *** 828,844 **** LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router- LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and area scope also appear in the ! area data structure. IPv6 routers implementing MOSPF add group- ! membership-LSAs to the area data structure. NSSA-LSAs are also ! included in an NSSA area's data structure. ! Coltun, et al. Expires November 12, 2007 [Page 15] ! Internet-Draft OSPF for IPv6 May 2007 3.1.2. The Interface Data structure --- 828,844 ---- LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router- LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and area scope also appear in the ! area data structure. NSSA-LSAs are also included in an NSSA area's ! data structure. ! ! Coltun, et al. Expires February 2, 2008 [Page 15] ! Internet-Draft OSPF for IPv6 August 2007 3.1.2. The Interface Data structure *************** *** 1086,1094 **** o The Options field within Database Description packets has moved around, getting larger in the process. More options bits are now possible. Those that MUST be set correctly in Database ! Description packets are: The MC-bit is set if and only if the ! router is forwarding multicast datagrams according to the MOSPF ! specification in [MOSPF], and the DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared. --- 1086,1092 ---- o The Options field within Database Description packets has moved around, getting larger in the process. More options bits are now possible. Those that MUST be set correctly in Database ! Description packets are: The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared. *************** *** 1577,1591 **** should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in ! AS scoped LSAs. The MC-bit should be set if and only if the router ! is running MOSPF and the LSA is to be used in the multicast SPF ! computation (see [MOSPF]). The N-bit should be set if and only if ! the attached area is an OSPF NSSA area. The R-bit should be set ! unless the router will not participate in any transit routing. The ! DC-bit should be set if and only if the router can correctly process ! the DoNotAge bit when it appears in the LS age field of LSAs (see ! [DEMAND]). All unrecognized bits in the Options field should be ! cleared. The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for --- 1577,1588 ---- should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in ! AS scoped LSAs. The N-bit should be set if and only if the attached ! area is an OSPF NSSA area. The R-bit should be set unless the router ! will not participate in any transit routing. The DC-bit should be ! set if and only if the router can correctly process the DoNotAge bit ! when it appears in the LS age field of LSAs (see [DEMAND]). All ! unrecognized bits in the Options field should be cleared. The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for *************** *** 1603,1610 **** State ID fields. To the left of the Options field, the router capability bits V, E, ! and B should be set according to Section 12.4.1 of [OSPFV2]. Bit W ! should be coded according to [MOSPF]. Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link --- 1600,1606 ---- State ID fields. To the left of the Options field, the router capability bits V, E, ! and B should be set according to Section 12.4.1 of [OSPFV2]. Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link *************** *** 1732,1748 **** ! Coltun, et al. Expires November 12, 2007 [Page 31] ! Internet-Draft OSPF for IPv6 May 2007 Designated Router. o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link- ! LSAs. In this way, the network link exhibits a capability when at ! least one of the link's routers requests that the capability be advertised. As an example, assuming that Router RT4 has been elected Designated --- 1732,1749 ---- ! Coltun, et al. Expires February 2, 2008 [Page 31] ! Internet-Draft OSPF for IPv6 August 2007 Designated Router. o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link- ! LSAs corresponding to fully adjacent neighbors. In this way, the ! network link exhibits a capability when at least one fully ! adjacent neighbor on the link requests that the capability be advertised. As an example, assuming that Router RT4 has been elected Designated *************** *** 1787,1801 **** ! ! Coltun, et al. Expires November 12, 2007 [Page 32] ! Internet-Draft OSPF for IPv6 May 2007 ! o The NU-bit in the PrefixOptions field should be clear. The coding ! of the MC-bit depends upon whether, and if so how, MOSPF is ! operating in the routing domain (see [MOSPF]). o Link-local addresses MUST never be advertised in inter- area- prefix-LSAs. --- 1788,1799 ---- ! Coltun, et al. Expires February 2, 2008 [Page 32] ! Internet-Draft OSPF for IPv6 August 2007 ! o The NU-bit in the PrefixOptions field should be clear. o Link-local addresses MUST never be advertised in inter- area- prefix-LSAs. *************** *** 1894,1916 **** Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. ! o The NU-bit in the PrefixOptions field should be clear. The coding ! of the MC-bit depends upon whether, and if so how, MOSPF is ! operating in the routing domain (see [MOSPF]). ! - Coltun, et al. Expires November 12, 2007 [Page 34] - - Internet-Draft OSPF for IPv6 May 2007 ! o Link-local addresses can never be advertised in AS- external- LSAs. - o The forwarding address is present in the AS-external-LSA if and - only if the AS-external-LSA's bit F is set. o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set. --- 1892,1911 ---- Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. ! o The NU-bit in the PrefixOptions field should be clear. + o Link-local addresses can never be advertised in AS- external- LSAs. + o The forwarding address is present in the AS-external-LSA if and + only if the AS-external-LSA's bit F is set. ! Coltun, et al. Expires February 2, 2008 [Page 34] ! ! Internet-Draft OSPF for IPv6 August 2007 o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set. *************** *** 1982,1990 **** Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. ! o The NU-bit in the PrefixOptions field should be clear. The coding ! of the MC-bit depends upon whether, and if so how, MOSPF is ! operating in the routing domain (see [MOSPF]). o Link-local addresses can never be advertised in NSSA-LSAs. --- 1971,1977 ---- Address Prefix fields embedded within the LSA body. Network Mask is no longer specified. ! o The NU-bit in the PrefixOptions field should be clear. o Link-local addresses can never be advertised in NSSA-LSAs. *************** *** 2450,2475 **** area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- Area-Prefix-LSAs (0x2009) are assumed to be understood by all ! routers. However, not all LS types are understood by all routers, ! For example, the group-membership-LSA (0x2006) is understood only by ! MOSPF routers and since it has its U-bit set to 0. This LS Type ! should only be flooded to a non-MOSPF neighbor (determined by ! examining the MC-bit in the neighbor's Database Description packets' ! Options field) when the neighbor is Designated Router or Backup ! Designated Router for the attached link. ! ! The previous paragraph solves a problem for IPv4 OSPF extensions such ! ! ! ! Coltun, et al. Expires November 12, 2007 [Page 44] ! ! Internet-Draft OSPF for IPv6 May 2007 ! ! ! as MOSPF, which require that the Designated Router support the ! extension in order to have the new LSA types flooded across broadcast ! and NBMA networks (see Section 10.2 of [MOSPF]). 3.5.3. Installing LSAs in the database --- 2422,2436 ---- area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- Area-Prefix-LSAs (0x2009) are assumed to be understood by all ! routers. However, all LS types MAY not be understood by all routers. ! For example, a new LSA type with its U-bit set to 0 MAY only be ! understood by a subset of routers. This new LS Type should only be ! flooded to an OSPF neighbor that understands the LS type or when the ! neighbor that doesn't understand it is Designated Router or Backup ! Designated Router for the attached link. This allows the LSA to be ! flooded on the local link even if either the router elected ! Designated Router or Backup Designated Router doesn't understand the ! LS type. 3.5.3. Installing LSAs in the database *************** *** 3395,3406 **** neighbor relationships from forming (e.g., the E-bit below); these mismatches are discovered through the sending and receiving of Hello packets. Some option mismatches prevent particular LSA types from ! being flooded across adjacencies (e.g., the MC-bit below); these are ! discovered through the sending and receiving of Database Description ! packets. Some option mismatches prevent routers from being included ! in one or more of the various routing calculations because of their ! reduced functionality (again, the MC-bit is an example); these ! mismatches are discovered by examining LSAs. Seven bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e., clear) --- 3395,3405 ---- neighbor relationships from forming (e.g., the E-bit below); these mismatches are discovered through the sending and receiving of Hello packets. Some option mismatches prevent particular LSA types from ! being flooded across adjacencies these are discovered through the ! sending and receiving of Database Description packets. Some option ! mismatches prevent routers from being included in one or more of the ! various routing calculations because of their reduced functionality; ! these mismatches are discovered by examining LSAs. Seven bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e., clear) *************** *** 3414,3429 **** ! Coltun, et al. Expires November 12, 2007 [Page 61] ! Internet-Draft OSPF for IPv6 May 2007 1 2 ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+ ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|MC| E|V6| ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+ The Options field --- 3413,3429 ---- ! ! Coltun, et al. Expires February 2, 2008 [Page 61] ! Internet-Draft OSPF for IPv6 August 2007 1 2 ! 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ ! | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6| ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ The Options field *************** *** 3438,3446 **** This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2]. ! MC-bit ! This bit describes whether IP multicast datagrams are forwarded ! according to the specifications in [MOSPF]. N-bit This bit indicates whether or not the router is attached to an --- 3438,3447 ---- This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2]. ! x-Bit ! This bit was previously used by MOSPF (see [MOSPF]) which has been ! deprecated for OSPFv3. It should be set to 0 and ignored upon ! reception. It may be reused in the future. N-bit This bit indicates whether or not the router is attached to an *************** *** 4021,4038 **** cases or are to be marked as not readvertisable in others. 0 1 2 3 4 5 6 7 ! +--+--+--+--+--+--+--+--+ ! | | | |DN| P|MC|LA|NU| ! +--+--+--+--+--+--+--+--+ ! Coltun, et al. Expires November 12, 2007 [Page 72] ! Internet-Draft OSPF for IPv6 May 2007 The Prefix Options field --- 4021,4038 ---- cases or are to be marked as not readvertisable in others. 0 1 2 3 4 5 6 7 ! +--+--+--+--+--+-+--+--+ ! | | | |DN| P|x|LA|NU| ! +--+--+--+--+--+-+--+--+ ! Coltun, et al. Expires February 2, 2008 [Page 72] ! Internet-Draft OSPF for IPv6 August 2007 The Prefix Options field *************** *** 4050,4059 **** Section 3.4.3.9. An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128). ! MC-bit ! The "multicast" capability bit. If set, the prefix should be ! included in IPv6 multicast routing calculations. If not set, it ! should be excluded. P-bit The "propagate" bit. Set on NSSA area prefixes that should be --- 4050,4060 ---- Section 3.4.3.9. An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128). ! x-bit ! This bit was previously defined as a "multicast" capability bit. ! However, the use was never adequately specified and it is being ! deprecated. It is set to 0 and ignored upon reception. It may be ! reused in the future. P-bit The "propagate" bit. Set on NSSA area prefixes that should be *************** *** 4193,4209 **** The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this ! document, except for the group-membership-LSA (see [MOSPF]) and the ! NSSA-LSA (see [NSSA]). As shown below, each LSA function code also ! Coltun, et al. Expires November 12, 2007 [Page 75] ! Internet-Draft OSPF for IPv6 May 2007 ! implies a specific setting for the U, S1, and S2 bits. LSA function code LS Type Description --- 4193,4210 ---- The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this ! document, except for the NSSA-LSA (see [NSSA]) and 0x2006 which was ! previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated ! Coltun, et al. Expires February 2, 2008 [Page 75] ! Internet-Draft OSPF for IPv6 August 2007 ! for OSPFv3. As shown below, each LSA function code also implies a ! specific setting for the U, S1, and S2 bits. LSA function code LS Type Description *************** *** 4213,4219 **** 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-external-LSA ! 6 0x2006 Group-membership-LSA 7 0x2007 NSSA-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA --- 4214,4220 ---- 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-external-LSA ! 6 0x2006 Deprecated (May be reused) 7 0x2007 NSSA-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA *************** *** 4272,4278 **** +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | LS Checksum | Length | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ ! | 0 |Nt|W|V|E|B| Options | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | Type | 0 | Metric | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ --- 4272,4278 ---- +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | LS Checksum | Length | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ ! | 0 |Nt|x|V|E|B| Options | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ | Type | 0 | Metric | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+ *************** *** 4326,4336 **** Bit B When set, the router is an area border router (B is for border). ! Bit W ! When set, the router is a wild-card multicast receiver. When ! running MOSPF, these routers receive all multicast datagrams, ! regardless of destination. See Sections 3, 4, and A.2 of [MOSPF] ! for details. Bit Nt When set, the router is an NSSA border router that is --- 4326,4335 ---- Bit B When set, the router is an area border router (B is for border). ! Bit x ! This bit was previously used by MOSPF (see [MOSPF]) which has been ! deprecated for OSPFv3. It should be set to 0 and ignored upon ! reception. It may be reused in the future. Bit Nt When set, the router is an NSSA border router that is *************** *** 5796,5806 **** --- 5796,5814 ---- o Add new prefix options and options field bits added in this_______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf" rel="nofollow">https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf
- [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- RE: [OSPF] Removal of MOSPF from OSPFv3 Daniel Joyal
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- Re: [OSPF] Removal of MOSPF from OSPFv3 Vincent Nogues
- Re: [OSPF] Removal of MOSPF from OSPFv3 Anton Smirnov
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Russ White
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Russ White
- Re: [OSPF] Removal of MOSPF from OSPFv3 Erblichs
- Re: [OSPF] Removal of MOSPF from OSPFv3 Acee Lindem