Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.txt

From: Donald Eastlake <[email-masked]>
Date: Sun, 11 Dec 2016 00:19:13 -0500

Hi Joel,

Sorry for the delay but we have attempted to respond to your points in
version -09 of the draft. There were also changes unrelated to your
comments which are briefly described in
https://www.ietf.org/mail-archive/web/trill/current/msg07572.html

Additional changes in -09 including making "SHOULD" the implementation
requirement for methods 2 and 3.

Concerning the possible change to the Push Directory state machine, looking
at this it appears that changes by adding states would have to be more
extensive than I originally thought. In any case, in this version, some
explanatory text has been added in Section 2.3.2.

Please take a look when convenient.

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

On Sat, Apr 16, 2016 at 10:03 PM, Donald Eastlake <[email-masked]> wrote:

> Hi Joel,
>
> On Fri, Apr 15, 2016 at 11:46 PM, Joel M. Halpern <[email-masked]>
> wrote:
> > If by the connectivity check to the directory server, you mean the
> > underlying IS-IS routing reporting connectivity, then say that.
>
> OK.
>
> > While that
> > is not actually interchangeable with real connectivity, it is perfectly
> > reasoanble for the WG to deem it sufficient.  I think it would only take
> a
> > sentence or two to clarify for the reader that what is meant is apparent
> > topological connectivity, as distinct from verified communication.
>
> The phrase usually used in TRILL (See RFC 7780) is "data reachable".
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
> > Yours,
> > Joel
> >
> >
> > On 4/15/16 11:12 PM, Donald Eastlake wrote:
> >>
> >> Hi Joel,
> >>
> >> On Fri, Apr 15, 2016 at 11:51 AM, Joel M. Halpern <[email-masked]>
> >> wrote:
> >>>
> >>> Thank you Donald.  Points of agreement elided, some responses to try to
> >>> clarify my observations.  I will note that from your comments about
> 3.1,
> >>> I
> >>> believe my concerns, now moved to 3.7, are larger, as I had assumed
> that
> >>> the
> >>> magic was in some other protocol, and you now say it is not defined
> >>> there.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 4/15/16 11:23 AM, Donald Eastlake wrote:
> >>>>
> >>>>
> >>>> Hi Joel
> >>>>
> >>>> Thanks for your thorough review and comments. See below
> >>>>
> >>>> On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern <[email-masked]
> >>>>   <mailto:[email-masked]> wrote:
> >>>>
> >>> ...
> >>>
> >>>>> Major Issues:
> >>>>> In the state machine transitions in section 2.3.3
> >>>>> for push servers, it appears that if the event indicating that the
> >>>>> server is being shut down occurs while the server is already Going
> >>>>> Stand-By or Uncompleting, the transitions indicate that this
> >>>>> "going
> >>>>> down" event will be lost.  A strict reading of this would seem to
> >>>>> mean that the "go Down" event would need to recur after the
> >>>>> timeout
> >>>>> condition.  This would seem to be best addressed by a new state
> >>>>> "Going-Down" whose timeout behavior is to move to down state.
> >>>>
> >>>>
> >>>> I understand your point but "going down" and the like are called
> >>>> "events or conditions" in this draft, not just events.
> >>>> The problem with adding a single "Going-Down" state is that
> >>>> transition
> >>>> to that state would lose the information as to whether or not the
> >>>> Push
> >>>> Directory had been advertising that it was pushing complete
> >>>> information or not. The reason to remember this is that you would
> >>>> want
> >>>> to behave a differently if the "going down" condition was revoked
> >>>> before it completed. This information could be preserved in a
> >>>> Boolean
> >>>> pseudo variable but the current style of state machine in this draft
> >>>> avoids such pseudo variables and encodes all of the relevant push
> >>>> directory's state into the state machine state. Thus, I can see
> >>>> three
> >>>> possible responses to your comment:
> >>>>
> >>>> 1) Change wording to emphasize that these "events or conditions" can
> >>>> be conditions that cause a state transition some substantial time
> >>>> after they become true.
> >>>>
> >>>> 2) Add two new states: (1) going down - was complete; (2) going down
> >>>> -
> >>>> was incomplete.
> >>>>
> >>>> 3) Change the style of state machine to admit pseudo variables which
> >>>> can be set and testing as part of the state machinery.
> >>>>
> >>>> Option 1 is just some minor wording changes but adopting either
> >>>> options 2 or 3 involves more extensive changes so I would prefer to
> >>>> avoid them.
> >>>
> >>>
> >>>  From what I have seen, trying to build a state machine with conditions
> >>> rather than events is fraught with problems and tends to lead to errors
> >>> in
> >>> implementation.  It amounts to hiding pseudo-variables inside the
> states,
> >>> but not describing them.
> >>> Thus, I would much prefer solution 2, but it is of course up to the WG.
> >>
> >>
> >> Well, option 2 wouldn't be too hard. Option 3 would probably involve the
> >> most
> >> change.
> >>
> >>> ...
> >>>
> >>>>> Minor Issues:
> >>>>> In section 2.3.3 describing the state transitions for push
> >>>>> servers, there is an event (event 1) described as "the server was
> >>>>> Down but is now Up."  The state transition diagram describes this
> >>>>> as
> >>>>> being a valid event that does not change the servers state if the
> >>>>> server is in any state other than "Down." In one sense, this is
> >>>>> reasonable, saying that such an event is harmless.  I would
> >>>>> however
> >>>>> expect some sort of logging or administrative notification, as
> >>>>> something in the system is quite confused.
> >>>>
> >>>>
> >>>> Again, I see your point but it seems to me to be a matter of state
> >>>> machine style. Note that the "event" is described as a condition, so
> >>>> from that point of view, it is true anytime the state is other than
> >>>> Down. On the other hand, if you view it as strictly an event, you
> >>>> are
> >>>> left with the question of what to put at the intersection of a state
> >>>> and event in the table when it is impossible for that event to occur
> >>>> in that state. Some people note this with an "N/A" (not applicable)
> >>>> entry. In fact, previous TRILL state diagrams such as in RFC 7177
> >>>> use
> >>>> "N/A" so it would probably be simplest to change to that for
> >>>> consistency.
> >>>
> >>>
> >>> I think N/A would be good.
> >>
> >>
> >> OK.
> >>
> >>> ...
> >>>
> >>>>> Text in section 3.2.2.1 on lifetimes and the information
> >>>>> maintenance in section 3.3 imply that the clients and servers must
> >>>>> maintain a connection. Presumably, this is required already by the
> >>>>> RBridge Channel protocol, and I understand that we should not
> >>>>> repeat
> >>>>> the entire protocol here.  It would seem to make readers life MUCH
> >>>>> simpler if the text noted that the RBridge Channel protocol
> >>>>> requires
> >>>>> that there be a maintained connection between the client and the
> >>>>> server, and that these mechanisms leverage the presence of that
> >>>>> connection.
> >>>>
> >>>>
> >>>> The basic RBridge Channel protocol [RFC7178] is a datagram protocol
> >>>> rather than a connection protocol. So there is no guaranteed
> >>>> continuity of connection between RBridges that have previously
> >>>> exchanged RBridge Channel messages. But connection would only be
> >>>> lost
> >>>> if the network partitions since RBridge Channel messages look like
> >>>> data packets to any transit RBridges and will get forwarded as long
> >>>> as
> >>>> there is any route. Network partition is immediately visible in the
> >>>> link state database to the RBridges at both ends of an RBridge
> >>>> Channel
> >>>> exchange.  Section 3.7 provides that if a Pull Directory is no
> >>>> longer
> >>>> reachable (i.e., RBridge Channel protocol packets would no longer
> >>>> get
> >>>> through), then all pull responses from that Pull Directory MUST be
> >>>> discarded since cache consistency update messages can't get through.
> >>>> Perhaps a reference to Section 3.7 should be added to Section 3.3.
> >>>
> >>>
> >>> I don't think a reference to 3.7 is sufficient, although it is helpful.
> >>> If the protocol is a datagram protocol, and if it is important to
> discard
> >>> data from unreachable pull servers, then I think 3.7 NEEDS to say more
> >>> than
> >>> just ~if you happen to magically figure out you can't reach the server,
> >>> discard data it has given you.~  From the rest of the text, this is an
> >>> important and unspecified protocol mechanism.
> >>
> >>
> >> Figuring out whether/how you can reach other RBridges is a basic
> >> function of TRILL IS-IS based routing, not something "magical".
> >> Whenever their is a topology change, an RBridge MUST determine routes
> >> to all data reachable RBridges in the new topology. If there was an
> >> RBridge previously reachable but no longer reachable, as would be the
> >> case for all RBridges on the other side of a network partition, this
> >> MUST be noticed so that, for example, all MAC reachability information
> >> associated with each of the no longer reachable RBridges can be
> discarded.
> >> It does not seem like much of a stretch to believe that an RBridge would
> >> keep track of the Pull Directory or Directories it was using, each of
> >> which will be some other RBridge, and notice when a topology change
> >> makes any of them inaccessible. But I have no problem adding some
> >> wording to make this clearer.
> >>
> >>> ...
> >>> In the flooding flag and behavior, (long text elided) I don't think
> there
> >>> is
> >>> anything wrong with the intended behavior.  It is just that the very
> >>> brief
> >>> description of the FL flag leads the reader to an incorrect
> expectation.
> >>> Yes, it gets sorted out, but that is not good.  What I would suggest is
> >>> when
> >>> the flag is defined (with whatever name you choose) note that "for the
> >>> qtypes 2,3,and 4, the flag indicates that the server should flood its
> >>> response."
> >>
> >>
> >> We can work  on clarifying the wording.
> >>
> >> Thanks,
> >> Donald
> >> =============================
> >>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >>   155 Beaver Street, Milford, MA 01757 USA
> >>   [email-masked]
> >>
> >
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 Dec 2016 02:02:28 -0500

Thanks Donald.  I will look at it within the next few days.

Yours,
Joel

On 12/11/16 12:19 AM, Donald Eastlake wrote:
> <https://www.ietf.org/mail-archive/web/trill/current/msg07572.html>
>
> Concerning the possible change to the Push Directory state machine,
> looking at this it appears that changes by adding states would have to
> be more extensive than I originally thought. In any case, in this
> version, some explanatory text has been added in Section 2.3.2.
>
>  [email-masked] <mailto:[email-masked]>
>
> On Sat, Apr 16, 2016 at 10:03 PM, Donald Eastlake <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Joel,
>
>     On Fri, Apr 15, 2016 at 11:46 PM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > reasoanble for the WG to deem it sufficient.  I think it would only take a
>      Donald E. Eastlake 3rd   +1-508-333-2270 <tel:%2B1-508-333-2270> (cell)
>      [email-masked] <mailto:[email-masked]>
>
>     > Yours,
>     > Joel
>     >
>     >
>     >> On Fri, Apr 15, 2016 at 11:51 AM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>>
>     >> wrote:
>     >>>
>     >>> clarify my observations.  I will note that from your comments
>     about 3.1,
>     >>> I
>     >>> believe my concerns, now moved to 3.7, are larger, as I had
>     assumed that
>     >>> the
>     >>>> On Wed, Apr 13, 2016 at 4:47 PM, Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>     >>>>   <mailto:[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>
>     >>> ...
>     >>>
>     >>>>> Major Issues:
>     >>> implementation.  It amounts to hiding pseudo-variables inside
>     the states,
>     >>> but not describing them.
>     >>> If the protocol is a datagram protocol, and if it is important
>     to discard
>     >>> In the flooding flag and behavior, (long text elided) I don't
>     think there
>     >>> is
>     >>   [email-masked] <mailto:[email-masked]>
>     >>
>     >
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Dec 2016 18:36:24 -0500

Thank you Donald.  One major and a few minor points I noticed while 
reading.  This does look to have addressed all my major concerns, and 
most of my minor concerns.

Major:
     The QTYPE table in section 3.2.1 lists the values 3 and 4 as 
unused.  (This appears to have changed between versions 7 and 8. 
Possibly in an effort to address my earlier question about why these 
values were used.)  The  Pull Directory Forwarding text in section 
3.2.2.2 still explicitly assigns meanings and responses to QTYPEs 3 and 
4.  Either those values are to be used, in which case 3.2.1 needs to say 
so.  Or they are not to be used, and 2 is used for all the ARP-like 
behaviors.  In which case 3.2.2.2 needs to discuss this.

Minor:
     The text is now clear as to what the content is when frames are 
included in a query (3.2.1)  It would seem helpful to implementors if 
the motivation for distinguishing between type 2 and type 5 in the 
request, since the behavior is apparently decidable based on the frame 
content itself.

     In section 3.2.2.1 on the Response format, in discussing the SIZE 
field of the response record, the text refers to errors in the QUERY 
records and to subsequent QUERY records.  I presume that this was 
intended to say RESPONSE Record in each case?

     In bullet 1 of section 3.3, at the end, in describing the 
possibility of an all-entries flush (F, P, and N bits set), I think the 
text intends that the count must be 0 to trigger this behavior.  It 
would help to say that.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Dec 2016 20:23:36 +0000

Hi Joel,

Thanks for your prompt response. See below at <de>

-----Original Message-----
From: trill [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, December 12, 2016 6:36 PM
To: Donald Eastlake
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [trill] RtgDir review of draft-ietf-trill-directory-assist-mechanisms-07.txt

<de> Thanks.

Major:

<de> Sorry, 3.2.2.2 was overlooked when 3.2.2.1 was updated. This should be easy to fix.

<de> I do see a difference between QTYPE 2 and QTYPE 5.
	QTYPE 2 can be seen as saying to ignore the MAC destination address, look at the Ethertype, and process as an ARP, ND, or RARP packet (or reject if none of these).
	QTYPE 5 can be seen as saying to ignore the Ethertype and do various lookups and/or forwarding based on the MAC destination address.
	These seems like different services although I suppose you could guess heuristically which was wanted.

Minor:

<de3> OK. Something like my text above could be included.

<de> Yup. Looks like a copy and paste error that slipped by.

<de> OK. Seems fairly clear to me but it can't hurt to make it clearer.

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

> Please take a look when convenient.

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Dec 2016 15:26:35 -0500

Thanks.  That works for me.  I suspect the 3.2.1 / 3.2.2.2 disconnect 
was a skipped correction.

Yours,
Joel

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Dec 2016 02:05:26 -0500

Hi Joel,

Thanks.
A -10 version has been posted that is intended to incorporate these
improvements.

Donald

On Tue, Dec 13, 2016 at 3:26 PM, Joel M. Halpern <[email-masked]> wrote:
> Thanks.  That works for me.  I suspect the 3.2.1 / 3.2.2.2 disconnect was a
> skipped correction.
>
> Yours,
> Joel
>
>
>> Cc: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Re: [trill] RtgDir review of
>> draft-ietf-trill-directory-assist-mechanisms-07.txt
>>
>>         QTYPE 2 can be seen as saying to ignore the MAC destination
>> address, look at the Ethertype, and process as an ARP, ND, or RARP packet
>> (or reject if none of these).
>>         QTYPE 5 can be seen as saying to ignore the Ethertype and do
>> various lookups and/or forwarding based on the MAC destination address.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Dec 2016 13:00:09 -0500

Thanks.  Looks good to me.
Yours,
Joel