Subject: Re: [trill] Restarted WG last call on draft-ietf-trill-esadi-04

From: Donald Eastlake <[email-masked]>
Date: Mon, 3 Feb 2014 16:00:33 -0500

Hi,

I think the solution to this weakness is to give the originator of an
LSP fragment a head start in sending it when a CSNP or PSNP
effectively requests that action. I suggest some text like the
following:

   All the TRILL switches participating in an ESADI instance for some
   Data Label appear to ESADI to be adjacent. Thus the originator of any
   active ESADI-LSP fragment always appears to be on link and, to spread
   the burden of such response, could be the RBridge to respond to any
   ESADI-CSNP or PSNP request for that fragment. However, under very
   rare circumstances, it could be that some version of the LSP fragment
   with a higher sequence number is actually held by another ESADI
   RBridge on the link, so non-originators need to be able to respond
   eventually. Thus, when the receipt of a CSNP or PSNP causes the
   SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP
   fragment, action is as specified in [IS-IS] for the originating ESADI
   RBridge of the fragment; however, at a non-originating ESADI RBridge,
   in addition to setting the SRMflag, the lastSent timestamp [IS-IS] is
   also set to the current time minus

          mimumLSPTimeInterval * ( 100 - Random (Jitter) ) / 100

   (where minimumLSPTimeInterval, Random, and Jitter are as in [IS-IS]).
   This will delay and jitter the transmission of the LSP fragment by
   non-originators. This givies the originator more time to send the
   fragment and provides more time for such an originator transmitted
   copy to traverse the likely multi-hop path to non-originators and
   clear the SRMflag for the frament at non-originators.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Wed, Dec 18, 2013 at 6:03 PM, Donald Eastlake <[email-masked]> wrote:
> Hi Erik,
>
> See below:
>
> On Mon, Dec 16, 2013 at 6:40 PM, Erik Nordmark <[email-masked]> wrote:
>> On 12/15/13 11:21 AM, Donald Eastlake wrote:
>>> Hi Erik,
>>>
>>> On Fri, Dec 13, 2013 at 1:08 PM, Erik Nordmark <[email-masked]> wrote:
>>>> On 12/12/13 2:04 AM, [email-masked] wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> There is a weakness of ESADI-CSNP processing in the -04 version.
>>>>>
>>>>> Assume there are 3 RBridges (say RB1, RB2, and RB3) participating ESADI on
>>>>> the virtual link for VLAN-x, and RB2 is the DRB on that link. RB3 has a
>>>>> self-orignated LSP RB3-01 with SN(sequence number) 1, RB1 has a copy of
>>>>> RB3-01 but with a SN more than 1,
>>>>
>>>> Hongjun,
>>>>
>>>> Why would RB1 have a higher sequence number? Since RB3 originates that LSP
>>>> it is RB3 that controls the sequence numbers.
>>>> (Is this in some restart case where RB3 has rebooted?)
>>>
>>> I dunno what the most likely way for this condition to occur is but I
>>> believe it is a good general principal of protocol design that you
>>> should be able to start from an arbitrary initial state of the
>>> participants and show that, assuming no further traumas, the network
>>> will converge to a correct state. Maybe RB1 was part of a completely
>>> different TRILL campus which happens to include a node with the same
>>> nickname as RB3 and some bizarre events causes RB1 to be disconnected
>
> First, a correction: IS-IS works based on the System ID, not the
> nickname, so that should say "same System ID" above, not "same
> nickname".
>
>>> from its original TRILL campus and inserted into the three-node TRILL
>>> campus being described...
>>
>> That seems like an odd case and would result in surprises.
>>
>> If RB1 comes from a different planet (where nicknames and LSPs can be
>> duplicated) and happens to have a copy of RB3-01 with some SN, then we
>> definitely don't want that LSA to be shared with other routers. The RB3
>> on this planet should originate the RB3 LSAs.
>
> Well, this could be solved with IS-IS authentication which would
> probably result is RB1 being isolated from the new network I was
> hypothesizing. And when RB1 got re-keyed, I would imagine it would
> discard cached LSPs that were authenticated with old keying...
>
> However, assuming no authentication or the identical keying in both
> networsk, the general IS-IS mechanism to fix this is, as Hongjun says,
> that when an IS-IS router R receives an LSP fragment with sequence
> number SN and R believes its current sequence number is less than SN,
> it immediately originates a copy of the same fragment but with
> sequence number SN+! and updates its current sequence number to SN+!.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
>>    Erik
>>>>...

---

From: Jon Hudson <[email-masked]>
Date: Wed, 5 Feb 2014 23:05:07 -0800

Looks good to me beyond a few small typos.

nice and clear too, good stuff

On Mon, Feb 3, 2014 at 1:00 PM, Donald Eastlake <[email-masked]> wrote:

> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

-- 
"Do not lie. And do not do what you hate."