Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

From: Karsten Thomann <[email-masked]>
Date: Wed, 03 Jun 2015 21:36:06 +0000

Hi,

some comments after reading the draft:

I'm not really convinced that this will really be implemented in a home network or small enterprise 
networks, as ISIS isn't a protocol widely supported on that platforms.
I was thinking more about shortest path bridging switch autodiscovery, but this is only my own 
opinion.

Regarding 3.3.2:
What is exactly the duplication resolution, if the NET is used by an ISIS Router not capable of 
autoconfig?
In my opinion the device which is auto config capable MUST recalculate its NET, if the other router 
does not advertise a Router-Fingerprint TLV.

I'm not able to find a similar approach for the OSPF RFC, as it seems to have the same problem.

I don't know if this is typical for english texts, but I'm not familiar with the form of ".etc" only "etc." 
as this is written many times in that form.

Section 1.
andSection 3.5)./and Section 3.5). (missing space)

Section 3.4.3
Names TVL (TLV 137/Names TLV (TLV 137

Kind regards
Karsten

Am Samstag, 30. Mai 2015, 10:41:29 schrieb Liubing:
> Hi Dear all,
> 
> We've submitted a new version of the draft.
> 
> Main revisions is summarized as the following:
> 1. Revise the SysID generation to NOT prescriptive to only using MAC
> address. 2. Added a new Section 3.3.3 "SysID and Router-Fingerprint
> Generation Considerations", to specifically discuss the constrained
> entropies for generating the fields in small devices. 3. Revise the NET
> duplication procedures to remove the purge operation 4. Added a new Section
> 3.3.4 " Double-Duplication of both NET and Router-Fingerprint"
> 
> We believed this version improves a lot and removes most of the worries
> raised in previous meetings and discussions. Looking forward to your
> feedback. Thanks!
> 
> Best regards,
> Bing
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, May 30, 2015 6:27 PM
> To: Mikael Abrahamsson; Bruno Decraene; Ian Farrer; Liubing (Leo); Bruno
> Decraene; Mikael Abrahamsson; Ian Farrer; Liubing (Leo) Subject: New
> Version Notification for draft-liu-isis-auto-conf-04.txt
> 
> 
> A new version of I-D, draft-liu-isis-auto-conf-04.txt has been successfully
> submitted by Bing Liu and posted to the IETF repository.
> 
> Name:		draft-liu-isis-auto-conf
> Revision:	04
> Title:		ISIS Auto-Configuration
> Document date:	2015-05-30
> Group:		Individual Submission
> Pages:		11
> URL:           
> https://www.ietf.org/internet-drafts/draft-liu-isis-auto-conf-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-liu-isis-auto-conf/
> Htmlized:       https://tools.ietf.org/html/draft-liu-isis-auto-conf-04
> Diff:          
> https://www.ietf.org/rfcdiff?url2=draft-liu-isis-auto-conf-04
> 
> Abstract:
>    This document specifies an IS-IS auto-configuration technology.  The
>    key mechanisms of this technology are IS-IS NET (Network Entity
>    Title) self-generation, duplication detection and duplication
>    resolution.  This technology fits the environment where plug-and-play
>    is expected, e.g., home networks and small or medium size enterprise
>    networks.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 5 Jun 2015 06:44:47 +0000

Hi Karsten,

Thanks for your review and comments. Please see replies inline.

From: Karsten Thomann [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 5:36 AM
To: [email-masked]
Cc: Liubing (Leo)
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

Hi,

I'm not really convinced that this will really be implemented in a home network or small enterprise networks, as ISIS isn't a protocol widely supported on that platforms.

I was thinking more about shortest path bridging switch autodiscovery, but this is only my own opinion.

[Bing] I agree ISIS is not widely supported on small devices nowadays. But I think it might has the potential in the future.

Actually, In Homenet the ISIS is already in the short list for their routing protocol choice (http://datatracker.ietf.org/doc/draft-mrw-homenet-rtg-comparison/). And there is also some operator showed explicit requirement for ISIS in home routers.

Furthermore, the scope might not only limit to home/enterprise scenarios. Maybe the operators would find this auto-conf tool is also benefit for them one day:)

Regarding 3.3.2:

What is exactly the duplication resolution, if the NET is used by an ISIS Router not capable of autoconfig?

In my opinion the device which is auto config capable MUST recalculate its NET, if the other router does not advertise a Router-Fingerprint TLV.

[Bing] The autoconfig should be a dedicated ISIS process that it won't be mixed with the non-autoconf routers. This is prevented by the Authentication TLV as described in 3.4.1.

I don't know if this is typical for english texts, but I'm not familiar with the form of ".etc" only "etc." as this is written many times in that form.

[Bing] My bad, sorry for the language issue.

Section 1.

Section 3.4.3

[Bing] I'll correct them accordingly. Thanks for the careful check:)

Best regards,

Bing

Kind regards

Karsten

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

> [email-masked]<mailto:[email-masked]>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 5 Jun 2015 16:53:11 +0000

Actually, In Homenet the ISIS is already in the short list for their routing protocol choice (http://datatracker.ietf.org/doc/draft-mrw-homenet-rtg-comparison/).

[Uma]:  Sure,  though still it's complicated situation in Homenet, IS-IS is not out.  Some of you may aware, there was a design team formed including routing experts and

Homenet experts to come out with recommendations for the suitable RP for their needs.

And there is also some operator showed explicit requirement for ISIS in home routers.

[Uma]: We too have some discussions on this internally and I see the potential for future requests..

               IMO, this work should be progressed by closing on the corner cases further and I support this.

Cheers!

--

Uma C.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Jun 2015 17:06:24 +0000

From: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 5, 2015 at 12:53 PM
To: "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>>, Karsten Thomann <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

Speaking as the Routing Area advisor to homenet:

Agreed. I would support going forward with this work. Even if the homenet WG doesn’t select IS-IS outright, the fact that it made it to the short list indicates that there is a requirement.

Thanks,
Acee

[Uma]:  Sure,  though still it’s complicated situation in Homenet, IS-IS is not out.  Some of you may aware, there was a design team formed including routing experts and

Cheers!

--

Uma C.

---

From: Karsten Thomann <[email-masked]>
Date: Sat, 06 Jun 2015 13:35:26 +0000

Hi,

please see inline.

Am Freitag, 5. Juni 2015, 06:44:47 schrieb Liubing:
> Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version
> Notification for draft-liu-isis-auto-conf-04.txt
> 
> 
> Hi,
> 
> 
> 
> I'm not really convinced that this will really be implemented in a home
> network or small enterprise networks, as ISIS isn't a protocol widely
> supported on that platforms.
> 
> [Bing] I agree ISIS is not widely supported on small devices nowadays. But I
> think it might has the potential in the future.
> 
> Actually, In Homenet the ISIS is already in the short list for their routing
> protocol choice
> (http://datatracker.ietf.org/doc/draft-mrw-homenet-rtg-comparison/). And
> there is also some operator showed explicit requirement for ISIS in home
> routers.
> 
> 
> 
> Furthermore, the scope might not only limit to home/enterprise scenarios.
> Maybe the operators would find this auto-conf tool is also benefit for them
> one day:)
I didn't wanted to start a real discussion, only express my personal concern that it is unlikely to be 
supported in home networks, but likely in other areas where ISIS has advantages against OSPF.

> In my opinion the device which is auto config capable MUST recalculate its
> NET, if the other router does not advertise a Router-Fingerprint TLV.
> 
> [Bing] The autoconfig should be a dedicated ISIS process that it won't be
> mixed with the non-autoconf routers. This is prevented by the
> Authentication TLV as described in 3.4.1.
Yes and no, the draft uses a MUST for the ability to change the password, and there are possible 
cases where it is indended by design to use somewhere a link between a autoconf based network 
and the not autoconf network...

I my opinion it's a bit weak argument to not specify that behavior explicitly.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 8 Jun 2015 10:25:50 +0000

Hi Uma,

Many thanks for your support.

               > IMO, this work should be progressed by closing on the corner cases further and I support this.
Would you mind elaborating a bit more on what "corner cases" you were referring to? So that we can improve the draft:)

Best regards,
Bing

From: Uma Chunduri [mailto:[email-masked]]
Sent: Saturday, June 06, 2015 12:53 AM
To: Liubing (Leo); Karsten Thomann; [email-masked]
Subject: RE: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

Cheers!

--

Uma C.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 8 Jun 2015 10:31:12 +0000

Hi Acee,

Many thanks for your clarification and support.
This work was heavily inspired by you and Jari’s OSPF-autoconf [RFC7503]. I believe these autoconf technologies could benefit network operation in the future.

Best regards,
Bing

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Saturday, June 06, 2015 1:06 AM
To: Uma Chunduri; Liubing (Leo); Karsten Thomann; [email-masked]
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

Thanks,
Acee

Cheers!

--

Uma C.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 8 Jun 2015 10:41:24 +0000

Hi Karsten,

Please see replies inline.

From: Karsten Thomann [mailto:[email-masked]]
Sent: Saturday, June 06, 2015 9:35 PM
To: Liubing (Leo)
Cc: [email-masked]
Subject: Re: [Isis-wg] ISIS-autoconf-04 submitted //FW: New Version Notification for draft-liu-isis-auto-conf-04.txt

Hi,

please see inline.

> To: [email-masked]<mailto:[email-masked]>

> I was thinking more about shortest path bridging switch autodiscovery, but

> this is only my own opinion.

> one day:)

I didn't wanted to start a real discussion, only express my personal concern that it is unlikely to be supported in home networks, but likely in other areas where ISIS has advantages against OSPF.

[Bing] Expression and discussion is always good:) Thanks.

> What is exactly the duplication resolution, if the NET is used by an ISIS

> Router not capable of autoconfig?

> Authentication TLV as described in 3.4.1.

Yes and no, the draft uses a MUST for the ability to change the password, and there are possible cases where it is indended by design to use somewhere a link between a autoconf based network and the not autoconf network...

[Bing] I think it's good to explicitly specify the behavior.

But I'd prefer the behavior to be abandoning the LSP rather than recalculating its NET. In this case, the router without a Router-Fingerprin TLV just could not joint in the autoconf process, even if the authentication TLV is correct.

How do you think about it?

Best regards,

Bing

> I'm not able to find a similar approach for the OSPF RFC, as it seems to

> have the same problem.

---

From: Karsten Thomann <[email-masked]>
Date: Mon, 08 Jun 2015 22:31:53 +0000

Hi Bing,

please see reply inline.

> Notification for draft-liu-isis-auto-conf-04.txt
<snip>
> Yes and no, the draft uses a MUST for the ability to change the password,
> and there are possible cases where it is indended by design to use
> somewhere a link between a autoconf based network and the not autoconf
> network...
> 
> 
> 
> But I'd prefer the behavior to be abandoning the LSP rather than
> recalculating its NET. In this case, the router without a Router-Fingerprin
> TLV just could not joint in the autoconf process, even if the
> authentication TLV is correct.
> 
In my opinion autoconf routers should be as "passive" to the network as possible, and how would 
the abandoning of the LSP solve the issue if the other router is not directly connected or 
multihomed to other routers?

Kind regards
Karsten

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 9 Jun 2015 05:21:44 +0000

Hi Karsten,

> How do you think about it?
In my opinion autoconf routers should be as "passive" to the network as possible, and how would the abandoning of the LSP solve the issue if the other router is not directly connected or multihomed to other routers?

[Bing] Sorry, I'm a bit confused. Let me explain what I understood to check whether I was sync with you.
Say, RouterB is in an Autoconf area, and also connected to a Non-Auto area. By accident, the RouterC in the Non-auto area has a NET the same with RouterB, and for some reason RouterC send a LSP including the AuthTLV and set the autoconf password but without a Router-Fingerprint TLV. Then, my understanding is that it is not a bad LSP, which should be dropped by RouterB's autoconf process so that it won't influent the autoconf process. 
Did I miss something?

Kind regards
Karsten

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 09 Jun 2015 09:28:30 +0200

Hi Bing

Am Dienstag, 9. Juni 2015, 05:21:44 schrieb Liubing:
> In my opinion autoconf routers should be as "passive" to the network as
> possible, and how would the abandoning of the LSP solve the issue if the
> other router is not directly connected or multihomed to other routers?
> 
> [Bing] Sorry, I'm a bit confused. Let me explain what I understood to check
> whether I was sync with you. Say, RouterB is in an Autoconf area, and also
> connected to a Non-Auto area. By accident, the RouterC in the Non-auto area
> has a NET the same with RouterB, and for some reason RouterC send a LSP
> including the AuthTLV and set the autoconf password but without a
> Router-Fingerprint TLV. Then, my understanding is that it is not a bad LSP,
> which should be dropped by RouterB's autoconf process so that it won't
> influent the autoconf process. Did I miss something?

Ok, that maybe explains our communication problem, my thinking requires at 
least 3 routers to explain it.

Example topology is the following
|A| <-> |B| <-> |C|

A is the starting router and wants to join the ISIS network, B and C already 
have built an adjacency.
C isn't autoconf capable with a configured NET and now A want's to join the 
network with the same NET as C.
My question is now, what is done to prevent the LSP war?
In my opinion C should detect the duplicate NET and as it recognizes that C 
isn't autoconf capable (as there is no Router-Fingerprint-TLV) it should 
recalculate its NET.

I hope this explains my "corner case" good enough.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 11 Jun 2015 06:01:53 +0000

Hi Karsten,

Thanks for your detailed explanation, please see replies inline.

> Sent: Tuesday, June 09, 2015 3:29 PM
> To: Liubing (Leo)
> Cc: [email-masked]
> > > Yes and no, the draft uses a MUST for the ability to change the
> > > password, and there are possible cases where it is indended by
> > > design to use somewhere a link between a autoconf based network and
> > > the not autoconf network...
> > >
> > >
> > >
> > > recalculating its NET. In this case, the router without a
> > > Router-Fingerprin TLV just could not joint in the autoconf process,
> > > even if the authentication TLV is correct.
> > >
> > In my opinion autoconf routers should be as "passive" to the network
> > as possible, and how would the abandoning of the LSP solve the issue
> > if the other router is not directly connected or multihomed to other
> routers?
> >
> > [Bing] Sorry, I'm a bit confused. Let me explain what I understood to
> > check whether I was sync with you. Say, RouterB is in an Autoconf
> > area, and also connected to a Non-Auto area. By accident, the RouterC
> > in the Non-auto area has a NET the same with RouterB, and for some
> > reason RouterC send a LSP including the AuthTLV and set the autoconf
> > password but without a Router-Fingerprint TLV. Then, my understanding
> > is that it is not a bad LSP, which should be dropped by RouterB's
> > autoconf process so that it won't influent the autoconf process. Did I miss
> something?
> 
> Ok, that maybe explains our communication problem, my thinking requires
> at least 3 routers to explain it.
> 

[Bing] Ah, I think we had different assumption. I assumed the auto-conf routers and non-autoconf routers are basically separated; but I guess your case assuming they are mixed together. I think we need to think a bit more whether autoconf routers tolerance a non-autoconf router to join in the autoconf area when the non-auto router's AuthTLV is correct but without a Router-Fingerprint TLV. And vice versa, the autoconf router accidently plugged into a non-auto area and the AuthTLV is by accident be set the same as the non-auto area. 
If this is valid use case, then I think the autoconf router should re-caulculate the NET in both cases.

Best regards,
Bing

---

From: Karsten Thomann <[email-masked]>
Date: Sat, 13 Jun 2015 18:36:19 +0000

Hi,

reply inline.

Am Donnerstag, 11. Juni 2015, 06:01:53 schrieb Liubing:
> > A is the starting router and wants to join the ISIS network, B and C
> > already have built an adjacency.
> [Bing] Ah, I think we had different assumption. I assumed the auto-conf
> routers and non-autoconf routers are basically separated; but I guess your
> case assuming they are mixed together. I think we need to think a bit more
> whether autoconf routers tolerance a non-autoconf router to join in the
> autoconf area when the non-auto router's AuthTLV is correct but without a
> Router-Fingerprint TLV. And vice versa, the autoconf router accidently
> plugged into a non-auto area and the AuthTLV is by accident be set the same
> as the non-auto area. If this is valid use case, then I think the autoconf
> router should re-caulculate the NET in both cases.
My preference would be to force the autoconf capable router to recalculate its NET, as preventing 
non autoconf capable routers to join the area could prevent some possible use cases in the 
future.

Kind regards
Karsten

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 26 Jun 2015 03:01:22 +0000

Some (somewhat extensive) comments on the draft.

Overall Comments
------------------------------

1)You have completely neglected the case where duplicate system-id occurs between two directly connected routers. In such a case no neighbor can be formed and therefore no LSPs can be exchanged - which means no Fingerprint TLV is available for conflict resolution. Please see RFC 7503 Section 7.1.

