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

From: [email-masked]
Date: Thu, 12 Dec 2013 18:04:26 +0800

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, RB2 does not have that LSP. Then upon
receiving RB2's CSNPs, (according the current ESADI protocol) RB3 will
multicast that LSP on the virtual link, but RB1 will not do that until it
receives that LSP from RB3. If RB1 has missed that LSP from RB3 for some
reason such as poor network quality occasionally, it will not tell RB3 to
update that LSP to a new SN even it receives CSNPs from RB2 and finds its
locally-stored LSP with a greater SN than RB2's. And that LSP with lower 
SN
will exist on RB2/RB3 for a long time until RB3 update that LSP again and
RB1 receives it sucessfully. 

It is not reasonable that RB3 found the problem but could only stay there 
quietly until it receives that LSP from RB1. 

So I think that problem, although only a corner problem, should be 
resolved.

Thanks,
Hongjun Zhai
---------------------------------------------
Add: No.68 Zijinghua Road, Yuhuatai District,
Nanjing City, R.P. China, 210012

Tel: +86 025 52877345
Email: [email-masked]
---------------------------------------------

Erik Nordmark <[email-masked]> 
发件人:  "trill" <[email-masked]>
2013-11-28 00:17

收件人
"[email-masked]" <[email-masked]>, Donald Eastlake <[email-masked]>
抄送

主题
[trill] Restarted WG last call on draft-ietf-trill-esadi-04

This WG last call is to gauge the consensus on the ESADI draft with the 
change to use the encoding from draft-ietf-isis-fs-lsp for the ESADI 
PDUs. That change (plus some editorial changes) are in 
draft-ietf-trill-esadi-04.

Last call runs until December 19.

Please send any comments to the list.

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 13 Dec 2013 10:08:01 -0800

On 12/12/13 2:04 AM, [email-masked] wrote:
> 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?)

    Erik

> RB2 does not have that LSP. Then upon
> locally-stored LSP with a greater SN than RB2's. And that LSP with lower SN
> *Erik Nordmark <[email-masked]>*

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 15 Dec 2013 14:21:12 -0500

Hi Erik,

On Fri, Dec 13, 2013 at 1:08 PM, Erik Nordmark <[email-masked]> wrote:
> Why would RB1 have a higher sequence number? Since RB3 originates that LSP
> it is RB3 that controls the sequence numbers.

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
from its original TRILL campus and inserted into the three-node TRILL
campus being described...

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

---

From: [email-masked]
Date: Mon, 16 Dec 2013 16:43:31 +0800

Hi Erik,

> (Is this in some restart case where RB3 has rebooted?)

Yes, if RB3 (and the DRB) rebooted and startup so fast that RB1 did not 
perceive that reboot, RB1 would not remove the LSPs orgiginated by 
RB3 from its link state database. Those LSPs might have higher sequence 
numbers than the new LSPs originated by RB3 after the reboot.

If RB1 missed those new LSPs for some reasons, according the current 
ESADI specification, it would not tell RB3 to update the sequence numbers 
of those LSPs, even it found the problem based on the DRB's CSNPs. 
Either the poor network quality or transient network congestion might
cause RB1 not to receive those new LSPs from RB3.

Thanks,
Hongjun Zhai

Tel: +86 025 52877345

2013-12-14 02:08

收件人
[email-masked]
抄送
Donald Eastlake <[email-masked]>, trill <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [trill] Restarted WG last call on draft-ietf-trill-esadi-04

Hongjun,

    Erik

SN

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 16 Dec 2013 15:40:58 -0800

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

   Erik

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Dec 2013 18:03:34 -0500

Hi Erik,

See below:

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

> 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

>>>...