Re: [OSPF] Removal of MOSPF from OSPFv3

[Acee Lindem <[e-mail]>]

Mitchell,
We've discussed this before (at least once). Nobody (to the best of  
my knowledge) has implemented MOSPF for OSPFv3. If they have, they  
should come forward with a complete specification since there were  
things missing from RFC 2740 (e.g., the definition of the group LSAs).

Thanks,
Acee
On Aug 2, 2007, at 2:01 PM, Erblichs wrote:

> Acee Lindem and group,
>
> 	IMO, OSPF needs to have some form
> 	of formal DEPRECATION policy.
>
> 	WOULD it be more prudent to suggest first
> 	generating some type of DEPRECATED statement?
>
> 	This is common in OSs when a feature is about
> 	to be removed in one of the next releases.
> 	Doing so ONLY in the context of a mail alias
> 	limits the notification to a limited audience.
>
> 	IMO, that COULD be done by checking the bit
> 	in the hello and if set generating the msg
> 	one time per intf.
>
> 	In theory, the DEPRECATE statement would suggest
> 	sending a email to the [e-mail] 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 [e-mail]
> 	mail alias.
>
> 	THis would cover ALL users who MIGHT be using
> 	a non-conformant and/or legacy (not currently in
> 	business) router and people who read the ospf RFCs
> 	but do not subscibe to the mail alias.
>
> 	In the legal sense, I believe this would be equal
> 	to "Due Diligence".
>
> 	Mitchell Erblich
> 	--------------------
>
> 	
>
> 	
>
> 	
>
> Acee Lindem wrote:
>>
>> Hi Dan,
>>
>> On Aug 1, 2007, at 10:22 AM, Daniel Joyal wrote:
>>
>>> This also has an impact to the OSPFv3 MIB which has multicast- 
>>> specific
>>> objects that would need to be removed.
>>
>> Yup. ospfv3MulticastExtensions and ospfv3IfMulticastForwarding could
>> be removed. Anything else?
>>
>> Thanks,
>> Acee
>>
>>>
>>> -Dan
>>>
>>>> -----Original Message-----
>>>> From: Acee Lindem [mailto:[e-mail]]
>>>> 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
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ospf


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