[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSPF] Removal of MOSPF from OSPFv3
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 ospf at ietf.org 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 ospf at ietf.org
>>>>> 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:acee at 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
>>>>>>>>
>>>>>>>>
>>>>>>>> ! f
>
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf