[rbridge] [Isis-wg] trill-adj Section 5 comments

[Radia Perlman]

Re: Multicasting probe-ack

Yeah, actually, the original design was that the MTU ack would be
unicast.  I prefer it that way, but someone said they thought it would
be simpler for their implementation to be allowed to multicast the
ack.  I don't think it's a big deal either way.  I'd tend to ignore an
ack for a probe I didn't send, but as Donald said, there might be some
useful information gleaned from seeing an ack...so, I see no reason to
specify that an implementation MUST ignore the ack.

Radia

On Sun, Feb 20, 2011 at 1:04 AM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
> Response to some comments by Les Ginsberg:
>
>> Section 5
>> ---------
>
>> [TRILL] 4.3.2 states:
>
>> "The MTU-probe MAY be multicast to All-RBridges, or unicast to a
>> specific RBridge. The MTU-ack is normally unicast to the source of
>> the MTU-probe to which it responds but MAY be multicast to
>> All-RBridges."
>
>> How does the sender of the Probe/ACK determine whether to use
>> unicast or multicast destination address?
>
> It is an implementation choice. Probably multicast is good to use
> initially or testing a new MTU value to all your neighbors, basically
> whenever there is a large or indefinite number of desired
> responders. Unicast would be good to use if a single new station has
> appeared on the link and you just want to test MTU to that station
> without bothering others. That sort of strategy would seem to minimize
> the burden on the link. (See some suggested text further below.)
>
>> If an MTU-ACK is sent to multicast address what should the receivers
>> who did not initiate the probe do with the ACK? Ignore? Process?
>
> Receipt of such an MTU-ack confirms MTU but only one way from the
> sender, not to the sender. Whether that makes any difference is an
> implementation choice. If bidirectional MTU had previously been
> confirmed, perhaps an implementation would use such uni-directional
> confirmation to push out, by a bounded amount, the time until it next
> does a bi-directional MTU re-confirmation.
>
> Some text could be added, after the text you quote, such as:
>
>   "Use of multicast or unicast is an implementation choice. However,
>   the burden on the link is generally minimized by unicasting MTU-ack
>   frames and by multicasting MTU-probes when a response from all
>   other RBridges on the link is desired, such as when initializing or
>   re-confirming MTU, and unicasting MTU-probes when a response from a
>   single RBridge, such as one that has just been detected on the
>   link, is desired."
>
> Given that the MTU facility is new, it does not seem wise to be overly
> constraining at this point.
>
>> On a LAN should MTU probes only be sent to/from the DRB when
>> pseudo-node bypass is NOT set? It seems useless to do otherwise -
>> but this is not discussed.
>
> I don't quite understand your comment. If MTU testing is enabled, then
> it is a part of determining if an adjacency is in the Report state. It
> seems to me that whether or not the adjacency from a non-DRB RBridge
> to the DRB is in Report state is important whether or not the DRB is
> asserting bypass pseudonode.
>
> If bypass pseudo-node is set, then the RBridge's adjacency to the DRB
>   is not particularly special. It gets reported or not in the
>   RBridge's LSP, depending on whether that RBridge sees it as being
>   in the Report state, just like any other of the RBridge's
>   adjacencies on the link.
>
> If bypass pseudo-node is not set, then the DRB is reporting its
>   adjacency to the pseudo-node and reports, in the pseudo-node LSP,
>   adjacency to other RBridge on the link only if the DRB sees its
>   adjacency to the other RBridge as being in the Report
>   state. Similarly, the other RBridge only reports its adjacency to
>   the pseudo-node if it sees its adjacency to the DRB as in Report
>   state; and it does not report adjacencies to any other RBridges on
>   the link regardless of the state of its adjacency to them.
>
> The second case above is not clear from the current wording in Section
> 6. Perhaps the sentence
>
>   "If the DRB does not set the bypass pseudonode bit in its TRILL
>   Hellos, then (as in [IS-IS]) it sends LSPs on behalf of the
>   pseudonode, and all RBridges report only their adjacency to the
>   pseudonode."
>
> should be replaced with
>
>   "If the DRB does not set the bypass pseudonode bit in its TRILL
>   Hellos, then (1) the DRB reports in its LSP its adjacency to the
>   pseudonode, (2) the DRB sends LSPs on behalf of the pseudonode in
>   which it reports adjacency to all other RBridges on the link where
>   it sees that adjacency in the Report state, and (3) all other
>   RBridges on the link report their adjacency to the pseudonode if
>   they see their adjacency to the DRB as being in the Report state
>   and do not report any other adjacencies on the."
>
>> Also, don't you need PORT ID in the Probe Source/ACK Source in the
>> MTU PDU to fully identify the source/responder?
>
> An RBridge can figure out what port an MTU PDU came from by looking at
> the source MAC address but normally I don't think it needs that. The
> sender of an MTU-probe gets to encode things however they want into
> the Probe ID field in such a way that they can identify the resulting
> MTU-ack. The Probe ID field is opaque as far as the responder is
> concerned.  draft-ietf-isis-trill-05 says, concerning Probe ID: "For
> example, an IS creating an MTU-probe could compose this quantity from
> a port identifier and probe sequence number relative to that port."
>
>> ...
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
> _______________________________________________
> Isis-wg mailing list
> Isis-wg at ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>