Subject: [rbridge] trill-adj Section 5 comments

From: Donald Eastlake <[email-masked]>
Date: Sun, 20 Feb 2011 01:04:05 -0800

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
 [email-masked]

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 22 Feb 2011 16:39:11 -0800

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Sunday, February 20, 2011 1:04 AM
> To: Les Ginsberg (ginsberg); [email-masked]
> Cc: isis mailing list
> Subject: trill-adj Section 5 comments
> 

If RB1 sends a multicast MTU-ACK in response to a Probe from RB2 - and the ACK is received by RB3 - what use can RB3 make of this? As you have stated the ACK confirms receipt by RB1 of a Probe from RB2. I don't think this information is useful to RB3 - which argues that ACKs should always be unicast. But as you allow multicast ACKs I am trying to understand why??

> I don't quite understand your comment.

If pseudo-node bypass is NOT set then - as you detail below - only neighbors to the pseudo-node will be advertised in non-pseudo-node LSPs - so the existence of Report state between two non-DRB neighbors isn't useful. Given that the invention of pseudo-node bypass was solely to minimize the number of LSPs generated I find it somewhat curious that you are unnecessarily profligate in the use of MTU PDUs.

??

> If MTU testing is enabled, then

Exactly my point. So why waste cycles sending MTU Probes between two non-DRBs?

>    and do not report any other adjacencies on the."

I thought you had previously agreed on revised wording based on Mike Shand's suggestion. Are you proposing to revise the (updated) text again?

> the source MAC address but normally I don't think it needs that.

Section 4.4.4 of RFCTrill allows that an RB can have multiple ports on a LAN which share the same MAC address. It therefore seems necessary to include PortID to correctly identify the sender.

   Les

> The