Re: [OSPF] Removal of MOSPF from OSPFv3

[Acee Lindem <[e-mail]>]

Mitchell,

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

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

Again, this is MOSPF for OSPFv3.


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

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.

>
> 	Then the issue comes into play about routers no longer
> 	 having their supftware updated who IGNORE this bit
>          once it is re-used.

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


>
> 	Mitchell Erblich
> 	------------------
>
> 	
>
> Acee Lindem wrote:
>>
>> 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
>>>>>>


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