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