[bugzilla-daemon@xxxxxxxxxxxxx]

Jim Young changed bug 6302

What	Removed	Added
CC		jyoung@gsu.edu

Comment # 28 on bug 6302 from Jim Young

When reviewing the Type 3 summary-LSA diagram from RFC 2328, one might get the
impression that at least one TOS/TOS Metric section is mandated.

<snip>
>     Type 3 summary-LSAs are used when the destination is an IP network.
>     In this case the LSA's Link State ID field is an IP network number
>     (if necessary, the Link State ID can also have one or more of the
>     network's "host" bits set; see Appendix E for details). When the
>     destination is an AS boundary router, a Type 4 summary-LSA is used,
>     and the Link State ID field is the AS boundary router's OSPF Router
>     ID.  (To see why it is necessary to advertise the location of each
>     ASBR, consult Section 16.4.)  Other than the difference in the Link
>     State ID field, the format of Type 3 and 4 summary-LSAs is
>     identical.
> 
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |            LS age             |     Options   |    3 or 4     |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                        Link State ID                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     Advertising Router                        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                     LS sequence number                        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         LS checksum           |             length            |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Network Mask                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |      0        |                  metric                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     TOS       |                TOS  metric                    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                              …                              |
<snip>

But the subsequent text appears to make all the TOS/TOS Metric sections
optional.      

<snip>
>     Additional TOS-specific information may also be included, for
>     backward compatibility with previous versions of the OSPF
>     specification ([Ref9]). For each desired TOS, TOS-specific
>     information is encoded as follows:
> 
>     TOS IP Type of Service that this metric refers to.  The encoding of
>         TOS in OSPF LSAs is described in Section 12.3.
> 
>     TOS metric
>         TOS-specific metric information.
<snip>

My captures of OSPV V2 LS Updates with Type-3 Summary LSAs do not have any
TOS/TOS Metric sections.

---

      You are receiving this mail because:

• You are watching all bug changes.