Subject: Re: [rbridge] WG last call of draft-ietf-trill-rbridge-extension-02

From: Donald Eastlake <[email-masked]>
Date: Thu, 1 Mar 2012 10:01:41 -0500

Suggested revised Section 2.4:

2.4 Conflict of Extended Header Flags

   It would be possible to specify the effects of TRILL Header
   extension flags so that two or more of them conflicted. In that
   case, flags could be present in a frame that direct an RBridge
   processing the frame to do conflicting things or to change
   its interpretation of later parts of the frame in conflicting ways.

   Conflicting extended flags MUST NOT be included in a frame. If they
   are, the results are unspecified.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Fri, Feb 24, 2012 at 12:32 PM, Donald Eastlake <[email-masked]> wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 6:16 PM, Thomas Narten <[email-masked]> wrote:
>>
>> ...
>>
>> I have some other comments on the document itself, if it goes
>> forward. My main comment concerns Section 2.4. I think it should be
>> deleted entirely. We should just not allow the definition of
>> conflicting options. Or if we do, we should say mutually incompatable
>> options MUST NOT be used together at the same time. If someone ends up
>> generating Trill packets with conflicting options, let the behavior be
>> undefined. Looking at Section 2.4, it seems that implementations may
>> end up having to do a lot of work to adhere to the rules -- and for
>> what ends?  We should just strongly discourage the use of conflicting
>> extensions, and when they happen, buyer beware. We should not
>> complicate implementations to handle cases that really shouldn't be
>> allowed to happen. That is IMO a bad tradeoff.
>
> While I think it would be unreasonable to forbid ever defining options
> that could conflict, prohibiting the simultaneous use of such options
> and stating that the results would be unspecified is reasonable. This
> would be consistent with other parts of the TRILL specification that
> make checking various frame constraints optional for transit RBridges
> to reduce the burden on such RBridges.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
>> Alternatively, if we ever decide we need to define a conflicting
>> extension, that is the time to define how to handle the two when they
>> occur together. We may find that the proposed rules in Section 2.4 end
>> up being wrong for those specific options anyway, in which case we
>> find ourselves in a bind.
>
>> Thomas

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Thomas Narten <[email-masked]>
Date: Thu, 01 Mar 2012 16:30:20 -0500

Hi Don.

>    are, the results are unspecified.

How about:

   Defining TRILL extensions or extension flags that conflict with
   each other would be undesirable. Should conflicting extensions
   appear in the same packet, the results would be unpredictable, if
   different implementations processed them in different orders. While
   rules could be defined to specify how to predictably process
   conflicting options, such rules could also limit implementation
   flexibility in order to handle scenarios that arguably shouldn't be
   allowed in the first place.

   Conflicting extensions SHOULD NOT be defined, but if they are,
   careful thought should be given as to whether and how to specify
   the handling of conflicting extensions.

Bottom line: we shouldn't define any, and hopefully we won't. But if
we ever do, that is the time to figure out what the rules make
sense. It may well be that even then the Best Answer may is "don't do
it, results are undefined"

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 01 Mar 2012 17:02:39 -0500

Proposed wording looks good to me! Thanks!

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 1 Mar 2012 16:58:02 -0500

Hi Thomas,

How about the following, which is your text with a minor change:

  Defining TRILL extensions or extension flags that conflict with
  each other would be undesirable. Should conflicting extensions
  appear in the same packet, the results would be unpredictable, if
  different implementations processed them in different orders. While
  rules could be defined to specify how to predictably process
  conflicting options, such rules would also limit implementation
  flexibility and could impose substantial processing burdens.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Mar 2012 18:34:15 -0400

There was substantial support for this document but one person had
objections. Some of those objections were resolved by the replacement
of Section 2.4, as discussed on this list, resulting in
draft-ietf-trill-rbridge-extension-03.txt. This document has achieve
rough working group consensus and its RFC publication will be request.

Thanks,
Donald

On Wed, Feb 1, 2012 at 2:31 PM, Erik Nordmark <[email-masked]> wrote:
>
> Last year we had a last call on draft-ietf-trill-rbridge-options, and
> that resulted in separating out the minimum set of flags and associated
> behavior into a this extensions document.
>
> The WG last call ends on Feb 15th.
> Please send comments (including ones that say you've read the document
> and it is fine) to the rbridge list.
>
>   Erik