[rbridge] trill-adj Section 5 comments

[Les Ginsberg (ginsberg)]

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Sunday, February 20, 2011 1:04 AM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Cc: isis mailing list
> Subject: trill-adj Section 5 comments
> 
> 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.

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??

> 
> 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 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
> 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.

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

> 
> 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."

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

> 
> > 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.

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
> 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