Subject: [Isis-wg] Fwd: review comments on draft-ietf-isis-fs-lsp-01

From: Alia Atlas <[email-masked]>
Date: Tue, 20 May 2014 17:42:49 -0400

[Adding ISIS WG and Adrian]

---------- Forwarded message ----------
From: Alia Atlas <[email-masked]>
Date: Tue, May 20, 2014 at 5:36 PM
Subject: review comments on draft-ietf-isis-fs-lsp-01
To: "[email-masked]" <[email-masked]>,
[email-masked]

As a standard part of my process for evaluating drafts before starting
IETF Last Call,
I do a review of the draft.  This is that review.

In general, this is a really clear and well written draft.  Thank you
for articulating the reasons and requirements so clearly and for
taking advantage of this opportunity to make the
backwards-incompatible changes.

This draft is in excellent shape and I will start the IETF Last Call
for it - but I do have a couple specific comments below.  These can be
handled during IETF Last Call and addressing any concerns raised
there.

Specific comments:

In Sec 11, could the following text be clarified?
" A list of the circuit scopes supported on this circuit and
  other non-circuit flooding scopes supported.

       R bit MUST be 0 and is ignored on receipt.

       In a Point-Point IIH L1, L2 and domain-wide scopes MAY
       be advertised.
       In Level 1 LAN IIHs L1 and domain-wide scopes MAY be advertised.
       In Level 2 LAN IIHs L2 and domain-wide scopes MAY be advertised.
"
For instance, does this mean that circuit scopes MAY be advertised?
In a Level 1 LAN IIHs, L1 scopes MUST NOT be advertised?

In the IANA section, do the registries for the sub-TLVs also need to
be extended?

Thanks,
Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 20 May 2014 23:11:54 +0000

(Resending - including WG and Adrian)

Alia -

Thanx for your comments.
Inline.

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Tuesday, May 20, 2014 2:37 PM
> To: [email-masked]; [email-masked]

An IIH is a circuit scoped PDU. It therefore is expected that if the new Scoped Flooding Support TLV is sent in an IIH that it would include the circuit scopes supported on that circuit. The language regarding L1, L2, domain-wide scopes explicitly specifies what scopes - in addition to circuit scopes - MAY be included in the three IIH PDU types. The expectation regarding circuit scope  is explicitly stated by the earlier sentence:

" A list of the circuit scopes supported on this circuit and  other non-circuit flooding scopes supported."

I think your point may be that it would be clearer to also include "circuit scopes" in the statement regarding each PDU type - something like:

<Begin revised text>
In a Point-Point IIH L1, L2, domain-wide, and circuit scopes MAY  be advertised.
In Level 1 LAN IIHs L1, domain-wide, and  circuit scopes MAY be advertised.
In Level 2 LAN IIHs L2, domain-wide, and circuit scopes MAY be advertised.
<End revised text>

If you think the revised text is clearer I have no objection.

> In a Level 1 LAN IIHs, L1 scopes MUST NOT be advertised?

Did you mean L2 scopes MUST NOT be advertised in an L1 LAN IIH? If so, yes that is the intent of listing the scopes which MAY be advertised in a given PDU. What is not specifically permitted is prohibited.

> In the IANA section, do the registries for the sub-TLVs also need to

The draft introduces 16 bit TLVs and 16 bit sub-TLVs - so if/when new sub-TLV registries associated w extended TLV codepoints (i.e. codepoint > 255) are required they will have to support 16 bit sub-TLV codepoints.   However, the existing sub-TLV registries (e.g. Sub-TLVs for TLV 22, 141, and 222) do NOT need to be extended. This is because those registries are associated with Standard TLVs and therefore the sub-TLV codepoints are restricted to be within the Standard sub-TLV range.

As we are not introducing any new sub-TLV registries in this document I think the existing language in the IANA section is appropriate. We could add a statement like:

"Future sub-TLV registries associated with Extended TLVs will support values in the range of 0 - 65535."

I am not sure that is necessary.

   Les

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 May 2014 19:29:39 -0400

Hi Les,

> If you think the revised text is clearer I have no objection.

I think it is clearer.

> Did you mean L2 scopes MUST NOT be advertised in an L1 LAN IIH? If so, yes that is the intent of listing the scopes which MAY be advertised in a given PDU. What is not specifically permitted is pro…

Could you please state that?  A big friendly MUST NOT clarifies things.

> I am not sure that is necessary.

Probably not needed, thanks.  I just wanted to be sure it hadn't been
overlooked.

Alia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 May 2014 00:05:48 +0000

Alia -

> Sent: Tuesday, May 20, 2014 4:30 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; [email-masked]; isis-
> [email-masked]; Adrian Farrel
> Subject: Re: review comments on draft-ietf-isis-fs-lsp-01
> 
> Hi Les,
> 
> > An IIH is a circuit scoped PDU. It therefore is expected that if the new
> Scoped Flooding Support TLV is sent in an IIH that it would include the
> circuit scopes supported on that circuit. The language regarding L1, L2,
> domain-wide scopes explicitly specifies what scopes - in addition to circuit
> scopes - MAY be included in the three IIH PDU types. The expectation
> regarding circuit scope  is explicitly stated by the earlier sentence:
> >
> > I think your point may be that it would be clearer to also include "circuit
> scopes" in the statement regarding each PDU type - something like:
> >
> > <Begin revised text>
> > Did you mean L2 scopes MUST NOT be advertised in an L1 LAN IIH? If so,
> yes that is the intent of listing the scopes which MAY be advertised in a
> given PDU. What is not specifically permitted is prohibited.
> 

If this is the direction we want to head, then I would suggest removing the text specifying what scope may be advertised in a given IIH from Section 11 and instead add some columns to the "LSP Flooding Scoped Identifier Registry" defined in the IANA section to indicate for each scope identifier whether it can be included in the "Scoped Flooding Support" TLV in a given IIH PDU. I can't format it easily here, but it would add three new columns:

Scoped Flooding Support Advertisement
P2P-IIH   L1 LAN IIH    L2 LAN IIH
-------------------------------------------
 Y/N             Y/N                      Y/N

This would allow the registry to update the definition of what could be advertised when new flooding scopes are invented.

I am hoping this can all be handled during the editing process and that a new version of the draft is not necessary.
Please let me know.

   Les

> > The draft introduces 16 bit TLVs and 16 bit sub-TLVs - so if/when new sub-
> TLV registries associated w extended TLV codepoints (i.e. codepoint > 255)
> are required they will have to support 16 bit sub-TLV codepoints.   However,
> the existing sub-TLV registries (e.g. Sub-TLVs for TLV 22, 141, and 222) do
> NOT need to be extended. This is because those registries are associated
> with Standard TLVs and therefore the sub-TLV codepoints are restricted to
> be within the Standard sub-TLV range.
> >
> > As we are not introducing any new sub-TLV registries in this document I
> think the existing language in the IANA section is appropriate. We could add
> a statement like:
> >

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 May 2014 20:39:56 -0400

Les,

Any way that makes it clear is fine. In the registry is a good idea.

I will need an updated  draft right after IETF Last Call is done.
This is for clarity - unwritten  MUST NOTs are a problem in a RFC.

Thanks,
Alia