Subject: Re: [Isis-wg] trill-adj Section 5 comments

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 Mar 2011 11:25:55 -0500

Hi Les,

On Tue, Feb 22, 2011 at 4:39 PM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> 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
>>
>> 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.

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

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 7 Mar 2011 06:43:08 -0800

Donald -

> Sent: Wednesday, March 02, 2011 8:26 AM
> Subject: Re: trill-adj Section 5 comments
> 
> Hi Les,
> 

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.

> clarify this point so I think the wording should be augmented as

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

> 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

---

From: Radia Perlman <[email-masked]>
Date: Mon, 7 Mar 2011 15:38:09 -0800

Re: multiple ports with the same MAC address

This is a pathological case no matter whether it's the same RB with
multiple ports using the same MAC address, or two different RBs using
the same MAC address.

It confuses bridges, and makes it impossible when forwarding, to
specify which neighbor using that MAC address you want to forward a
packet to, so as Donald said, if you hear a Hello on a port that you
think you are using MAC address x, and the Hello is claiming MAC
address x, then the lower priority port defers (doesn't participate in
transmitting data), as long as it continues hearing such Hellos,
regardless of whether it thinks it is hearing its own Hellos or
someone else's Hellos.

Radia

On Mon, Mar 7, 2011 at 6:43 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Radia Perlman <[email-masked]>
Date: Mon, 7 Mar 2011 15:56:05 -0800

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 <[email-masked]> wrote:
> I don't quite understand your comment. If MTU testing is enabled, then
> the source MAC address but normally I don't think it needs that. The

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 11 Mar 2011 02:29:03 -0500

Hi Les,

On Mon, Mar 7, 2011 at 9:43 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:

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

Sorry, there was a lot of text above. I've ellided the less relevant
material and I believe that the remaining block is a significnat point
in favor of correctly determining the state of adjacencies to other
than the DRB on a LAN link. This would include MTU testing if enabled.
Do you believe I am mistaken?

> OK. I think the final sentence of your new text has been truncated

Yes, thanks, you are correct. I'll add that missing word.

>> >> An RBridge can figure out what port an MTU PDU came from by looking
>> >> st the source MAC address but normally I don't think it needs that.
>> >
> 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:
>
> 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.

Right, but the test above works, I believe. The LANID should be unique
for each link. All ports on the link will be sending Hellos with that
LANID. So, if you have only one port on the link, only that port will
be receiving Hellos with that LANID. If you have two or more ports on
the link, all of them will be receiving Hellos with that LANID. The
minimal case is a link with a single RBridge connected to it by two
ports. Even in that case, each port will be receiving Hellos from the
other with the same LANID.

But, as you point out below, the case of having duplicate MAC
addresses on a link is orthongonal to a particular RBridge having more
than one port on the link.

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

I agree. Receipt by a port of a TRILL Hello with an SNPA (source MAC)
equal to that of the receiving port needs to suspend the receiving
port, if the received Hello is of higher priority, regardless of
whether that Hello came from the same or a different RBridge.

Thanks,
Donald