There are a number of choices here:

a)You could use the MAC address as the tiebreaker (smaller MAC address changes its system-id). This of course only works on Ethernet and depends on the MAC address of the interface NOT being the source of the system-id. :-)

b)If you restrict yourself to IPv6 you could use the solution defined in RFC 7503 Section 7.1. But as you want to address IPv4 and IPv6 (no objection from me) that does not seem to be viable.

c)You could include the Fingerprint TLV in the hellos and be able to use that as a tiebreaker. This seems the most robust.

2)What you have written in the draft defines a way to make conflicts low probability and defines a means of resolving conflicts when they occur - but it does not attempt to minimize the occurrence of system-id changes for a router once it has become fully operational. This should also be a goal. To make this a reality I propose some additions:

Define a "startup mode" wherein a router does not start advertising neighbors/reachability and/or sets the OL bit until after an initial delay has expired. During this time it acquires the LSPDB and verifies that duplicate system-id is not detected. If duplicate system-id is detected we make the starting node the one which changes its system-id regardless of fingerprint content. This has minimal impact on a running network because the startup node is not yet being used for forwarding traffic. Once duplicate system-id has been resolved (if necessary) the router begins normal operation.

If two routers are both in startup mode (or both NOT in startup mode) and duplicate system-id is detected then we use the rules set forth in the draft to determine which one changes its system-id based on fingerprint.

Indication of being in startup mode can easily be included in the fingerprint TLV with a flag.

Specific Comments on Sections within the draft
----------------------------------------------------------------

Section 1.  Introduction

LES: Interesting that you don't mention ISO 10589 at all. That is the document that defines the base protocol - which RFC 1195,RFC 5308, and many others extend.

  3.  NET duplication detection and resolution

LES: More correctly "NET" should be replaced by "system-id".

Section 3.1.  IS-IS Default Configuration

LES: You might want to consider an option that allows P2P mode on Ethernet interfaces as that is quite a pervasive deployment these days.

Section 3.2.  IS-IS NET Generation
  ...

   o  Area address

         This field is 1 to 13 octets in length.  In IS-IS auto-
         configuration, this field MUST be 0 in 13 octets length.

LES: What does "0 in 13" mean? Do you mean that the area address MUST be 13 octets of all 0? Do you mean the area address can be 0 octets long (omitted) - which would be a violation of the protocol? Please clarify. 

     o  NSEL

         This field is the N-selector, and is 1 octet in length.  In IS-
         IS auto-configuration, it SHOULD be set to "00".

LES: The NSEL MUST be "00" as per ISO 10589. Anything else would be a protocol violation. Please revise the text accordingly - or eliminate it entirely as unnecessary. 

Section 3.3.  IS-IS NET Duplication Detection and Resolution

LES: This entire section is a discussion of "duplicate system-id detection/resolution" - NOT duplicate NET. The area address portion of the NET is not subject to duplicate detection - and since all routers will be L1 any router with a different area address will be ignored i.e. we will not form adjacencies to it under base protocol rules. Please rename the section  and revise the text appropriately.

Section 3.3.2.  NET Duplication Detection and Resolution Procedures

   1) Flood the Router-Fingerprint TLVs

      When an IS-IS auto-configuration router gets online, it MUST
      include the Router-Fingerprint TLV in the first originated level-1
      LSP.  Then all the routers in the area could receive the
      information in the TLV.

LES: You mean Fingerprint TLV MUST be in LSP #0?? That seems appropriate - but it needs to be stated that way.

Section 3.3.3.  SysID and Router-Fingerprint Generation Considerations

LES: It is also desirable that system-id - once chosen - should be retained across reboot.

Section 3.3.4.  Double-Duplication of both NET and Router-Fingerprint

LES: I am not following this logic. You state at the beginning of the section that fingerprint generation might be constrained - presumably because an early implementation of this functionality might not be robust. You then go on to say that if this leads to "double duplication" that routers should ("on the fly"??) be able to enhance their fingerprint. This would seem to require an implementation upgrade. Otherwise why wouldn't the fingerprint be enhanced initially? 

