Subject: Re: PPP BCP proposed IETF standard

From: Mitsuru Higashiyama <[email-masked]>
Date: Thu, 17 Feb 2000 04:38:02 +0900

Hello Ewart,

Thank you for your comments and suggestions.

> Ewart Tempest wrote:
> 
>      Mitsuru,
> 
>      I have included my comments below, and many thanks for the useful
>      feedback.
> 
>      I asked Fred whether or not he was aware of any reference
>      implementations of the I-D, or of any product groups that were
>      implementing the I-D, since I have an interest in modifying our
>      3rd-party supplied PPP implementation to implement the I-D and
>      doing some interop. Do you know of any development groups/e-mail
>      contacts working on I-D implementations?

I am implementing it now. But my PPP implementation only support
SONET interface. What kind of line do you want to use in interop ?

> 
>      Thanks.
> 
>      Ewart
> 
>           -----Original Message-----
>           From:   Mitsuru Higashiyama
>           [SMTP:[email-masked]]
>           Sent:   Monday, February 14, 2000 5:17 PM
>           To:     Fred Baker
>           Cc:     Tempest, Ewart [IRE07:GC72:EXCH]; Thomas Narten;
>           Erik Nordmark; [email-masked]
>           Subject:        Re: PPP BCP proposed IETF standard
> 
>           Hello,
> 
>           Fred Baker wrote:
>           >
>           > Mitsuru-san:
>           >
>           > This seems like a reasonable comment. We can take this as
>           an IETF Last
>           > Call comment, unless there is concern from the Area
>           Director.
> 
>           I see.
> 
>           > Fred
>           >
>           > At 01:37 PM 2/11/00 +0000, Ewart Tempest wrote:
>           >
>           > > Hi Fred,
>           > >
>           > > I know that draft 0.3 of the PPP BCP has been put
>           forward as a
>           > > proposed IETF standard. As one of the authors, I
>           wondered whether
>           > > the following clarifications could be made to the texts:
> 
>           > >
>           > > 1) In section 4.1.4:
>           > > "(a) If the bridge wants to terminate the connection, it
>           sends a
>           > > Terminate-Request and terminates the connection.
>           > > (b) If the bridge wants to run the connection but not
>           receive old
>           > > BPDUs, its only option is to run without the spanning
>           tree on the
>           > > link at all, which is dangerous. It should
>           Configure-Reject the
>           > > <specify option> option and advise the network
>           administration that
>           > > it has done so."
>           >
>           > Ewart, are you asking us in this to specify the option? It
>           should
>           >  configure-reject the older Spanning Tree Bridge PDU
>           option.
> 
>           Ewart, thanks your english corrections.
>           I would like to wait your answer to Fred's question, too.
>           [Tempest, Ewart [IRE07:GF62-M:EXCH]]
>           I was asking for the option to be explicitly specified in
>           the texts, yes.

O.K. I understand what was you asking.

As your other comment for NULL Spanning-Tree-Protocol option and
Configure-Reject issue, I would like to change the paragraph in 4.1.4 
as bellow:

 (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.

> 
>           > > 2) In the first paragraph of Appendix A, I assume that
>           the sections
>           > > 4.2 and 4.3 being referred to are those of RFC 1638:
> 
>           No, it reffers to sections 4.2 and 4.3 in this I-D. The
>           sections 4.2
>           and 4.3 defines new BCP frame formats. The first paragraph
>           of Appendix A
>           mean that:
>             By default, Spanning Tree BPDUs MUST be carried with MAC
>           or 802.2 LLC
>             header described in section 4.2 or 4.3 of this I-D. If you
>           wants to
>             connect to old BCP implementations, you will use Spanning
>           Tree Frame
>             format of old BCP described in Appendix A.
>           [Tempest, Ewart [IRE07:GF62-M:EXCH]]
>           OK. The first paragraph in Appendix A needs clarification:
> 
>           "By default, Spanning Tree BPDU MUST be carried with MAC or
>           802.2 LLC header described in section 4.2 or 4.3. This
>           format MUST be used when it connect to old BCP
>           implementation to keep backward compatibility."
> 
>           In order to achieve backwards compatibility (with RFC 1638
>           compliant bridges), you have to encode BPDUs as per sections
>           4.2 and 4.3 of RFC 1638, not the I-D, although I appreciate
>           that one would have to use the Spanning-Tree-Protocol option
>           to negotiate to this position. In the description for the
>           Management-Inline option, it clearly states that this (the
>           Management-Inline) option would typically be the first
>           option to be negotiated so that one could determine what
>           kind of compliant entity was at the other end of the link.
>           Only once you know this would one be in a reasonable
>           position to decide whether, and if so how, to negotiate
>           use/non-use of the STP over the link.
> 
>           A suggested rewording for the above paragraph would be:
> 
>           "By default, Spanning Tree BPDUs MUST be encoded with a MAC
>           or 802.2 LLC header as described in section 4.2 or 4.3 of
>           this document. However, should the remote entity
>           Configure-Reject the Management-Inline option, thereby
>           indicating that it is a purely RFC 1638 compliant device,
>           the local entity may subsequently encode BPDUs as described
>           in section 4.3 of RFC 1638 provided that use of a suitable
>           non-NULL STP protocol across the link is successfully
>           negotiated using the (old) Spanning-Tree-Protocol option."

