RE: [OSPF] Removal of MOSPF from OSPFv3
"Daniel Joyal" <djoyal@nortel.com> Wed, 01 August 2007 14:22 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 1IGF5b-0001b4-LT; Wed, 01 Aug 2007 10:22:15 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGF5Z-0001ay-8I for ospf@ietf.org; Wed, 01 Aug 2007 10:22:13 -0400
Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGF5W-0000PW-QW for ospf@ietf.org; Wed, 01 Aug 2007 10:22:13 -0400
Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71EM8s11424; Wed, 1 Aug 2007 14:22:08 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OSPF] Removal of MOSPF from OSPFv3
Date: Wed, 01 Aug 2007 10:22:04 -0400
Message-ID: <4B7DAC3FEFD35D4A96BDD011699050140A4245F9@zrtphxm1.corp.nortel.com>
In-Reply-To: <66A3A59B-F3DA-437C-9107-67C36A4B93F7@redback.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OSPF] Removal of MOSPF from OSPFv3
thread-index: AcfTvwB/mQLdra7ZSC+iefDbTVHBtQAiEcng
References: <66A3A59B-F3DA-437C-9107-67C36A4B93F7@redback.com>
From: Daniel Joyal <djoyal@nortel.com>
To: Acee Lindem <acee@redback.com>, OSPF List <ospf@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed
Cc:
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
This also has an impact to the OSPFv3 MIB which has multicast-specific objects that would need to be removed. -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 > document to the IANA considerations. Refer to Section 5. > > + E.18. Changes from the 16 Version to the 17 Version > > + The section contains list of changes from version 16 to > version 17: > > > + o Changes to deprecate MOSPF for OSPFv3. Refer to Appendix A.2, > + Appendix A.4.2.1, and Appendix A.4.3. > > + o Deprecate the MC-bit in the prefix options which was never > + adequated specified. Refer to Appendix A.4.1.1. > > + o Clarify the setting of the options in the > network-LSA. Refer to > + Appendix A.4.4. > > > > Acee-iMac:~/ietf/xml2rfc acee$ > > > _______________________________________________ > 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
- [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