Re: [OSPF] Removal of MOSPF from OSPFv3

Acee and group,

	Has the IETF removed / plan to remove the
	MOSPF RFC?

	Mitchell Erblich
	----------------

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?
> 
>         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...
> 
>         Then the issue comes into play about routers no longer
>          having their supftware updated who IGNORE this bit
>          once it is re-used.
> 
>         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@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@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@redback.com]
> > >>>> Sent: Tuesday, July 31, 2007 6:03 PM
> > >>>> To: OSPF List
> > >>>> Subject: [OSPF] Removal of MOSPF from OSPFv3
> > >>>>
> > >>>> MOSPF has never really been fully specified in RFC 2740 and,
> > >>>> to the best of my knowledge, has never been implemented.
> > >>>> Hence, we again had some discussions about removing it from
> > >>>> the respin. I've made the changes but have not submitting
> > >>>> them. I've also attempted to reclaim the MC-bit in the prefix
> > >>>> options since this was never fully specified either and has
> > >>>> proved to be grossly inadequate to separate unicast and
> > >>>> multicast topologies. Please send comments ASAP. If I don't
> > >>>> hear any serious dissent I'll submit the update and we'll do
> > >>>> a quick re-WGLC.
> > >>>>
> > >>>> Thanks,
> > >>>> Acee
> > >>>>
> > >>>> ***************
> > >>>> *** 82,89 ****
> > >>>>       addition, option handling has been made more flexible.
> > >>>>
> > >>>>       All of OSPF for IPv4's optional capabilities, including
> > >>>> demand
> > >>>> !    circuit support, Not-So-Stubby Areas (NSSAs), and the
> > >>>> multicast
> > >>>> !    extensions to OSPF (MOSPF) are also supported in OSPF for
> > >>>> IPv6.
> > >>>>
> > >>>>
> > >>>>
> > >>>> --- 82,89 ----
> > >>>>       addition, option handling has been made more flexible.
> > >>>>
> > >>>>       All of OSPF for IPv4's optional capabilities, including
> > >>>> demand
> > >>>> !    circuit support and Not-So-Stubby Areas (NSSAs) are also
> > >>>> supported in
> > >>>> !    OSPF for IPv6.
> > >>>>
> > >>>>
> > >>>>
> > >>>> ***************
> > >>>> *** 828,844 ****
> > >>>>       LSAs, network-LSAs, inter-area-prefix-LSAs,
> > >>>> inter-area-router- LSAs,
> > >>>>       and intra-area-prefix-LSAs.  LSAs with unknown LS type,
> > >>>> U-bit set to
> > >>>>       1 (flood even when unrecognized) and area scope also
> > >>>> appear in the
> > >>>> !    area data structure.  IPv6 routers implementing MOSPF add
> > >>>> group-
> > >>>> !    membership-LSAs to the area data structure.  NSSA-LSAs are
> > >>>> also
> > >>>> !    included in an NSSA area's data structure.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 15]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>    3.1.2.  The Interface Data structure
> > >>>> --- 828,844 ----
> > >>>>       LSAs, network-LSAs, inter-area-prefix-LSAs,
> > >>>> inter-area-router- LSAs,
> > >>>>       and intra-area-prefix-LSAs.  LSAs with unknown LS type,
> > >>>> U-bit set to
> > >>>>       1 (flood even when unrecognized) and area scope also
> > >>>> appear in the
> > >>>> !    area data structure.  NSSA-LSAs are also included in an
> > >>>> NSSA area's
> > >>>> !    data structure.
> > >>>> !
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 15]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>    3.1.2.  The Interface Data structure
> > >>>> ***************
> > >>>> *** 1086,1094 ****
> > >>>>       o  The Options field within Database Description
> > >>>> packets has moved
> > >>>>          around, getting larger in the process.  More options
> > >>>> bits are now
> > >>>>          possible.  Those that MUST be set correctly in Database
> > >>>> !       Description packets are: The MC-bit is set if and only
> > >>>> if the
> > >>>> !       router is forwarding multicast datagrams according to
> > >>>> the MOSPF
> > >>>> !       specification in [MOSPF], and the DC-bit is set if and only
> > >>>> if the
> > >>>>          router wishes to suppress the sending of Hellos over
> > >>>> the interface
> > >>>>          (see [DEMAND]).  Unrecognized bits in the Database
> > >>>> Description
> > >>>>          packet's Options field should be cleared.
> > >>>> --- 1086,1092 ----
> > >>>>       o  The Options field within Database Description
> > >>>> packets has moved
> > >>>>          around, getting larger in the process.  More options
> > >>>> bits are now
> > >>>>          possible.  Those that MUST be set correctly in Database
> > >>>> !       Description packets are: The DC-bit is set if and only
> > >>>> if the
> > >>>>          router wishes to suppress the sending of Hellos over
> > >>>> the interface
> > >>>>          (see [DEMAND]).  Unrecognized bits in the Database
> > >>>> Description
> > >>>>          packet's Options field should be cleared.
> > >>>> ***************
> > >>>> *** 1577,1591 ****
> > >>>>       should be set unless the router will not participate in
> > >>>> transit
> > >>>> IPv6
> > >>>>       routing.  The E-bit should be clear if and only if the
> > >>>> attached area
> > >>>>       is an OSPF stub or OSPF NSSA area.  The E-bit should
> > >>>> always be set in
> > >>>> !    AS scoped LSAs.  The MC-bit should be set if and only if
> > >>>> the router
> > >>>> !    is running MOSPF and the LSA is to be used in the multicast
> > >>>> SPF
> > >>>> !    computation (see [MOSPF]).  The N-bit should be set if
> > >>>> and only if
> > >>>> !    the attached area is an OSPF NSSA area.  The R-bit should
> > >>>> be set
> > >>>> !    unless the router will not participate in any transit
> > >>>> routing.  The
> > >>>> !    DC-bit should be set if and only if the router can correctly
> > >>>> process
> > >>>> !    the DoNotAge bit when it appears in the LS age field of LSAs
> > >>>> (see
> > >>>> !    [DEMAND]).  All unrecognized bits in the Options field
> > >>>> should be
> > >>>> !    cleared.
> > >>>>
> > >>>>       The V6-bit and R-bit are only examined in Router-LSAs
> > >>>> during the SPF
> > >>>>       computation.  In other LSA types containing options,
> > >>>> they are set for
> > >>>> --- 1577,1588 ----
> > >>>>       should be set unless the router will not participate in
> > >>>> transit
> > >>>> IPv6
> > >>>>       routing.  The E-bit should be clear if and only if the
> > >>>> attached area
> > >>>>       is an OSPF stub or OSPF NSSA area.  The E-bit should
> > >>>> always be set in
> > >>>> !    AS scoped LSAs.  The N-bit should be set if and only if the
> > >>>> attached
> > >>>> !    area is an OSPF NSSA area.  The R-bit should be set unless the
> > >>>> router
> > >>>> !    will not participate in any transit routing.  The DC-bit
> > >>>> should be
> > >>>> !    set if and only if the router can correctly process the
> > >>>> DoNotAge
> > >>>> bit
> > >>>> !    when it appears in the LS age field of LSAs (see
> > >>>> [DEMAND]).  All
> > >>>> !    unrecognized bits in the Options field should be cleared.
> > >>>>
> > >>>>       The V6-bit and R-bit are only examined in Router-LSAs
> > >>>> during the SPF
> > >>>>       computation.  In other LSA types containing options,
> > >>>> they are set for
> > >>>> ***************
> > >>>> *** 1603,1610 ****
> > >>>>       State ID fields.
> > >>>>
> > >>>>       To the left of the Options field, the router capability
> > >>>> bits V, E,
> > >>>> !    and B should be set according to Section 12.4.1 of
> > >>>> [OSPFV2].  Bit W
> > >>>> !    should be coded according to [MOSPF].
> > >>>>
> > >>>>       Each of the router's interfaces to the area are then
> > >>>> described by
> > >>>>       appending "link descriptions" to the router-LSA.  Each link
> > >>>> --- 1600,1606 ----
> > >>>>       State ID fields.
> > >>>>
> > >>>>       To the left of the Options field, the router capability
> > >>>> bits V, E,
> > >>>> !    and B should be set according to Section 12.4.1 of [OSPFV2].
> > >>>>
> > >>>>       Each of the router's interfaces to the area are then
> > >>>> described by
> > >>>>       appending "link descriptions" to the router-LSA.  Each link
> > >>>> ***************
> > >>>> *** 1732,1748 ****
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 31]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>          Designated Router.
> > >>>>
> > >>>>       o  The Options field in the network-LSA is set to the
> > >>>> logical OR of
> > >>>>          the Options fields contained within the link's
> > >>>> associated link-
> > >>>> !       LSAs.  In this way, the network link exhibits a capability
> > >>>> when at
> > >>>> !       least one of the link's routers requests that the
> > >>>> capability be
> > >>>>          advertised.
> > >>>>
> > >>>>       As an example, assuming that Router RT4 has been
> > >>>> elected Designated
> > >>>> --- 1732,1749 ----
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 31]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>          Designated Router.
> > >>>>
> > >>>>       o  The Options field in the network-LSA is set to the
> > >>>> logical OR of
> > >>>>          the Options fields contained within the link's
> > >>>> associated link-
> > >>>> !       LSAs corresponding to fully adjacent neighbors.  In
> > >>>> this way,
> > >>>> the
> > >>>> !       network link exhibits a capability when at least one fully
> > >>>> !       adjacent neighbor on the link requests that the
> > >>>> capability be
> > >>>>          advertised.
> > >>>>
> > >>>>       As an example, assuming that Router RT4 has been
> > >>>> elected Designated
> > >>>> ***************
> > >>>> *** 1787,1801 ****
> > >>>>
> > >>>>
> > >>>>
> > >>>> !
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 32]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.  The
> > >>>> coding
> > >>>> !       of the MC-bit depends upon whether, and if so how, MOSPF is
> > >>>> !       operating in the routing domain (see [MOSPF]).
> > >>>>
> > >>>>       o  Link-local addresses MUST never be advertised in inter-
> > >>>> area-
> > >>>>          prefix-LSAs.
> > >>>> --- 1788,1799 ----
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 32]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.
> > >>>>
> > >>>>       o  Link-local addresses MUST never be advertised in inter-
> > >>>> area-
> > >>>>          prefix-LSAs.
> > >>>> ***************
> > >>>> *** 1894,1916 ****
> > >>>>          Address Prefix fields embedded within the LSA body.
> > >>>> Network Mask
> > >>>>          is no longer specified.
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.  The
> > >>>> coding
> > >>>> !       of the MC-bit depends upon whether, and if so how, MOSPF is
> > >>>> !       operating in the routing domain (see [MOSPF]).
> > >>>> !
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> - Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 34]
> > >>>> -
> > >>>>
> > >>>> - Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>> !    o  Link-local addresses can never be advertised in AS-
> > >>>> external-
> > >>>> LSAs.
> > >>>>
> > >>>> -    o  The forwarding address is present in the
> > >>>> AS-external-LSA if and
> > >>>> -       only if the AS-external-LSA's bit F is set.
> > >>>>
> > >>>>       o  The external route tag is present in the
> > >>>> AS-external-LSA if and
> > >>>>          only if the AS-external-LSA's bit T is set.
> > >>>> --- 1892,1911 ----
> > >>>>          Address Prefix fields embedded within the LSA body.
> > >>>> Network Mask
> > >>>>          is no longer specified.
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.
> > >>>>
> > >>>> +    o  Link-local addresses can never be advertised in AS-
> > >>>> external-
> > >>>> LSAs.
> > >>>>
> > >>>> +    o  The forwarding address is present in the
> > >>>> AS-external-LSA if and
> > >>>> +       only if the AS-external-LSA's bit F is set.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 34]
> > >>>> !
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>       o  The external route tag is present in the
> > >>>> AS-external-LSA if and
> > >>>>          only if the AS-external-LSA's bit T is set.
> > >>>> ***************
> > >>>> *** 1982,1990 ****
> > >>>>          Address Prefix fields embedded within the LSA body.
> > >>>> Network
> > >>>> Mask
> > >>>>          is no longer specified.
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.  The
> > >>>> coding
> > >>>> !       of the MC-bit depends upon whether, and if so how, MOSPF is
> > >>>> !       operating in the routing domain (see [MOSPF]).
> > >>>>
> > >>>>       o  Link-local addresses can never be advertised in NSSA-LSAs.
> > >>>>
> > >>>> --- 1971,1977 ----
> > >>>>          Address Prefix fields embedded within the LSA body.
> > >>>> Network
> > >>>> Mask
> > >>>>          is no longer specified.
> > >>>>
> > >>>> !    o  The NU-bit in the PrefixOptions field should be clear.
> > >>>>
> > >>>>       o  Link-local addresses can never be advertised in NSSA-LSAs.
> > >>>>
> > >>>> ***************
> > >>>> *** 2450,2475 ****
> > >>>>       area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004),
> > >>>> NSSA-LSAs
> > >>>>       (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and
> > >>>> Intra-
> > >>>>       Area-Prefix-LSAs (0x2009) are assumed to be understood by all
> > >>>> !    routers.  However, not all LS types are understood by
> > >>>> all routers,
> > >>>> !    For example, the group-membership-LSA (0x2006) is understood
> > >>>> only by
> > >>>> !    MOSPF routers and since it has its U-bit set to 0.  This LS
> > >>>> Type
> > >>>> !    should only be flooded to a non-MOSPF neighbor (determined by
> > >>>> !    examining the MC-bit in the neighbor's Database Description
> > >>>> packets'
> > >>>> !    Options field) when the neighbor is Designated Router or
> > >>>> Backup
> > >>>> !    Designated Router for the attached link.
> > >>>> !
> > >>>> !    The previous paragraph solves a problem for IPv4 OSPF
> > >>>> extensions
> > >>>> such
> > >>>> !
> > >>>> !
> > >>>> !
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 44]
> > >>>> !
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>> !
> > >>>> !
> > >>>> !    as MOSPF, which require that the Designated Router support the
> > >>>> !    extension in order to have the new LSA types flooded across
> > >>>> broadcast
> > >>>> !    and NBMA networks (see Section 10.2 of [MOSPF]).
> > >>>>
> > >>>>    3.5.3.  Installing LSAs in the database
> > >>>>
> > >>>> --- 2422,2436 ----
> > >>>>       area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004),
> > >>>> NSSA-LSAs
> > >>>>       (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and
> > >>>> Intra-
> > >>>>       Area-Prefix-LSAs (0x2009) are assumed to be understood by all
> > >>>> !    routers.  However, all LS types MAY not be understood by all
> > >>>> routers.
> > >>>> !    For example, a new LSA type with its U-bit set to 0 MAY
> > >>>> only be
> > >>>> !    understood by a subset of routers.  This new LS Type
> > >>>> should only be
> > >>>> !    flooded to an OSPF neighbor that understands the LS type
> > >>>> or when
> > >>>> the
> > >>>> !    neighbor that doesn't understand it is Designated Router
> > >>>> or Backup
> > >>>> !    Designated Router for the attached link.  This allows
> > >>>> the LSA to be
> > >>>> !    flooded on the local link even if either the router elected
> > >>>> !    Designated Router or Backup Designated Router doesn't
> > >>>> understand
> > >>>> the
> > >>>> !    LS type.
> > >>>>
> > >>>>    3.5.3.  Installing LSAs in the database
> > >>>>
> > >>>> ***************
> > >>>> *** 3395,3406 ****
> > >>>>       neighbor relationships from forming (e.g., the E-bit
> > >>>> below); these
> > >>>>       mismatches are discovered through the sending and
> > >>>> receiving of
> > >>>> Hello
> > >>>>       packets.  Some option mismatches prevent particular LSA
> > >>>> types from
> > >>>> !    being flooded across adjacencies (e.g., the MC-bit
> > >>>> below); these
> > >>>> are
> > >>>> !    discovered through the sending and receiving of Database
> > >>>> Description
> > >>>> !    packets.  Some option mismatches prevent routers from being
> > >>>> included
> > >>>> !    in one or more of the various routing calculations
> > >>>> because of their
> > >>>> !    reduced functionality (again, the MC-bit is an example); these
> > >>>> !    mismatches are discovered by examining LSAs.
> > >>>>
> > >>>>       Seven bits of the OSPF Options field have been assigned.
> > >>>> Each
> > >>>> bit is
> > >>>>       described briefly below.  Routers should reset (i.e., clear)
> > >>>> --- 3395,3405 ----
> > >>>>       neighbor relationships from forming (e.g., the E-bit
> > >>>> below); these
> > >>>>       mismatches are discovered through the sending and
> > >>>> receiving of
> > >>>> Hello
> > >>>>       packets.  Some option mismatches prevent particular LSA
> > >>>> types from
> > >>>> !    being flooded across adjacencies these are discovered through
> > >>>> the
> > >>>> !    sending and receiving of Database Description packets.
> > >>>> Some option
> > >>>> !    mismatches prevent routers from being included in one or
> > >>>> more of
> > >>>> the
> > >>>> !    various routing calculations because of their reduced
> > >>>> functionality;
> > >>>> !    these mismatches are discovered by examining LSAs.
> > >>>>
> > >>>>       Seven bits of the OSPF Options field have been assigned.
> > >>>> Each
> > >>>> bit is
> > >>>>       described briefly below.  Routers should reset (i.e., clear)
> > >>>> ***************
> > >>>> *** 3414,3429 ****
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 61]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>                                   1                    2
> > >>>> !            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9 0  1  2  3
> > >>>> !           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+
> > >>>> !           | | | | | | | | | | | | | | | | |*|*|DC|R|N|MC| E|V6|
> > >>>> !           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+
> > >>>>
> > >>>>                               The Options field
> > >>>>
> > >>>> --- 3413,3429 ----
> > >>>>
> > >>>>
> > >>>>
> > >>>> !
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 61]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>                                   1                    2
> > >>>> !            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9 0 1  2  3
> > >>>> !           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
> > >>>> !           | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
> > >>>> !           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
> > >>>>
> > >>>>                               The Options field
> > >>>>
> > >>>> ***************
> > >>>> *** 3438,3446 ****
> > >>>>          This bit describes the way AS-external-LSAs are
> > >>>> flooded, as
> > >>>>          described in Sections 3.6, 9.5, 10.8, and 12.1.2 of
> > >>>> [OSPFV2].
> > >>>>
> > >>>> !    MC-bit
> > >>>> !       This bit describes whether IP multicast datagrams are
> > >>>> forwarded
> > >>>> !       according to the specifications in [MOSPF].
> > >>>>
> > >>>>       N-bit
> > >>>>          This bit indicates whether or not the router is
> > >>>> attached to an
> > >>>> --- 3438,3447 ----
> > >>>>          This bit describes the way AS-external-LSAs are
> > >>>> flooded, as
> > >>>>          described in Sections 3.6, 9.5, 10.8, and 12.1.2 of
> > >>>> [OSPFV2].
> > >>>>
> > >>>> !    x-Bit
> > >>>> !       This bit was previously used by MOSPF (see [MOSPF])
> > >>>> which has
> > >>>> been
> > >>>> !       deprecated for OSPFv3.  It should be set to 0 and ignored
> > >>>> upon
> > >>>> !       reception.  It may be reused in the future.
> > >>>>
> > >>>>       N-bit
> > >>>>          This bit indicates whether or not the router is
> > >>>> attached to an
> > >>>> ***************
> > >>>> *** 4021,4038 ****
> > >>>>       cases or are to be marked as not readvertisable in others.
> > >>>>
> > >>>>                         0  1  2  3  4  5  6  7
> > >>>> !                     +--+--+--+--+--+--+--+--+
> > >>>> !                     |  |  |  |DN| P|MC|LA|NU|
> > >>>> !                     +--+--+--+--+--+--+--+--+
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 72]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>                             The Prefix Options field
> > >>>> --- 4021,4038 ----
> > >>>>       cases or are to be marked as not readvertisable in others.
> > >>>>
> > >>>>                         0  1  2  3  4  5  6  7
> > >>>> !                     +--+--+--+--+--+-+--+--+
> > >>>> !                     |  |  |  |DN| P|x|LA|NU|
> > >>>> !                     +--+--+--+--+--+-+--+--+
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 72]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>>                             The Prefix Options field
> > >>>> ***************
> > >>>> *** 4050,4059 ****
> > >>>>          Section 3.4.3.9.  An implementation MAY also set the
> > >>>> LA-bit for
> > >>>>          prefixes advertised with a host PrefixLength (128).
> > >>>>
> > >>>> !    MC-bit
> > >>>> !       The "multicast" capability bit.  If set, the prefix
> > >>>> should be
> > >>>> !       included in IPv6 multicast routing calculations.  If
> > >>>> not set, it
> > >>>> !       should be excluded.
> > >>>>
> > >>>>       P-bit
> > >>>>          The "propagate" bit.  Set on NSSA area prefixes that
> > >>>> should be
> > >>>> --- 4050,4060 ----
> > >>>>          Section 3.4.3.9.  An implementation MAY also set the
> > >>>> LA-bit for
> > >>>>          prefixes advertised with a host PrefixLength (128).
> > >>>>
> > >>>> !    x-bit
> > >>>> !       This bit was previously defined as a "multicast"
> > >>>> capability bit.
> > >>>> !       However, the use was never adequately specified and
> > >>>> it is being
> > >>>> !       deprecated.  It is set to 0 and ignored upon reception.  It
> > >>>> may be
> > >>>> !       reused in the future.
> > >>>>
> > >>>>       P-bit
> > >>>>          The "propagate" bit.  Set on NSSA area prefixes that
> > >>>> should be
> > >>>> ***************
> > >>>> *** 4193,4209 ****
> > >>>>
> > >>>>       The LSA function codes are defined as follows.  The
> > >>>> origination
> > >>>> and
> > >>>>       processing of these LSA function codes are defined
> > >>>> elsewhere in
> > >>>> this
> > >>>> !    document, except for the group-membership-LSA (see
> > >>>> [MOSPF]) and the
> > >>>> !    NSSA-LSA (see [NSSA]).  As shown below, each LSA
> > >>>> function code also
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires November 12, 2007
> > >>>> [Page 75]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>     May
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>> !    implies a specific setting for the U, S1, and S2 bits.
> > >>>>
> > >>>>
> > >>>>                LSA function code   LS Type   Description
> > >>>> --- 4193,4210 ----
> > >>>>
> > >>>>       The LSA function codes are defined as follows.  The
> > >>>> origination
> > >>>> and
> > >>>>       processing of these LSA function codes are defined
> > >>>> elsewhere in
> > >>>> this
> > >>>> !    document, except for the NSSA-LSA (see [NSSA]) and
> > >>>> 0x2006 which was
> > >>>> !    previously used by MOSPF (see [MOSPF]).  MOSPF has been
> > >>>> deprecated
> > >>>>
> > >>>>
> > >>>>
> > >>>> ! Coltun, et al.          Expires February 2, 2008
> > >>>> [Page 75]
> > >>>>
> > >>>>
> > >>>> ! Internet-Draft                OSPF for IPv6
> > >>>>  August
> > >>>> 2007
> > >>>>
> > >>>>
> > >>>> !    for OSPFv3.  As shown below, each LSA function code also
> > >>>> implies a
> > >>>> !    specific setting for the U, S1, and S2 bits.
> > >>>>
> > >>>>
> > >>>>                LSA function code   LS Type   Description
> > >>>> ***************
> > >>>> *** 4213,4219 ****
> > >>>>                3                   0x2003    Inter-Area-Prefix-LSA
> > >>>>                4                   0x2004    Inter-Area-Router-LSA
> > >>>>                5                   0x4005    AS-external-LSA
> > >>>> !             6                   0x2006    Group-membership-LSA
> > >>>>                7                   0x2007    NSSA-LSA
> > >>>>                8                   0x0008    Link-LSA
> > >>>>                9                   0x2009    Intra-Area-Prefix-LSA
> > >>>> --- 4214,4220 ----
> > >>>>                3                   0x2003    Inter-Area-Prefix-LSA
> > >>>>                4                   0x2004    Inter-Area-Router-LSA
> > >>>>                5                   0x4005    AS-external-LSA
> > >>>> !

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf