Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

[Alia Atlas <[e-mail]>]

Donald,

Could you please submit this ?

Thanks,
Alia

On Wed, Mar 14, 2018 at 8:32 PM, Donald Eastlake <[e-mail]> wrote:

> Hi Alvaro,
>
> Attached is a candidate -06 version of draft-ietf-trill-address-flush
> (my internal version 39) intended to resolve your comments. Also
> attached is a diff against the currently posted -05. Can you take a
> looks and see if your comments are satisfied?
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>
> On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake <[e-mail]> wrote:
> > Hi Alvaro,
> >
> > On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <[e-mail]>
> wrote:
> >> Alvaro Retana has entered the following ballot position for
> >> draft-ietf-trill-address-flush-05: No Objection
> >>
> >> ...
> >>
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> I have some non-blocking comments/questions:
> >>
> >> (1) Why are the 2 VLAN Block encodings needed?  More important, when
> should
> >> each be used?  Section 2.2 says that "All RBridges implementing the
> Address
> >> Flush RBridge Channel message MUST implement types 1 and 2, the VLAN
> types...",
> >> but I didn't see anything about the VLAN Block Only Case (2.1).  I'm
> wondering
> >> if there will be cases where the support won't match and the message
> will then
> >> be ineffective.
> >
> > I suppose some wording could be added but the idea is that the VLAN
> > Block Only Case is part of the basic message and always has to be
> > implemented, as opposed to the extensible list of TLV types. The
> > message is structured so that you can't use both the VLAN Block Only
> > Case and the extensible TLV structure to specify VLANs at the same
> > time. The VLAN Block Only Case is expected to be common and
> > corresponds more closely to deployed code.
> >
> >> (2) In the 2.2.* sections, the description of some of the TLVs says
> (when the
> >> Length is incorrect) that "...the Address Flush message MUST be
> discarded if
> >> the receiving RBridge implements Type x".  What if that type is not
> supported
> >> -- I would assume you still want to discard?  BTW, the Type 5
> description
> >> doesn't qualify dropping based on the type support.
> >
> > If the Type is not implemented, then how would you know that the
> > length is not valid? How would you currently code a length validity
> > check for types to be specified in the future as part of the
> > extensibility of the message? But, since there is a length field, you
> > can always skip over a TLV you don't understand. The qualification
> > based on type support should be there for Type 5 also. (Of course, in
> > the real world, I think inconsistent Address Flush message type
> > support in a TRILL campus will be very rare.)
> >
> >> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not
> discarding).
> >>  Is there an intended difference in the behavior?
> >
> > There is no intended difference between "ignoring" and "discarding" an
> > Address Flush message. (Types 1, 2, and 6 are the mandatory to support
> > types so there is no conditional on support.)
> >
> >> (3) Section 2 says that "Address Flush protocol messages are usually
> sent as
> >> multi-destination packets...Such messages SHOULD be sent at priority
> 6".  It is
> >> not clear to me whether unicast packets (mentioned later) should also
> have the
> >> same priority.
> >
> > Yes, probably throwing in "including unicast Address Flush messages"
> > would clarify.
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   [phone] (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  [e-mail]
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>
>