-----Original Message-----
From: Acee Lindem [mailto:[EMAIL PROTECTED]
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