Or are you suggesting that - in order to save space - we send only a simple fingerprint - and if we hit double duplication we respond by sending a lengthier fingerprint? In which case you have a very imprecise definition of when "double duplication" can be declared.

Section 3.4.1.  Authentication TLV

LES: If security is a real concern I think cleartext password has been proven to be of not much value. I would suggest that you provide the ability to specify a password which would be used in MD5 authentication (RFC 5304) or perhaps Generic Crypto (RFC 5310). If security is not a concern, then no password/authentication is fine. If you choose a unique area address then it is unlikely that a non-autoconf router would be configured w the same area address so you would never form an adjacency with it.

Section 3.4.2.  Wide Metric TLV

LES: I think you have to use MUST here because routers using wide metric TLVs will not interoperate w routers using narrow metric TLVs - though they will form adjacencies. Also, there is more to wide metrics than 1 TLV. For completeness you should specify the list of TLVs which can/cannot be used (TLV 22, 135, etc.). Also, are you forbidding the use of MT (e.g. TLV 222, 235, etc.)?

Section 3.4.3.  Dynamic Host Name TLV

LES: "vendor" or "device type" won't provide uniqueness - not very helpful to have a bunch of devices all named "vendor-a". Serial #s - while likely unique - might be reasonable - assuming they are less cryptic than the chosen system-id - which is debatable. Unless there is a convenient way to get a name that the user can easily recognize I don't see much value here.

Section 3.4.4.  Purge Originator Identification TLV

LES: I don't object to this, but I don't see why it needs to be mentioned. It does not affect interoperability and it's use or non-use isn't specific to autoconfigured networks.

Section 3.5.1.  Adjacency Formation

LES: You could simply suggest using the defaults defined in ISO 10589 - which are the values you have mentioned.

Section 3.5.2.  Co-existing with Other IGP Auto-configuration

LES: So what you stated in Section 2 about "Interworking with other routing protocols" being out of scope apparently isn't true?? Otherwise why did you write this section?

   Les