Subject: [Isis-wg] draft-ietf-trill-clear-correct-00

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Mar 2012 23:25:24 -0500

Participant in the ISIS WG my want to look at this draft, which is
currently in WGLC in the TRILL WG as it has some IS-IS aspects:
https://datatracker.ietf.org/doc/draft-ietf-trill-clear-correct/

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

---

From: Mike Shand <[email-masked]>
Date: Tue, 06 Mar 2012 11:11:05 +0000

Hi Donald,

I had a quick skim through this and noticed the following, which you may 
wish to address.

2. Overloaded and/or Unreachable RBridges para 3

TYPO "They can do reasonable well" ->  reasonably

2.1 Reachability para 3

"which could be tens of seconds or longer."

The default value for MaxAge in ISO/IEC 10589 is 20 minutes (1200 
seconds), so "tens of seconds" is something of an underestimate, unless 
TRILL is proposing running with a MUCH smaller value of MaxAge (and 
hence maximumLSPGenerationInterval).

It is confusing to have the statement that "As a result, RB1 will be 
aware of the partition." after the statement that the stale LSPs will 
hang around for a long time, since it sounds as if this very delay is 
the cause of the knowledge of the partition. I THINK what you are trying 
to say is that it doesn't matter that you don't receive the new LSPs 
from the far side of the partition, since you WILL receive the updated 
LSPs from the nodes adjacent to the failure(s) on the near side of the 
partition, and this is sufficient to determine the lack of connectivity.

This may be clearer if you put the "As a result..." sentence before the 
"However, LSPs held..." sentence.

Or perhaps I am completely misunderstanding the point you are making.

2.4.2.1 An Example Network para 2

TYPO "has such a neighbor that signal it is willing" ->  signals (or has signalled)

5.2 Ethernet MTU Values para 1

"originatingL1LSPBufferSize is the maximum permitted size of LSPs after the eight byte fixed IS-IS PDU header."

I don't know where this idea came from but it is not correct.
originatingL1LSPBufferSize refers to the size of the entire LSP starting with the protocol discriminator.

I suspect this may be an erroneous deduction from the fortuitous fact that adding 8 to 1492 gives 1500.

In fact the 1492 is a relic of the origins of ISO/IEC 10589 in DECnet Phase V, where before its adoption as a standard,
the frames were encoded using the SNAP SAP, which necessarily limited the maximum available payload to 1492.
This length was never changed when the encoding was changed, although it could have been made 1497.

Mike

On 06/03/2012 04:25, Donald Eastlake wrote:
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Mar 2012 13:44:16 -0500

Hi Mike,

Thanks for the review and comments. See below.

> TYPO "They can do reasonable well" ->  reasonably

OK.

> The default value for MaxAge in ISO/IEC 10589 is 20 minutes (1200 seconds),
> so "tens of seconds" is something of an underestimate, unless TRILL is
> proposing running with a MUCH smaller value of MaxAge (and hence
> maximumLSPGenerationInterval).

I'll change seconds to minutes. I think the existing text was written
erroneously thinking about 30 or 40 second holding times.

> It is confusing to have the statement that "As a result, RB1 will be aware
> of the partition." after the statement that the stale LSPs will hang around
> for a long time, since it sounds as if this very delay is the cause of the
> knowledge of the partition. I THINK what you are trying to say is that it
> doesn't matter that you don't receive the new LSPs from the far side of the
> partition, since you WILL receive the updated LSPs from the nodes adjacent
> to the failure(s) on the near side of the partition, and this is sufficient
> to determine the lack of connectivity.

Right.

> "However, LSPs held..." sentence.

Yes, it reads much better that way.

> Or perhaps I am completely misunderstanding the point you are making.

Nope, you have it right.

> TYPO "has such a neighbor that signal it is willing" ->  signals (or has

OK.

> adding 8 to 1492 gives 1500.

Precisely.

> In fact the 1492 is a relic of the origins of ISO/IEC 10589 in DECnet Phase
> V, where before its adoption as a standard,

OK. I'll correct the definition and adjust the numbers appropriately.

Thanks again,
Donald