Thanks, I will add this explanation.

> 
>           Within the I-D, the need to negotiate the type of STP used
>           over the link seems to have been negated (the
>           Spanning-Tree-Protocol and Management-Inline options are
>           incompatible). It would be useful to add some texts to the
>           I-D which specify why this was done. Was this because, with
>           the option to enable VLAN tagging across the link, one could
>           have multiple STP instances of the same and/or different
>           type operating over the link at the same time?

Yes, as my opinion, BCP bridge should connect LAN to LAN transpearently.
Bridge can decide which kind of STP should be send/recv by himself.
Because he have already done so on LAN interfaces. On the LAN
interfaces,
he never negotiate with other bridges which kind of STP will he use.  

This rule will be applied for Link Aggregation and GARP. All management
protocols will work well on the layer of their protocol entities without
line level negotiations.

>           > >
>           > >         "By default, Spanning Tree BPDUs MUST be carried
>           with MAC or
>           > > 802.2 LLC header described in section 4.2 or 4.3
>           encoded as per
>           > > section 4.2 or 4.3 of RFC 1638. This format MUST be used
>           when it
>           > > connect connecting to old BCP implementations to keep
>           ensure
>           > > backwards compatibility."
>           > >
>           > > Please confirm. Specifically, if an IETF draft compliant
>           bridge
>           > > entity receives a Configure-Reject for the Management
>           Inline option,
>           > > the remote bridge entity must be RFC 1638 compliant. If
>           the IETF
>           > > draft compliant bridge entity does not
>           implement/understand the RFC
>           > > 1638 BPDU format, it must negotate use of the NULL
>           protocol wrt the
>           > > Spanning-Tree-Protocol negotiation, if any traffic is to
>           be bridged
>           > > over the link.
> 
>           We have already define this manner in 4.1.4. It said:
>                 (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.
> 
>           We have two options, first is sending Configure-Reject
>           described in
>           BCP-03, second is sending NULL Spanning-Tree-Protocol
>           option.
>           Is there any advantage on using NULL Spanning-Tree-Protocol
>           option ?
>           [Tempest, Ewart [IRE07:GF62-M:EXCH]]
>           So rejecting an option should really be reserved for meaning
>           "I do not understand the option, period", as is the case for
>           the new Management-Inline option, for example, when trying
>           to communicate with pure RFC 1638 bridges. Given that both
>           the IETF draft and RFC 1638 both mandate support for the
>           Spanning-Tree-Protocol option, use of Configure-Reject for
>           this option, should, strictly speaking, be an illegal thing
>           to do. Are you aware of any RFC 1638 implementations today
>           which will ever Configure-Reject this option?
> 
>           Best regards,
>           Mitsuru
>           --
>            Mitsuru Higashiyama <[email-masked]>
>            ANRITSU CORPORATION
>            Systems Development Department, Information & Network
>           Division
>            Telephone  Office +81 462 96 6625  Fax +81 462 25 8387

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