Subject: RE: [OSPF] Removal of MOSPF from OSPFv3

From: "Daniel Joyal" <[email-masked]>
Date: Wed, 1 Aug 2007 10:22:04 -0400

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:[email-masked]] 
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf
> 

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 1 Aug 2007 17:46:46 -0400

Hi Dan,

> objects that would need to be removed.

Yup. ospfv3MulticastExtensions and ospfv3IfMulticastForwarding could  
be removed. Anything else?

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Thu, 02 Aug 2007 11:01:19 -0700

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 [email-masked] 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 [email-masked]
	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
	--------------------

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Aug 2007 14:15:25 -0400

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

---

From: Erblichs <[email-masked]>
Date: Thu, 02 Aug 2007 15:28:22 -0700

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
	------------------

---

From: Erblichs <[email-masked]>
Date: Thu, 02 Aug 2007 15:35:24 -0700

Acee and group,

	Has the IETF removed / plan to remove the
	MOSPF RFC?

	Mitchell Erblich
	----------------

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Aug 2007 19:22:29 -0400

Mitchell,
There was an attempt to make the base RFC historic but there was some  
pushback. However, the next time maybe we can do it. Note that I'm  
not deprecating MOSPF - just the partially specified MOSPF extensions  
in OSPFv3.

Thanks,
Acee

On Aug 2, 2007, at 6:35 PM, Erblichs wrote:

>>>>>>> !    the DoNotAge bit when it appears in the LS age field of  
>>>>>>> LSAs
>>>>>>> (see
>>>>>>> [OSPFV2].
>>>>>>> !    being flooded across adjacencies these are discovered  
>>>>>>> through
>>>>>>> the
>>>>>>> !       deprecated for OSPFv3.  It should be set to 0 and  
>>>>>>> ignored
>>>>>>> upon

---

From: Acee Lindem <[email-masked]>
Date: Thu, 2 Aug 2007 19:41:34 -0400

Mitchell,

> 	If not then WHY NOT be as careful as possible?

Again, this is MOSPF for OSPFv3.

> 	 egg problem, That's why it needs to be a 1-time FYI

We'll re-WG last call the updated OSPFv3 document without the MOSPF  
for OSPFv3 extensions. Given that we've discussed this a number of  
times, this should be ample time. Here is a link to the initial E- 
mail in one such discussion:

http://www1.ietf.org/mail-archive/web/ospf/current/msg03798.html

This was more than 18 months ago. You were one of the main dissenters  
at that time as well but, IMHO, there were no substantive objections.

> 	 having their supftware updated who IGNORE this bit

Unless they've implemented MOSPF for OSPFv3, they should not be using  
any of the deprecated bits. If you know of any implementations,  
please let us know.

Thanks,
Acee

---

From: Vincent Nogues <[email-masked]>
Date: Fri, 03 Aug 2007 09:09:32 +0200

Hi,

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 :

Then get rid of it...

Mitchell Erblich
------------------

Acee Lindem wrote:

Mitchell,

Thanks,
Acee

Acee Lindem and group,

Mitchell Erblich
--------------------

Acee Lindem wrote:

Hi Dan,

This also has an impact to the OSPFv3 MIB which has multicast-
specific
objects that would need to be removed.

Thanks,
Acee

-Dan

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Tuesday, July 31, 2007 6:03 PM
To: OSPF List
Subject: [OSPF] Removal of MOSPF from OSPFv3

Thanks,
Acee

***************
*** 82,89 ****

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 ----

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.

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.

should be set unless the router will not participate in
transit
! when it appears in the LS age field of LSAs (see
[DEMAND]). All

Designated Router.

Designated Router.

! adjacent neighbor on the link requests that the
capability be
advertised.

!

o Link-local addresses MUST never be advertised in inter-
area-
prefix-LSAs.
--- 1788,1799 ----

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 Link-local addresses can never be advertised in AS-
external-
LSAs.

+ o Link-local addresses can never be advertised in AS-
external-
LSAs.

--- 1971,1977 ----

***************
*** 2450,2475 ****
! MOSPF routers and since it has its U-bit set to 0. This LS
Type
! Options field) when the neighbor is Designated Router or
Backup

--- 2422,2436 ----
! For example, a new LSA type with its U-bit set to 0 MAY
only be

***************
*** 3395,3406 ****
mismatches are discovered through the sending and
receiving of

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 ****

1 2

The Options field

--- 3413,3429 ----

!

1 2

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

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

0 1 2 3 4 5 6 7

The Prefix Options field
--- 4021,4038 ----

0 1 2 3 4 5 6 7

The Prefix Options field
***************
*** 4050,4059 ****

! 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

! x-bit

P-bit

! 6 0x2006 Deprecated (May be
reused)

! 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

! 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

---

From: Anton Smirnov <[email-masked]>
Date: Fri, 03 Aug 2007 09:50:47 +0200

Hi,
    with OSPFv2 most implementations did not implement MOSPF (shall I 
say MOSPFv2) and the same will probably be true for OSPFv3/MOSPFv3. So I 
think it is very reasonable that we want to separate mandatory part of 
OSPFv3 from optional (and so far not very well specified) MOSPFv3.
    We are not banning MOSPFv3 work completely. If there is interest in 
MOSPFv3 it can be taken as separate work by interested parties.

    Thanks,

Anton

Vincent Nogues wrote:
> *Vincent NOGUES*

---

From: Acee Lindem <[email-masked]>
Date: Fri, 3 Aug 2007 09:08:21 -0400

Hi Vincent,

I couldn't agree more with Anton. Once you implement OSPFv3, you can  
bring it forward as an experimental RFC and specify it completely  
(not just the few reserved bits as we have today).

Also, I don't think the prospect of something that someone might  
implement or even intends to implement is enough to influence the  
standard. The original OSPFv3 document has been around since 1999 so  
there has been an ample gestation period for MOSPFv3 implementations.

Thanks,
Acee

On Aug 3, 2007, at 3:50 AM, Anton Smirnov wrote:

>    Hi,
>    with OSPFv2 most implementations did not implement MOSPF (shall  
> I say MOSPFv2) and the same will probably be true for OSPFv3/ 
> MOSPFv3. So I think it is very reasonable that we want to separate  
> mandatory part of OSPFv3 from optional (and so far not very well  
> specified) MOSPFv3.
>    We are not banning MOSPFv3 work completely. If there is interest  
> in MOSPFv3 it can be taken as separate work by interested parties.
>
>    Thanks,
>
> Anton
>
>
> Vincent Nogues wrote:
>> Hi,
>> 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,

---

From: Erblichs <[email-masked]>
Date: Fri, 03 Aug 2007 13:57:22 -0700

Group,

	First, doesn't removal of MOSPF from a well-known RFC
	remove it from the use by multiple vendors? IMO,
	this work would not be done if their is belief that
	MOSPF has strong backing.

	Who can raise their hands and state that most OSPFv3 
	capable routers don't have at least 1 MOSPF CLI
	command? I think that the CLI commands will conflict
	and need to be changed if re-use is done.

	This non-support is awareness of MOSPF and that is all
	is needed for breakage!!!!!

	How many of these CLI commands are with routers that 
	are no longer supported?

	It was my undestanding of a couple of years ago that
	MOSPF was basicly NOT classified as "historic", but
	was being treated as such within a WG meeting a couple
	of years ago. This was one of multiple multicast items.

	However, IFF we are going for re-use of the capability
	bit, then why don't we go for the re-use of the MOSPF LSA
	type value? They both have defined meanings and if you
	have no-issues with one, shouldn't you expect no issues
	with the other? Just looking it from the extreme case
	and I don't recommend this!!!!

	Minimally, DON"T ALL need to be DEPRECATED including the 
	MOSPF RFC for v3, if any re-use is done for the publicly 
	defined pieces.

	Thus, IMO available workarounds remove the need for
	re-use and allows the cruft to exist WITHOUT additional
	headaches that MIGHT follow the removal of MOSPF in
	OSPFv3. This is the secondary definition of an obsolete
	public interace and is one reason why private interfaces
	are created.

	Mitchell Erblich
	------------------

---

From: Russ White <[email-masked]>
Date: Mon, 06 Aug 2007 18:37:05 -0400

> bring it forward as an experimental RFC and specify it completely (not
> just the few reserved bits as we have today).
> 

I would support this action, as well.... It's fine to remove it for the
moment, and if someone comes forward with a full implementation, then we
can consider making it a separate document. This isn't about deprecating
it, just separating it, so the other docs can be simplified somewhat,
and removing the partial stuff out of the docs.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Erblichs <[email-masked]>
Date: Mon, 06 Aug 2007 15:55:22 -0700

Russ and group,

>that MOSPF for  
>OSPFv3 has been deprecated and the bits have been reclaimed.

     Are you sure that this isn't about deprecating it?
     
     Ok, now what do you do with 100s of documents outside
     of this RFC that says the bits are used for MOSPF?

     Group, no one needs to implement MOSPF for v3, just that
     vendors have to believe that if someone did impliment it,
     THEN they would be using those bits..

     That makes those bits UN-USEABLE for anything else.

	Mitchell Erblich
	-----------------

Russ White wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGt6KRER27sUhU9OQRAuXvAKCxK2wpeGc0RLuOFKq95pfZbOrCcwCg/DqU
> VC2vNqtq1RSJ6t05sJ7RReU=
> =sMVJ
> -----END PGP SIGNATURE-----
>

---

From: Russ White <[email-masked]>
Date: Tue, 07 Aug 2007 10:05:45 -0400

>      of this RFC that says the bits are used for MOSPF?

Are there 100's? I can't imagine there are many for MOSPF for v3, rather
than v2.... Can you point to some?

>      That makes those bits UN-USEABLE for anything else.

There are other bits, no?

:-)

Russ

- --