Subject: Re: [Fwd: Should we update BCP draft ?]

From: Fred Baker <[email-masked]>
Date: Sat, 08 Apr 2000 08:09:25 -0400

OK, I'm back into some semblance of time-zone sanity now. I'm within 2500 
miles of home :^)

>    It is conceivable that a network manager might wish to inhibit the
>    exchange of BPDUs on a link in order to logically divide two regions
>    into separate Spanning Trees with different Roots (and potentially
>    different Spanning Tree implementations or algorithms).  In order to
>    do that, he should configure both ends to not exchange BPDUs on a
>    link.  An implementation that does not support any spanning tree
>    protocol MUST silently discard any received IEEE 802.1D BPDU packets.
>
>    If a bridge is connected to an old BCP bridge [10], the other bridge
>    cannot operate according to this specification. Options are therefore
>    to decide that:
>
>       (a) If the bridge wants to terminate the connection, it sends a
>           Terminate-Request and terminate the connection.
>       (b) If the bridge wants to run the connection but not receive old
>           BPDUs, its only option is to run without spanning tree on the
>           link at all, which is dangerous. It should send NULL Spanning
>           Tree-Protocol option and advise the network administration
>           that it has done so.
>       (c) If the bridge chooses to be entirely backward compatible, it
>           sends Configure-Ack and operates in the manner described in
>           Appendix A.
>
>    Implementations SHOULD implement a backward compatibility mode.

To be perfectly honest, I think Ewart is being a bit pedantic. I don't see 
what part of this is hard to understand. I think he's saying "your state 
machine is not completely specified, and I want you to completely specify it."

We said the implementation SHOULD be backward compatible. That means it 
SHOULD be able to do both protocols (it should be able to masquerade as an 
old-model device and be indistinguishable from such a device when it is 
doing so, either due to configuration or to the temporary necessity of 
talking to an old-model peer until it is upgraded), but we could imagine 
cases where that wasn't an absolute requirement.

We said that it should be able to choose to not run spanning tree on a link 
for some good reasons, and identified procedures to say that and do that. 
We also opined that this is inherently dangerous, and should be noted to 
network management in case it turns out to be problematic. We also indicate 
what it means to configure-accept and to terminate.

What we have not specified is how to configure-nak, which is implicit in 
PPP, and can only mean "determine whether your implementation and 
configuration can run with the choice indicated by your peer; if so, repeat 
the configure-request using the peer's choice of parameter, and if not take 
an implementation-and-configuration-dependent choice either of terminating 
the connection or repeating the configuration-request with some other 
value." Since that is implicit in PPP, I don't think we need to say that.

And, as Ewart points out, we have not specified the behavior in the case of 
a configure-reject, which can only mean "I don't understand this option, 
don't send it to me." We have, I think, two choices: assert that 
configure-rejecting both the new and the old STP options forces the device 
bringing up the link to send neither option, and it can only imply that no 
spanning tree protocol will be used on the link. Therefore, consider the 
case conceptually equivalent to having configure-rejected with the value 
NULL. Don't send the option (it was indeed a configure-reject), but log the 
event and don't use spanning tree. The other option is to say "he's 
illegal", terminate the connection, and log the reason you did so.

So either we pick one of the options, or we let the network manager 
configure it. I think configuration of this is micromanagement; it would be 
better for the working group to pick one. I think the guiding argument 
should be towards robustness.

