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

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

On 12/16/13 12:43 AM, [email-masked] wrote:
> 
> Hi Erik,
> 
>  > 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?)
> 
> 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.

Hongjun,

But don't we need to somehow ignore those LSPs? Even though they have a
higher SN than the newly generated LSPs from RB3 they are stale in that
they contain information that is older.

Thus making sure that other RBs receive those higher SN LSAs seems to be
the opposite of that we want to do.

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

How does IS-IS handle the restart case? Does it rely on flushing all the
LSPs when a new adjacency is established after a restart? Or does it
solely rely on the sequence numbers?

   Erik

> 
> 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-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
> 
> 
> 	
> 
> 
> 
> 
> 
> 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?)
> 
>     Erik
> 
>  > 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
>  >
>  >
>  >
>  > _______________________________________________
>  > trill mailing list
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/trill
>  >
> 
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: hongjun ZHAI <[email-masked]>
Date: Wed, 18 Dec 2013 00:11:54 +0800

Hi Erik,

> they contain information that is older.

For two copies of a LSP, the one with higher SN is generally considered
newer than the one with smaller SN;  so when RB1 receives the newly
generated LSPs from RB3, it would not treat them as new ones as it has
the copies with higher SN than the received ones. So I think those stale
LSPs should be updated rather than be ignored.

> the opposite of that we want to do.

It is only a transient state for other RBs to have those stale LSPs
even RB1 multicast those LSPs on the virtual link when it found the problem
based on the DRB's CSNPs.

When being informed of those stale LSPs by RB1 via some means, RB3 could
know the sequence numbers it had used for those LSPs before its restarting,
then it would update those LSPs with greater sequence numbers. That update
can make those LSPs sychronized among the ESADI instances resided on the
virtual link. Then those instances can converge quickly to a correct state
from the wrong state that was caused by RB3's restarting.

> LSPs when a new adjacency is established after a restart?

In my mind, when an IS-IS router R1 startups from its restarting, its
adjancent neighbors will help it to get the SNs for the LSPs that it still
originates after that restarting. No matter based on receiving R1's newly
originated LSPs or the DIS's CSNPs, when the neighbors find they have
copies with higher SNs than the R1's newly originated ones, they would
multicast their ones with higher SNs. R1 would update those LSPs with
higher SNs and multicast them to its neighbors after it knows the SNs it
had used before its restarting.

> Or does it solely rely on the sequence numbers?

No, it does not. But the SN has a higher preference than other parameters
to determine which one of the copies of a LSP is newer.

Thanks,
Hongjun Zhai
-----------------------------------------------------------------------------
Yuhuatai District, Nanjing City, People's Republic of China
Mobile: +086-139-5108-4536
Email: [email-masked]
-----------------------------------------------------------------------------

On Tue, Dec 17, 2013 at 7:45 AM, Erik Nordmark <[email-masked]> wrote:

> >       Donald Eastlake <[email-masked]>, trill <[email-masked]
> >,