Subject: [Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Fri, 07 Apr 2017 13:31:09 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-isis-auto-conf-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a series of comments -- they don't add up to a DISCUSS, but I
think it is important that they are solved before publication.

(1) In Section 3.3. (Router-Fingerprint TLV), the format presented
doesn't actually show the "flags field", which is described in the text,
but it shows its contents.   The length is defined as "the length of the
value field", but the figure doesn't explicitly show the Value field.  It
is probably obvious that the flags field + Router Fingerprint = Value,
but it would be nice to be specific.

Suggestion: include the 1 octet "flags field" in the drawing -- if
needed, then show the detail (where the S and A bits are) in the
description of the field.

(2) What about the other bits in the Flag field, how should they be
registered in the future (if needed)?  Please ask IANA to define a
registry for them.

(3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs that
MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that
this TLV MUST NOT be included in an LSP with a non-zero LSP number.  What
should a receiving node do if any of those conditions are not true?

(4) s/3.4.3.  IS-IS System ID Duplication Detection and Resolution/3.4.3.
 IS-IS System ID Duplication Detection

(5) I thought the point of this document was for use in "unmanaged
deployments.  It allows IS-IS to be used without the need for any
configuration by the user."  But Section 3.5. (Additional IS-IS TLVs
Usage Guidelines) has recommendations for configuration options,
including manually configured adjacencies (which should not be allowed
according to Section 3.4.2. (Adjacency Formation)).  Isn't this against
the stated reasons for this document?

(6) Authentication is one of those features that could be manually
configured -- but the default is no authentication.  There's a
higher-than-usual risk of a node listening on the network (probably a
bigger problem for the user traffic), but also one that could listen to
the Hellos and purposefully trigger the duplicate resolution mechanism to
continuously run.  This risk should be highlighted in the Security
Considerations because it is newly introduced here. [Robert Sparks
pointed this risk out during his GenArt review.]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 7 Apr 2017 21:09:11 +0000

Alvaro -

Thanx for the review.
Inline.

> -----Original Message-----
> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 1:31 PM
> To: The IESG
> Cc: [email-masked]; Hannes Gredler; [email-masked];
> [email-masked]
> Subject: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> I have a series of comments -- they don't add up to a DISCUSS, but I think it is
> important that they are solved before publication.
> 
> (1) In Section 3.3. (Router-Fingerprint TLV), the format presented doesn't
> actually show the "flags field", which is described in the text,
> value field", but the figure doesn't explicitly show the Value field.  It is
> probably obvious that the flags field + Router Fingerprint = Value, but it
> would be nice to be specific.
> 
> Suggestion: include the 1 octet "flags field" in the drawing -- if needed, then
> show the detail (where the S and A bits are) in the description of the field.
> 
[Les:] Bing has the pen - I will let him respond - but I am OK with your suggestion.

> 
> (2) What about the other bits in the Flag field, how should they be registered
> in the future (if needed)?  Please ask IANA to define a registry for them.
> 
[Les:] I don't think a registry is needed. If an additional flag is required then a bis draft will be required.
This is no different than many other flags fields already defined in the protocol.
Note that this is different than (for example) the flags field in RFC 7794 since it is a fixed size.

> MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that this
> TLV MUST NOT be included in an LSP with a non-zero LSP number.  What
[Les:] Ignore on receipt. We can add an explicit statement.

>  IS-IS System ID Duplication Detection
[Les:] Agreed.

> configuration by the user."  But Section 3.5. (Additional IS-IS TLVs Usage
> Guidelines) has recommendations for configuration options, including
> manually configured adjacencies (which should not be allowed according to
> Section 3.4.2. (Adjacency Formation)).  Isn't this against the stated reasons
> for this document?
> 
[Les:] The mention of "manually configured adjacencies" is in the context of what the default metric should be for non-manual adjacencies.
We do not recommend manual configuration, but it is not illegal to do it.

> (6) Authentication is one of those features that could be manually configured
> -- but the default is no authentication.  There's a higher-than-usual risk of a
> node listening on the network (probably a bigger problem for the user
> traffic), but also one that could listen to the Hellos and purposefully trigger
> the duplicate resolution mechanism to continuously run.  This risk should be
> highlighted in the Security Considerations because it is newly introduced
> here. [Robert Sparks pointed this risk out during his GenArt review.]
>
[Les:] Let me know if the answer I provided to Robert suffices.

   Les

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 7 Apr 2017 21:25:32 +0000

On 4/7/17, 5:09 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

Les:

Hi!

…
> [Les:] I don't think a registry is needed. If an additional flag is required then a bis 

No.  That’s the point of specifying how others may request a flag in a registry: then they can go to IANA and not touch your document.

If I try to read between the lines…it sounds like you’re saying that the TLV would have no other use than for auto-configuration, so if any new flag is to be assigned it would necessarily have to modify this document.  Is that what you mean?

Honestly, I think it is just good practice to define how the remaining bits should be assigned/or not in the future.  But I’ll let the responsible AD make the call. ;-)

…
> [Les:] The mention of "manually configured adjacencies" is in the context of what 
> the default metric should be for non-manual adjacencies.

Would manual configuration unset the A flag because now the node is not acting in auto-configuration mode?   

I know some of this was discussed on the list before, but if partial manual configuration is allowed (and the A flag is still set), what prevents a manually configured router from setting the A flag and if the parameters (area, level, etc.) match, form an adjacency?  There was a discussion about not allowing non-auto-configured routers and auto-configured ones from becoming adjacent.

> [Les:] Let me know if the answer I provided to Robert suffices.

No.  I would have the same answer that he did: you should describe the new risk.  But let’s keep the discussion on that thread.

Thanks!

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 8 Apr 2017 00:49:14 +0000

Alvarao -

> Sent: Friday, April 07, 2017 2:26 PM
> To: Les Ginsberg (ginsberg); The IESG
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04:
> (with COMMENT)
> 
> > > registered in the future (if needed)?  Please ask IANA to define a registry
> for them.
> > >
> > [Les:] I don't think a registry is needed. If an additional flag is
> > required then a bis draft will be required.
> 
> No.  That’s the point of specifying how others may request a flag in a registry:
> then they can go to IANA and not touch your document.
> 
> If I try to read between the lines…it sounds like you’re saying that the TLV
> would have no other use than for auto-configuration, so if any new flag is to
> be assigned it would necessarily have to modify this document.  Is that what
> you mean?
> 
> Honestly, I think it is just good practice to define how the remaining bits
> should be assigned/or not in the future.  But I’ll let the responsible AD make
> the call. ;-)
> 

[Les:] There are other examples of flags fields in IS-IS:

RFC 5306 Section 3.2 Restart TLV
RFC 7981 Section 2 Router Capability TLV
draft-ietf-isis-segment-routing-extensions

We do not define an IANA registry for these - and I think with good reason.
These are NOT general purpose flags which anyone can make use of - they are directly tied to the functionality of the TLV/sub-TLV in which they appear. To add a flag means one is extending the feature described in the original specification - a bis draft is a MUST.

   Les

> > > Usage
> > > manually configured adjacencies (which should not be allowed
> > > according to Section 3.4.2. (Adjacency Formation)).  Isn't this
> > > against the stated reasons for this document?
> > >
> > [Les:] The mention of "manually configured adjacencies" is in the
> > context of what the default metric should be for non-manual adjacencies.
> I know some of this was discussed on the list before, but if partial manual
> configuration is allowed (and the A flag is still set), what prevents a manually
> configured router from setting the A flag and if the parameters (area, level,
> etc.) match, form an adjacency?  There was a discussion about not allowing
> non-auto-configured routers and auto-configured ones from becoming
> adjacent.
> 
> 
> > > configured
> > > -- but the default is no authentication.  There's a
> > > higher-than-usual risk of a node listening on the network (probably
> > > a bigger problem for the user traffic), but also one that could
> > > listen to the Hellos and purposefully trigger the duplicate
> > > resolution mechanism to continuously run.  This risk should be
> > > highlighted in the Security Considerations because it is newly
> > > introduced here. [Robert Sparks pointed this risk out during his
> > > GenArt review.]
> > >
> No.  I would have the same answer that he did: you should describe the new
> risk.  But let’s keep the discussion on that thread.
> 
> Thanks!
> 
> Alvaro.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 10 Apr 2017 09:28:06 +0000

Hi Alvaro and Les,

Thanks for your comments.

> needed, then show the detail (where the S and A bits are) in the description of the field.
> 

No problem, I'll do it in the next version.

Best regards,
Bing

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Saturday, April 08, 2017 5:09 AM
> To: Alvaro Retana (aretana); The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Alvaro Retana's No Objection on
> draft-ietf-isis-auto-conf-04: (with COMMENT)
> 
> Alvaro -
> 
> Thanx for the review.
> Inline.
> 
> > Cc: [email-masked]; Hannes Gredler;
> > [email-masked]; [email-masked]
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > value field", but the figure doesn't explicitly show the Value field.
> > It is probably obvious that the flags field + Router Fingerprint =
> > Value, but it would be nice to be specific.
> >
> > needed, then show the detail (where the S and A bits are) in the description
> of the field.
> >
> > (3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs
> > that MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says
> > that this TLV MUST NOT be included in an LSP with a non-zero LSP
> > number.  What should a receiving node do if any of those conditions are
> not true?
> >
> > manually configured adjacencies (which should not be allowed according
> > to Section 3.4.2. (Adjacency Formation)).  Isn't this against the
> > stated reasons for this document?
> >
> [Les:] The mention of "manually configured adjacencies" is in the context of
> what the default metric should be for non-manual adjacencies.
> > -- but the default is no authentication.  There's a higher-than-usual
> > risk of a node listening on the network (probably a bigger problem for
> > the user traffic), but also one that could listen to the Hellos and
> > purposefully trigger the duplicate resolution mechanism to
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg