[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [OSPF] Removal of MOSPF from OSPFv3
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 at 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www1.ietf.org/mailman/listinfo/ospf