Re: [OSPF] Removal of MOSPF from OSPFv3

[Acee Lindem <[e-mail]>]

Mitchell,
The fact that the MOSPF bits and LSA types are specifically ignored  
doesn't constitute an implementation.
Thanks,
Acee
On Aug 3, 2007, at 1:43 PM, Erblichs wrote:

> Acee Lindem,
>
> 	What I am sure about MOSPF for OSPFv3.
>
> 	- Ethereal and other networking debuggers with different
> 	  versions identifyied this bit wrt MOSPF.
>
> 	- Almost all OSPFv3 versions have some type of support
> 	  to ignore the bit and the LSA type. Some of these
> 	  routers are from companies that no longer suport the
> 	  router or no longer exist.
>
> 	- Zebra and other public domain implementations had
> 	  at least 1
>
> 	
> 	
>
> Acee Lindem wrote:
>>
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> !    f
>

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