Subject: [Isis-wg] WG Last Call for draft-ietf-isis-extended-sequence-no-tlv-00

From: Christian Hopps <[email-masked]>
Date: Wed, 11 Dec 2013 14:58:21 -0500

Hi Folks,

We are starting a WG Last Call on the following draft. The LC is set to expire Friday, Janurary 3rd 2014.

IS-IS Extended Sequence number TLV

http://tools.ietf.org/html/draft-ietf-isis-extended-sequence-no-tlv

Thanks,
Chris & Hannes.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Dec 2013 04:19:25 +0000

I preface my remarks by noting that I have been a vocal critic of this work in the past - mainly in the context of its use in LSPs - which the authors have now removed. This makes the draft acceptable - but I do still have some remarks on its current content. The WG can decide whether these are substantive enough to require an updated version - I tend to think so.

*****************************
Section 2.1 penultimate paragraph says

" a replayed PSNP can cause unnecessary
   LSP flood in the network."

"the network" should be replaced by "a given link"
And the text applies to both CSNP and PSNP since the absence of an LSP entry in a CSNP can trigger the receiver to flood the missing LSP on that link.

**********************************
In looking at the text in Section 3 and Section 4 which is describing how the ESSN/PSN fields should be encoded I have some questions on legal values for ESSN/PSN.

Is 0 legal for PSN? Seems clearly not for ESSN but the text is not clear for PSN. Specifically, when PSN rolls over and we increment ESSN must the value 0 be skipped when updating the PSN i.e. is the following sequence legal:

ESSN:50 PSN:(2**32) - 1
ESSN:51 PSN: 0

Also, if for some reason the sender increments the ESSN BEFORE the PSN wraps, is the following sequence legal?

ESSN:50 PSN: 1
ESSN:51 PSN: 1

The current text suggests it is NOT legal ("PSN MUST be greater") but that seems clearly broken as PSN must reset in order to rollover.

I offer this suggestion as regards the acceptance rules - which I think are simpler yet enforce the intended requirement:

a)ESSN must be non-zero
b)The combined unsigned 96 bit value (where ESSN is the 64 MSBs) MUST be greater than the previously received value.

*****************************

In Section 4 I think the rules regarding the ESSN/PSN values are PDU independent and should be moved/combined with the text in Section 3

**************************************

Section 4.2.1

I do not like the term "DISs CSNP ESN TLV". The point being made is that ESN # history needs to be kept on a per adjacency/pdu type/level basis. It is true that in the case of LAN's only the DIS will send CSNPs, but if there is a DIS change I presume that the new DIS is free to start using an ESN # totally independent of what was used by its predecessor DIS. So the scope of the ESN # is always based on the originator of the PDU - not whether it is DIS or not DIS. (CSNPs on a LAN sent from a non-DIS will be ignored based on existing protocol rules)

*****************************************
Section 5

Although you say previously that use of the ESN TLV is optional, it is clear that in order to achieve the goals of the extension that once "verify mode" is enabled the TLV MUST be present in every IIH/SNP sent. Any single PDU sent without the ESN TLV becomes a potential replay candidate. Therefore, once you enter "verify" mode, is it OK to accept a PDU which does not have a ESN TLV? As written the draft would indicate yes - the TLV can be omitted at any time - but I don't think that achieves the goals. Prior to entering verify mode it is certainly OK to have presence of ESN TLV optional - but I think not after. Clarifying text is needed.

*****************************************************

References

ISO 10589 should be in the references - and it should replace the reference to RFC 1195 in the Introduction. (i.e., RFC 1195 reference is unnecessary as well as used incorrectly)

********************************************************

There is still some discussion of the relevance of this technology to LSPs. This is understandable and even necessary to (at a minimum) clearly articulate why the draft excludes the use of the TLV in LSPs. However I would find the discussion more palatable if it was confined to a single section (currently there is text in multiple sections) and the discussion emphasized the point that the duration of the disruption possible with replay attacaks using LSPs (even "inter-session") is "short-lived" - meaning it is sub-second in most cases and in all cases not significantly longer. I think that is a fair characterization based on the lengthy discussion which we had previously. It would also help to explain to newcomers why LSPs were excluded.

Thanx.

    Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
> Sent: Wednesday, December 11, 2013 11:58 AM
> To: [email-masked] list
> Cc: Hannes Gredler; Christian Hopps
> Subject: [Isis-wg] WG Last Call for draft-ietf-isis-extended-sequence-no-tlv-
> 00
> 
> Hi Folks,
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg