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

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

Alia -

> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]]
> Sent: Tuesday, May 20, 2014 4:30 PM
> To: Les Ginsberg (ginsberg)
> Cc: [e-mail]; [e-mail]; isis-
> [e-mail]; Adrian Farrel
> Subject: Re: review comments on draft-ietf-isis-fs-lsp-01
> 
> Hi Les,
> 
> On Tue, May 20, 2014 at 7:11 PM, Les Ginsberg (ginsberg)
> <[e-mail]> wrote:
> > (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.
> 
> I think it is clearer.
> 
> >> 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.
> 
> Could you please state that?  A big friendly MUST NOT clarifies things.

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


> 
> >>
> >> 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.
> 
> Probably not needed, thanks.  I just wanted to be sure it hadn't been
> overlooked.
> 
> Alia
> >    Les
> >
> >>
> >> Thanks,
> >> Alia