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

["Les Ginsberg (ginsberg)" <[e-mail]>]

(Resending - including WG and Adrian)

Alia -

Thanx for your comments.
Inline.

> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]]
> Sent: Tuesday, May 20, 2014 2:37 PM
> To: [e-mail]; [e-mail]
> Subject: review comments on draft-ietf-isis-fs-lsp-01
> 
> 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?

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
> be extended?

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

> 
> Thanks,
> Alia