Re: [Isis-wg] draft-chunduri-isis-extended-sequence-no-tlv - other comments

[Donald Eastlake <[e-mail]>]

I have a concern about replayed IIHs within TRILL where it is
reasonable to believe that such a change could be universally deployed
or nearly so. I would like to see such a TLV available for at least
that purpose.

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

On Mon, Apr 2, 2012 at 2:33 AM, Les Ginsberg (ginsberg)
<[e-mail]> wrote:
> In a previous thread we have discussed the use of the proposed extension
> in LSPs.
>
> Here are the remainder of my comments on the draft:
>
> In regards to SNPs, the presence of replayed SNPs will cause unnecessary
> reflooding of LSPs but will not actually cause any change in the LSPDB
> of any router. The unnecessary flooding would be limited to the link on
> which the replayed SNPs appear. Because no actual LSPDB changes would
> occur as a result of replayed SNPs, this is the one usage which could be
> enabled in the presence of partial deployment.
>
> In regards to IIHs, replayed IIHs could cause adjacency flapping which
> could be very disruptive. The danger lies when not all systems on a link
> support the extension - which on multi-access links can lead to multiple
> DISs being elected and violations of the assumption of transitivity. For
> this reason, enablement cannot be safely done in the presence of legacy
> systems.
>
> Given the discussion in the draft about enhancements to provide routing
> protocols with a group key management protocol in the future, it is
> prudent to look at the value add of extended sequence #s in the presence
> of a group key management protocol. The cost of having router vendors
> and their customers implement, deploy, and support extended sequence #s
> must be weighed against the benefits.
>
> As discussed in an earlier thread, IS-IS already has a reliable
> mechanism to recover from replayed LSPs. I see no significant value in
> using this extension in LSPs - and there is significant risk of
> introducing prolonged inconsistency in the LSPDB of routers in the
> network if any legacy systems exist in the network or are introduced
> after the extension has been enabled. The negative consequences of
> having a legacy system are significant because, unlike authentication,
> extended sequence #s are always optional and the absence of the same do
> not prevent adjacency formation and LSP exchange.
>
> At this point the only significant potential value I see is in IIHs -
> and in the presence of a group key management protocol this would be
> limited to the period between key rollovers. Once the set of neighbors
> on a link is stable, there would be no opportunity to introduce
> disruption with replayed IIHs even if the authentication key is not
> changed, so the potential value add is limited to periods of instability
> without key rollover.
>
> If the draft is to go forward, I would like to see the use in LSPs
> removed from the draft and a more complete discussion of the
> benefits/consequences of using extended sequence numbers in IIHs/SNPs in
> the presence of a group key management protocol.
>
>   Les
>
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg