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

[Donald Eastlake <[e-mail]>]

Hi Mike,

Thanks for the review and comments. See below.

On Tue, Mar 6, 2012 at 6:11 AM, Mike Shand <[e-mail]> wrote:
> 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

OK.

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

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.

> This may be clearer if you put the "As a result..." sentence before the
> "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.

> 2.4.2.1 An Example Network para 2
>
> TYPO "has such a neighbor that signal it is willing" ->  signals (or has
> signalled)

OK.

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

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

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

Thanks again,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Mike
>
>
>
>
>
>
> On 06/03/2012 04:25, Donald Eastlake wrote:
>>
>> 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   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isis-wg
>
>

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge