Subject: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04

From: Christian Hopps <[email-masked]>
Date: Tue, 17 Jan 2017 07:00:39 -0500

Hi Folks,

We are starting a WG Last Call for

  "ISIS Auto-Configuration"
  - https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/

The WGLC will expire in 2 weeks on Jan 31, 2017.

Thanks,
Chris & Hannes.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 22 Jan 2017 13:39:06 +0000

Hi IS-IS WG, 

I have reviewed the document and support publication. I have the following
minor comments:

    1. It should be made clear that the A-Bit indicates that an IS-IS
router supports auto-configuration and, is not, necessarily
auto-configured itself. After reading the whole draft, I know that this is
the definition of the bit but the initial text says the router is
³operating in auto-configuration mode.²
    2. In the duplicate detection in section 3.4.3, could you note that an
IS-IS router should be able to detect discern the case where two
interfaces on the IS-IS router performing auto-configuration are connected
to the same network.

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 22 Jan 2017 17:57:30 +0000

Acee -

Thanx for reviewing the document.
Responses inline.

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of Acee Lindem
> (acee)
> Sent: Sunday, January 22, 2017 5:39 AM
> To: Christian Hopps; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-auto-conf-04
> 
> Hi IS-IS WG,
> 
>     1. It should be made clear that the A-Bit indicates that an IS-IS router
> supports auto-configuration and, is not, necessarily auto-configured itself.
> After reading the whole draft, I know that this is the definition of the bit but
> the initial text says the router is ³operating in auto-configuration mode.²

[Les:] It is clearly stated that the A flag does indeed mean 

" the router is operating in auto-configuration mode."

I do not see any text which suggests otherwise.

???

>     2. In the duplicate detection in section 3.4.3, could you note that an IS-IS
> router should be able to detect discern the case where two interfaces on the
> IS-IS router performing auto-configuration are connected to the same
> network.
> 
[Les:] Multiple connections of the same system to the same network can occur in the absence of auto-configuration and detection of this case is not altered by auto-configuration. This is detected by receiving a hello with the same source MAC address as a local interface. There are then the following cases:

1)Two interfaces on the local router are connected to the same media. This is further validated by having the same systemID. The means for detecting this as well as resolving this are not altered by auto-configuration.

2)Two neighbors connected to the same network have the same source MAC address. This is distinguished by having different system IDs in the hellos. The means for detecting this as well as resolving this are not altered by auto-configuration.

3)Two neighbors connected to the same network have the same source MAC address and the same systemID. This is distinguished by having different router fingerprint TLVs in the hellos - something only an auto-config router could do. But the additional detection capability does not provide any additional means to correct this issue.

The authors discussed this point during the writing of the draft and decided specifically NOT to comment on this issue as it by nature is no different than what can occur without auto-config and there is no good way to automatically recover from this case i.e. clearly we cannot alter the physical connections by programmatic means - nor do we assume/require a programmatic capability of assigning MAC addresses.
 
So, I am not sure what we could say other than to note that this can occur - but non-auto-config implementations already have to detect this - so does it make sense to comment on this in the auto-config draft?

   Les

> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 22 Jan 2017 23:56:17 +0000

Hi Les, 

On 1/22/17, 12:57 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>router

But there is no prior definition of “auto-configuration mode”. I think
most readers would believe that this indicates that only routers
performing auto-configuration will form adjacencies. Yet the documents
states: 

   This document also defines mechanisms to prevent the unintentional
   interoperation of auto-configured routers with non-autoconfigured
   routers.  See Section 3.3.

Where is the interoperation? This definitely needs to be clarified - I
don’t see how the authors can argue on this point!

>[Les:] Multiple connections of the same system to the same network can
>occur in the absence of auto-configuration and detection of this case is
>not altered by auto-configuration. This is detected by receiving a hello
>with the same source MAC address as a local interface. There are then the
>following cases:
>
>1)Two interfaces on the local router are connected to the same media.
>This is further validated by having the same systemID. The means for
>detecting this as well as resolving this are not altered by
>auto-configuration.
>
>2)Two neighbors connected to the same network have the same source MAC
>address. This is distinguished by having different system IDs in the
>hellos. The means for detecting this as well as resolving this are not
>altered by auto-configuration.
>
>3)Two neighbors connected to the same network have the same source MAC
>address and the same systemID. This is distinguished by having different
>router fingerprint TLVs in the hellos - something only an auto-config
>router could do. But the additional detection capability does not provide
>any additional means to correct this issue.
>
>The authors discussed this point during the writing of the draft and
>decided specifically NOT to comment on this issue as it by nature is no
>different than what can occur without auto-config and there is no good
>way to automatically recover from this case i.e. clearly we cannot alter
>the physical connections by programmatic means - nor do we assume/require
>a programmatic capability of assigning MAC addresses.
> 
>So, I am not sure what we could say other than to note that this can
>occur - but non-auto-config implementations already have to detect this -
>so does it make sense to comment on this in the auto-config draft?

Given that consequences of this mis-wiring are more severe when IS-IS
auto-configuration is being used, I think this deserves at least the
discussion above included in the draft.

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 23 Jan 2017 00:36:04 +0000

Acee -

> From: Acee Lindem (acee)
> Sent: Sunday, January 22, 2017 3:56 PM
> To: Les Ginsberg (ginsberg); Christian Hopps; [email-masked]
> >> I have reviewed the document and support publication. I have the
> >>following  minor comments:
> >>
> >>auto-configured itself.
> >> After reading the whole draft, I know that this is the definition of
> >>the bit but  the initial text says the router is ³operating in
> >>auto-configuration mode.²
> >
> But there is no prior definition of "auto-configuration mode". I think most
> readers would believe that this indicates that only routers performing auto-
> configuration will form adjacencies. Yet the documents
> states:
> 
> Where is the interoperation? This definitely needs to be clarified - I don't see
> how the authors can argue on this point!
[Les:] Section 3.4.2.  Adjacency Formation

 "  Routers operating in auto-configuration mode MUST NOT form
   adjacencies with routers which are NOT operating in auto-
   configuration mode.  The presence of the Router Fingerprint TLV with
   the A bit set indicates the router is operating in auto-configuration
   mode."

I do not see that anything further is needed.
??

> 
> >
> >???
> >
> >>     2. In the duplicate detection in section 3.4.3, could you note
> >>that an IS-IS  router should be able to detect discern the case where
> >>two interfaces on the  IS-IS router performing auto-configuration are
> >>connected to the same  network.
> >>
> >occur in the absence of auto-configuration and detection of this case
> >is not altered by auto-configuration. This is detected by receiving a
> >hello with the same source MAC address as a local interface. There are
> >then the following cases:
> >
> >address and the same systemID. This is distinguished by having
> >different router fingerprint TLVs in the hellos - something only an
> >auto-config router could do. But the additional detection capability
> >does not provide any additional means to correct this issue.
> >
> >way to automatically recover from this case i.e. clearly we cannot
> >alter the physical connections by programmatic means - nor do we
> >assume/require a programmatic capability of assigning MAC addresses.
> >
> >occur - but non-auto-config implementations already have to detect this
> >- so does it make sense to comment on this in the auto-config draft?
> 
> Given that consequences of this mis-wiring are more severe when IS-IS auto-
> configuration is being used, I think this deserves at least the discussion above
> included in the draft.
> 
[Les:] I do not see that this issue is any more/less severe when operating in autoconfig mode.
Manual intervention is required to resolve the issue regardless of mode - the protocol cannot heal itself in this case. All we can do is send out a notification and be smart in the implementation so as to avoid constant adjacency churn. This behavior is required/recommended regardless of autoconfig mode. In fact, it could be argued the problem is more severe for larger networks as the side effects of churn associated with sub-optimal handling of this problem will be far worse in a large network.

Interestingly, I do not even see a notification defined for this condition in the MIB (RFC 4444) - perhaps we will do better when defining the YANG data model. :-)

This is perhaps a problem worth discussing - but I don't see that it is in any way unique to or related to autoconfig - so adding it to this specification doesn't seem appropriate.

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Jan 2017 19:45:08 +0000

Les 

On 1/22/17, 7:36 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>most

The problem is that there is no prior definition of auto-configuration
mode. Hence, one could interpret the above text as only allowing
adjacencies between auto-configured routers. This directly contradicts the
interoperability with non-autoconfigured routers.

>>auto-
>Manual intervention is required to resolve the issue regardless of mode -
>the protocol cannot heal itself in this case. All we can do is send out a
>notification and be smart in the implementation so as to avoid constant
>adjacency churn. This behavior is required/recommended regardless of
>autoconfig mode. In fact, it could be argued the problem is more severe
>for larger networks as the side effects of churn associated with
>sub-optimal handling of this problem will be far worse in a large network.
>
>Interestingly, I do not even see a notification defined for this
>condition in the MIB (RFC 4444) - perhaps we will do better when defining
>the YANG data model. :-)
>
>This is perhaps a problem worth discussing - but I don’t see that it is
>in any way unique to or related to autoconfig - so adding it to this
>specification doesn’t seem appropriate.

With the respect to this being a problem in any mode, I agree. One
motivation for at least having a statement in this draft is that it
specifically addresses duplicate System-ID handling and I’m not sure
whether that is addressed in any other IS-IS specifications. However, I
don’t feel that strongly. Here is what we had in RFC 7503:

 An OSPFv3 router implementing this specification should ensure that
 the inadvertent connection of multiple router interfaces to the same
 physical link is not misconstrued as detection of an OSPFv3 neighbor
 with a duplicate Router ID.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Jan 2017 21:27:00 +0000

Les, et al, 
I see now that the intention was to “prevent” adjacencies between
auto-configured and non-autoconfigured IS-IS routers. Hence, I am fine
with this version of the document.
Thanks,
Acee

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 30 Jan 2017 09:25:45 -0800

Hello draft authors, Christian and Hannes,

the authors have done a fine job with the document since 
"draft-liu-isis-auto-conf" and it contains (IMHO) enough material to create a 
standard document.

My problem with the draft (still) is: the auto-generation of the system ID 
has a flaw. The draft even admits this in section 3.4.6. "Double-Duplication 
of both System ID and Router-Fingerprint" when it states

   In the pathological case the generation of a new version of an LSP by
   one of the "twins" will cause the other twin to generate the same LSP
   with a higher sequence number - and oscillation will continue without
   achieving LSPDB synchronization.

The draft is inspired by RFC7503 but does not realize that RFC7503 de-facto 
says "you need to have a unique router fingerprint". Period. Instead the 
draft tries to solve the situation when system ID and fingerprint are not 
unique, which is going in a circle as the fingerprint's main purpose is to 
make LSPs distinguishable due to it's uniqueness.

I'm sure some implementations exists and tests have been done but the 
algorithm described in the draft has effectively a race condition. You don't 
see them in lab tests but once it has been deployed widely enough you will 
hit it (well, the customers will).

The main problem to me seems a lack of ideas how to generate a unique 
fingerprint. Hardware-based information are an obvious choice but not the 
only way to have unique information. Today we don't use classic ROM anymore, 
it's typically a flash memory, so even when the hardware has no serial 
number, no burned-in MAC etc. you can still store a unique serial number (per 
manufacturer) on the flash while the software is programmed into the flash.

One question to the authors: as we want to solve the situation where no 
burned-in MAC address exists, are you okay with the possibility that multiple 
IS-IS speakers using the same source MAC address at the same time ?  Assuming 
that the system ID and the MAC are kept in-sync this is likely covered by 
section 3.4.3 "IS-IS System ID Duplication Detection and Resolution" ?  
Should this be mentioned somewhere?

Another comment to the authors, chairs and WG: what the creation of unique 
6-byte system IDs is doing is creating unique MAC addresses for hardware with 
no burned-in address - another reason why the draft is relevant and 
standard-worthy in my opinion.

To summarize: I'm not happy standardizing the draft with the described 
algorithm. But I do support the draft's overall goal and think it's relevant 
and should be standardized.

Regards, Marc

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 31 Jan 2017 05:47:18 +0000

Marc -

Thanx for the thoughtful review.
Inline.

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Monday, January 30, 2017 9:26 AM
> To: Christian Hopps; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> the authors have done a fine job with the document since "draft-liu-isis-
> auto-conf" and it contains (IMHO) enough material to create a standard
> document.
> 
> 
> My problem with the draft (still) is: the auto-generation of the system ID has
> a flaw. The draft even admits this in section 3.4.6. "Double-Duplication of
> both System ID and Router-Fingerprint" when it states
> 
[Les:] It seems you have misunderstood Section 3.4.6. This section is NOT pointing out a limitation of the solution proposed - it is pointing out the need to distinguish the "benign" case of "double duplication that will occur because a restarting router may receive stale copies of its own LSPs from its previous incarnation and the actual "pathological" case where two different routers actually do have the same system ID and fingerprint TLV. It then goes to specify logic on how to distinguish these cases.

