[rbridge] trill-adj Section 5 comments

[Les Ginsberg (ginsberg)]

Donald -

> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3 at gmail.com]
> Sent: Wednesday, March 02, 2011 8:26 AM
> To: Les Ginsberg (ginsberg); rbridge at postel.org
> Cc: isis mailing list
> Subject: Re: trill-adj Section 5 comments
> 
> Hi Les,
> 
> On Tue, Feb 22, 2011 at 4:39 PM, Les Ginsberg (ginsberg)
> <ginsberg at cisco.com> wrote:
> > 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??
> 
> Sorry I wasn't clear. In the example you state, I agree that it is of
> essentially no interest to RB3 that RB1 received an MTU-prove sent by
> RB2. However, the receipt of the MTU-ack by RB3 confirms that the path
> from RB1 to RB3 can accomodate a frame of the size of the MTU-ack. It
> is this information concerning the path from RB1 to RB3 that may be of
> interest to RB3, not anything to do with the path from RB2 to RB1.
> 
> >> 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.
> >
> > ??
> 
> While, as you say, the existence of Report state between two non-DRB
> neighbors does not affect any LSP, it is my understanding that it can
> affect actual forwarding behavior. For examle, assume three RBridges
> on a link: RBdrb, RBx, and RBy with mutual Report state adjacency
> between
> RBdrb and RBx and between RBdrb and RBy. RBdrb is the DRB and is
> reporting its adjacency to the pseudonode it created and RBx and RBy
> are reporting their adjacency to the pseudonode. Now assume that SPF
> calculates a route from somewhere through RBx to the psuedonode to RBy
> to someplace else. A packet bein routed along that route arrives at
> RBx. It is normally just forwarded directly to RBy. But it is my
> understanding that many implementation take note of the state of the
> adjacency between RBx and RBy. Of course, that adjacency should be in
> a good state and if it is not, something is screwed up on the link.
> Nevertheless, I understand that some implementation will, if they do
> not believe the adjacency between RBx and RBy is in a good state,
> forward the packet to the DRB/DIS instead as a saving move, since they
> have reasonable assurance that the adjacencies between RBx and RBdrb
> and between RBdrb and RBy are in good shape. It was for this reason
> that it seemed like a good idea to accurately determine the state of
> the adjacency between RBx and RBy.
> 
> >> 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?
> 
> See above.

I think that the points you make above only reinforce the point I am trying to make - that sending MTU probes to/from the DRB is sufficient for MTU testing. Clarifying this would be a good thing.

> 
> >> 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?
> 
> Yes, the revised wording from Mike Shand is in the current
> draft-ietf-trill-adj-03.txt. However, that current wording does not
> clarify this point so I think the wording should be augmented as
> above.

OK. I think the final sentence of your new text has been truncated ("link" is missing??).

> 
> >> > 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.
> 
> Sorry, my answer didn't include the case of multiple ports with the
> same MAC address. By the way, I think that having multiple ports with
> the same MAC address on a device is a bad thing, but some switch
> makers do that and TRILL certainly wants to be robust if that is done,
> even if more than one of these ports is on the same link.
> 
> Having such same MAC address ports on a link is no problem with
> bridges as spanning tree will turn all but one of the ports off (there
> is a port ID in BPDUs). But with a router, such as an RBridge, where
> frames are being sent and received using the MAC address of the port,
> you really can't have multiple ports with the same MAC address on a
> link simultaneously active. For proper handling of unicast TRILL Data,
> the TRILL protocol depends on only a single copy being received by the
> next hop RBridge by being unicast to that RBridge. If two ports with
> the same MAC were active, a duplicate copy would be created. In
> addition, if there were any bridges in the link, they could be
> confused by seeing frames with the same source address coming from
> different directions.
> 
> So the assumption has been that an RBridge can have multiple ports
> with the same MAC address on a link but that the use of all but one
> for TRILL Data or native traffic is suspended for as long as the
> RBridge can detect that this condition is continuing. Basically, an
> RBridge port that receives a TRILL Hello from another port on the
> same RBridge with the same MAC address, if that other port is higher
> priority to be DRB, suspends itself for the holding time in that
> Hello. When suspended, a port listens for TRILL Hellos, sends TRILL
> Hellos with an empty TRILL Neighbor TLV, does not send or repond to
> MTU PDUs, etc. This is actually another port state and I'll modify the
> state machine and Section 4.
> 

Your new requirements presume that the RB knows that it has multiple ports on the same LAN - but it isn't clear to me how an RB is guaranteed to know that. RFCTRill states in 4.4.4 that:

"RB1 detects this condition based on receiving TRILL-Hello messages
   with the same IS-IS pseudonode ID on multiple ports."

It is true that you have amended DRB election procedures to include the Port ID as a tiebreaker, but since the Port ID is not encoded in the LANID field there is no way for an RB to indicate which port has been elected - so the LANID field will always be identical as sent from all ports.

I think it is not always possible to differentiate between the pathological case where two RBs have the same MAC address and the non-pathological case of multiple local ports w the same MAC address. This is because port assignment is a local matter and not guaranteed to be unique among all RBs on the circuit. So if you are going to specify advertised neighbor suppression I think this needs to be done independent of whether it is a pathological or non-pathological case.

   Les

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