The link exchange is more robust if it is able to do the full negotiation 
(we don't have to guess), and in the event we have to take some default 
action, the network is more robust if either spanning tree is enabled on 
every link or the link is down. Defaulting towards leaving the link able to 
carry traffic but not detect and remove loops is (he carefully and loudly 
clears his throat) not robust. So I think the only sane default behavior if 
the peer configure-rejects the option is to terminate the link. He did 
something he shouldn't have according to the specification, and allowing 
him to continue is dangerous to the network. Better to take it down and 
highlight the problem than to pass traffic and give the network manager a 
bad day trying to figure out what happened.

So if we're going to add anything, I think we should add something like:

    "In the event that both the new Management-Inline Option and the
    Spanning-Tree-Protocol-Configuration Option are configure-rejected,
    indicating that the peer implements no spanning tree protocol at
    all and doesn't understand the options, it is an incomplete
    implementation. For safety reasons the system should cease attempting
    to configure bridging, and log the fact. If the peer was configure-
    rejecting the options in order to disable spanning tree entirely, it
    understood the option but could not within its configuration comply. It
    should have sent the Spanning-Tree-Protocol-Configuration Option with
    the value NULL."

An implementation which only supports the new protocol is therefore not 
implementing a backward compatibility mode (violating the SHOULD, which is 
acceptable if the reason is clearly stated to the purchaser of the 
equipment), implements and negotiates management-inline, and if that is 
configure-rejected (his peer is an older implementation) either (if so 
configured) negotiates to run naked, or by default takes down the link. A 
backward compatible implementation would in the same case simply switch to 
its compatibility mode.

>579,583c579,583
><    (b) If the bridge wants to run the connection but not receive old
><        BPDUs, its only option is to run without spanning tree on the
><        link at all, which is dangerous. It should Configure-Reject
><        the option and advise the network administration that it has
><        done so.
>---
> >    (b) If the bridge wants to run the connection but not receive old
> >        BPDUs, its only option is to run without spanning tree on the
> >        link at all, which is dangerous. It should send NULL Spanning
                                                          ^
                                      It should send the NULL Spanning...

> >        Tree-Protocol option and advise the network administration
> >        that it has done so.

I think your other changes are fine. The working group should decide 
whether they want to add the above paragraph, and in any event I consider 
the document complete.

---

From: Karl Fox <[email-masked]>
Date: Sun, 16 Apr 2000 11:38:10 -0400

Any comments on Fred's suggested changes?  They make sense to me; what say 
the rest of you?

Karl

>    should have sent the Spanning-Tree-Protocol-Configuration Option with
...
>I think your other changes are fine. The working group should decide whether they want to add the above paragraph, and in any event I consider the document complete.

Karl Fox <[email-masked]>
Key fingerprint = 5B15 7260 D55E D680 0B93  4953 8A3B AB0E C05D 77A3

---

From: Mitsuru Higashiyama <[email-masked]>
Date: Fri, 28 Apr 2000 15:27:26 +0900

Hello Fred,

I have added your addional description into the section 4.1.4.
And put the (b) option back to Configure-Reject operation
rather than NULL STP option.

If every thing is O.K. I will issue the new draft
and post it .

Thanks,
Mitsuru

4.1.4.  Separation of Spanning Tree Domains

   (a) If the bridge wants to terminate the connection, it sends a
       Terminate-Request and terminate the connection.
   (b) If the bridge wants to run the connection but not receive old
       BPDUs, its only option is to run without spanning tree on the
       link at all, which is dangerous. It should Configure-Reject
       the option and advise the network administration that it has
       done so.
   (c) If the bridge chooses to be entirely backward compatible, it
       sends Configure-Ack and operates in the manner described in
       Appendix A.

In the event that both the new Management-Inline Option and the
Spanning-Tree-Protocol-Configuration Option are configure-rejected,
indicating that the peer implements no spanning tree protocol at
all and doesn't understand the options, it is an incomplete
implementation. For safety reasons the system should cease
attempting to configure bridging, and log the fact. If the peer was
configure-rejecting the options in order to disable spanning tree
entirely, it understood the option but could not within its
configuration comply. It should have sent the
Spanning-Tree-Protocol-Configuration Option with the value NULL.

-- 
 Mitsuru Higashiyama <[email-masked]>
 ANRITSU CORPORATION
 Systems Development Department, Information & Network Division
 Telephone  Office +81 462 96 6625  Fax +81 462 25 8387

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Apr 2000 12:16:50 -0700

>If every thing is O.K. I will issue the new draft

please do, and have Karl forward it to the IESG