If we failed to distinguish these cases every time a router restarted within LSP Maxage interval it would needlessly modify its systemID/fingerprint simply because it received a stale copy of one of its own LSPs. We want to avoid that and have defined a procedure to do so.

> unique, which is going in a circle as the fingerprint's main purpose is to make
> LSPs distinguishable due to it's uniqueness.
>
[Les:]System ID uniqueness is a requirement of the base protocol specification The draft also specifies (Section 3.3) that the fingerprint MUST be unique. I do not see any circularity.

I am quite willing to admit that the authors of RFC 7503 may be smarter than me (though not necessarily smarter than my co-authors :-) ) - but I do not see that the substance of what is defined in the two documents differs. Both documents require detection of router/system ID duplication as well as fingerprint duplication. Both make recommendations as to how to resolve such duplication.

Here are some relevant excerpts from RFC 7503:

"[fingerprint]  SHOULD be constructed from the
   concatenation of a number of local values that themselves have a high
   likelihood of uniqueness,

" The OSPFv3 router
   SHOULD reduce the possibility of a subsequent Router ID collision by
   checking the Link State Database (LSDB) for an OSPFv3
   Autoconfiguration LSA with the newly selected Router ID and a
   different Router-Hardware-Fingerprint"

By comparison, the IS-IS autoconfig draft says:

" there are some resources which can
   provide an extremely high probability of uniqueness thus could be
   used as seeds to derive distinguisher..."

 " suggests using the MAC address as System ID and generating a
   pseudo-random number based on another seed (such as the memory
   address of a certain variable in the program) as the Router-
   Fingerprint..."

" to minimze the likelihood of double-duplication reoccuring,
   routers SHOULD have more entropies available.  One simple way to
   achieve this is to add the LSP sequence number..."

These seem to me to be qualitatively equivalent guidelines. And I do not see that RFC 7503 claims to have defined a guaranteed solution for fingerprint/router ID duplication. Just like the IS-IS draft it suggests procedures which have a high probability of success but which might have to be executed multiple times before successful resolution.

> only way to have unique information. Today we don't use classic ROM
> anymore, it's typically a flash memory, so even when the hardware has no
> serial number, no burned-in MAC etc. you can still store a unique serial
> number (per
> IS-IS speakers using the same source MAC address at the same time ?

[Les:] Duplicate MAC addresses are a different issue not directly related to systemID/fingerprint - nor autoconfig. They are only a problem when the two boxes are directly connected to the same media. Please see the recent discussion of this point between Acee and myself on the WG mailing list.

An implementation is free to implement duplicate MAC resolution procedures if it wishes - but doing so requires programmable MAC addresses which is NOT a requirement to support autoconfig.  Resolution of this issue is a base protocol issue and is out of scope for this draft.

> Assuming that the system ID and the MAC are kept in-sync this is likely
> covered by section 3.4.3 "IS-IS System ID Duplication Detection and
> Resolution" ?
[Les:] It is a common - and useful - convention to use a MAC address as the system ID - which the draft recommends as the initial value, but if this results in systemID duplication then clearly something else must be used. This does NOT imply that MAC address should be changed. The procedures used to do that are purposely left undefined, but we have made some suggestions in Section 3.4.5.

I would argue that leaving the exact mechanisms undefined in and of itself adds to the entropy simply because implementers are free to choose different methods.

> 
> Another comment to the authors, chairs and WG: what the creation of
> unique 6-byte system IDs is doing is creating unique MAC addresses for
> hardware with no burned-in address - another reason why the draft is
> relevant and standard-worthy in my opinion.
>
[Les:] This is a misinterpretation. There is nothing in the draft which comments on utilizing the systemID to set MAC address for the device - only the reverse is suggested. :-)

   Les

> algorithm. But I do support the draft's overall goal and think it's relevant and
> should be standardized.
> 
> 
> Regards, Marc
> 
> 
> 
> 
> > Hi Folks,
> >