[rbridge] trill-adj Section 5 comments

[Donald Eastlake]

Hi Les,

On Mon, Mar 7, 2011 at 9:43 AM, Les Ginsberg (ginsberg)
<ginsberg at cisco.com> wrote:

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

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

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

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

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.

>   Les

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com