Subject: Comments on draft-ietf-ospf-mt-01.txt

From: "Kushi, David M" <[email-masked]>
Date: Fri, 18 Mar 2005 10:06:20 -0800

> 9. MT ID Values
> 
>    Since AS-External-LSAs use the high order bit in the MT-ID field 
>    (E bit) for the external metric-type, only MT-IDs in the range 
>    [0-127] are valid.  The following MT-ID values are reserved:
>     
>         0 - Reserved for routers in MTRoutingExclusionCapability mode 
>             to advertise the metric associated with the default 
>             topology (see section 11.2).

Here is a possible interpretation:

        0 - Reserved for routers with MTRoutingExclusionCapability
            mode enabled to advertise the metric associated with
            the default topology (see section 11.2); for routers
            operating with MTRoutingExclusionCapability disabled,
            its use is unrestricted.

Here is another:

        0 - Reserved for routers with MTRoutingExclusionCapability
            mode enabled to advertise the metric associated with
            the default topology (see section 11.2); for routers
            operating with MTRoutingExclusionCapability disabled,
            the MT#0 metric is implicitly contained within the
            TOS0 metric field.  If MT-ID 0 is contained within
            a list of additional MT-IDs present in the LSA, any
            additional occurrence is treated as a duplicate, and
            is ignored (in accordance with 6.).

The advantage of the former, over the latter, is that there is 
an extra MT-ID available for use (when 
MTRoutingExclusionCapability is disabled).

>  
>         1 - Reserved for the default multicast topology.
> 
>    Unknown MT-IDs SHOULD be ignored.

> 11.2 New parameter in the Area Data Structure
> 
>    We define a new parameter in the Area Data Structure:
>  
>    MTRoutingExclusionCapability
>       This is a configurable parameter that will be used to facilitate
>       the introduction of MT routers in an area and ensure backward
>       compatibility.
> 
> 
>       By default, when an area data structure is created the 
>       MTRoutingExclusionCapability is disabled.
>        
>       If MTRoutingExclusionCapability is disabled:
>         o The MT-bit MUST be cleared in Hello packets.

The text would be unambiguous if the action associated with the 
reception of an Hello packet bearing a set MT-bit, while in
this mode, was explicitly stated.  E.g. 'If an Hello packet is 
received with the MT-bit set, it is not accepted by the router'.  
Or simply, 'The MT-bit must match the configured value of the 
area parameter MTRoutingExclusionCapability if it is to be 
accepted by the router'.

> 
>         o If a link participates in a non-default topology, 
>           it is automatically included in the default topology 
>           to support backward compatibility between MT and 
>           non-MT routers. This is accomplished through advertisement
>           via the TOS0 metric field the same as in standard OSPF
[OSPF].

The clarity of this document would be improved through the addition
of examples describing the encoding of messages.

E.g. (for the presumed case where MT#0 is allowed to be used without
restriction in the disabled mode):

Assume there are two routers, RA and RB, each with an interface in
area X.  The 'MTRoutingExclusionCapability' parameter is
configured with value 'disabled' on both, for X.  RA is a non-MT 
router; RB is MT-capable.

On the interface located on RB that is in area X, and which
attaches RB to RA, MT-ID 0 is configured with value 12,
it is not reserved as a replacement for TOS0 because 
'MTRoutingExclusionCapability' has value 'disabled', and thus its
use is unrestricted; MT-ID 2 is configured with metric 10; the 
standard TOS0 metric is configured with value 14.  In this case, 
a RTR-LSA contains this:

      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
                                 . . .                                
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |*|*|*|N|W|V|E|B|        0      |            # links            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Link ID                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Link Data                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |       2       |               14              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       0       |       0       |               12              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       2       |       0       |               10              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 11.4 OSPF Control Packets Transmission Over Excluded Links
>
>   If MTRoutingExclusionCapability is enabled and the default
>   topology is not configured on an interface, connected routes MUST
>   still exist for the default topology and should enable OSPF control
>   packets to be sent and received over that interface.
>

As stated, this seems contradictory to the statement "OSPF control
packets MUST be sent over the default topology." in 5.

>
>
> 11.5 OSPF LSA Advertisement and SPF Computation for Excluded Links
>
>   When MTRoutingExclusionCapability is enabled and the link does
>   not participate in the default topology, the MT-ID#0 metric is not
>   advertised. The TOS0 metric is set to infinity (0xFFFF) but is
>   ignored during the default topology SPF computation.
>
>   When MTRoutingExclusionCapability is enabled and a link participates
>   in the default topology, MT-ID#0 metric is used to advertise the 
>   metric associated with the default topology. The TOS0 metric is set 
>   to the same value as the MT-ID#0 metric but is ignored during the 
>   default topology SPF computation.

Why not simply indicate that the TOS0 metric is not used when 
MTRoutingExclusionCapability has value 'enabled', and that the
field is cleared to zero prior to transmission?

---

From: Peter Psenak <[email-masked]>
Date: Mon, 21 Mar 2005 10:24:35 +0100

Kushi,

>>            topology (see section 11.2).

MTID values 0 is reserved for base unicast topology regardless of 
MTRoutingExclusionCapability. I'll update the text to reflect that.

> area parameter MTRoutingExclusionCapability if it is to be 

- pre-MTR routers do not understand MT-bit and should ignore it, same is 
done on routers that understand MTR but has 
MTRoutingExclusionCapability disabled.

- it's enough to detect the misconfiguration on one side - check the 
MT-bit on the router that has MTRoutingExclusionCapability enabled.

> restriction in the disabled mode):

as MTID-0 is reserved regardless of the MTRoutingExclusionCapability 
state, I think we can live without the below example.

> standard TOS0 metric is configured with value 14.  In this case, 

the fact that default topology is "disabled" on the interface means:
1. OSPF does not advertise the link in the default topology.
2. connected route for the interface exist in the RIB associated with 
the default topology

(2) allows control packets to be sent over the interface.

In other words disabling topology on the interface only affects what 
OSPF advertises.

> MTRoutingExclusionCapability has value 'enabled', and that the

does not the text above says that?
"is ignored during the default topology SPF computation"

> field is cleared to zero prior to transmission?

TOS-0 metric can be set to whatever value, because it's not used in this 
case. We can remove the part that says what value it should be set to 
and leave it up to the implementation to fill the value.

thanks,
Peter