Donald, Could you please submit this ?
Thanks, Alia On Wed, Mar 14, 2018 at 8:32 PM, Donald Eastlake <[email protected]> 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 +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > > On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake <[email protected]> wrote: > > Hi Alvaro, > > > > On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana <[email protected]> > 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 +1-508-333-2270 (cell) > > 155 Beaver Street, Milford, MA 01757 USA > > [email protected] > > _______________________________________________ > trill mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trill > >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
