Subject: Re: [Isis-wg] draft-ietf-isis-auto-conf

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 25 Mar 2017 08:11:14 +0000

Alexander -

I am not sure why you did not send your comments to the WG list as well.  I have added the WG alias as this may be of interest to other folks in the WG.
Inline.

> -----Original Message-----
> From: Alexander Okonnikov [mailto:[email-masked]]
> Sent: Friday, March 24, 2017 5:09 AM
> To: [email-masked]
> Subject: draft-ietf-isis-auto-conf
> 
> Hi authors,
> 
> 
> Per procedure of protocol operation in start-up mode, router generates its
> LSP#0. Isn't it better to modify procedure such that start-up router will
> suppress generation of its LSP#0 (and omitting its LSP entry in its CSNP), until
> it will obtain full database, and will check presence of duplicate system ID. If
> duplicate system ID is present in the network (LSP with the same system ID,
> but S-bit clear), start-up router will perform change of its system ID. If its
> system ID is unique, it is advertising its LSP#0 into network. With current
> procedure there is possibility for traffic disruption, when LSP of existing
> router with the same system ID will being replaced by LSP of start-up router
> (the same case when two routers with the same system ID in regular IS-IS
> are present in the network).
> 
[Les:] As we have defined the S-bit(Startup) in the Fingerprint TLV and the tie-breaking rules in case of duplicate system-ids  favor the router NOT in startup mode we accomplish the same thing - and also handle the possible case when two routers who come up at roughly the same time have duplicate system-ids - which would have to be handled even we followed your suggestion as eventually the new routers have to send their first LSP.

> Also, the draft doesn't specify when pseudonode LSP should be generated
> (in case of start-up router is on broadcast link and is chosen to be DIS). Per
> current procedure, start-up router is not generating pseudonode LSP. But, in
> case it is DIS from point of view of other routers on the same LAN, previous
> DIS will purge its pseudonode LSP.
> Each other router will calculate start-up router as a new DIS. It also could be
> cause of disruption (absence of pseudonode LSP from new DIS).
> Hence, proposal is to start-up router to set its LAN priority to lowest value
> (0). The draft also could specify that for routers operating in non-start-up
> mode, LAN priority should not be less than 1. Once start-up router has
> finished its start-up mode, it could increase its LAN priority to
> configured/default value.
> 
[Les:] As per the base protocol (ISO10589) a router cannot declare itself DIS until it has at least one neighbor established on the LAN. As duplicate system-id detection via hellos prevents adjacencies from coming up in the event of a duplicate system-id, normal procedures regarding election of DIS can be safely used. Also the base protocol rules about new DIS pseudo-node LSP generation and purging of the pseudo-node LSPs generated by the old DIS can be safely used. 

Clever implementers find ways to avoid the disruption associated w DIS change when a new router comes up by using "make-before-break" logic.

   Les

> Thank you.
> BR,
> Alexander

---

From: Alexander Okonnikov <[email-masked]>
Date: Sat, 25 Mar 2017 22:25:50 +0300

Hi Les,

My point was to make start-up procedure less disruptive, not a replacement of current one.

Let's consider two cases:

1) Two routers in the network with the same System ID, one is in start-up mode:

IS in start-up mode can establish adjacencies, but it doesn't advertise its LSP#0 (and doesn't enlist it in its CSNP) until start-up mode timer will be expired or until IS will determine that its System ID is unique. After establishing adjacencies it receives CSNPs from its neighbors. Even if it sees LSP description for its own System ID, it still requests this LSP (rather than generates its new with higher seq num). On receipt of this LSP it further analyses Fingerprint value. If it is the same as its own, then there are two cases: "bening" and "pathological" ones, as specified in draft. In this case we follow DD-LSP procedure, specified in 3.4.6. If Fingerprint value is not the same, start-up router regenerates its System ID and restarts IS-IS process. It allows us to don't make disruption by injecting LSP of start-up router into network and thus replacing LSP of another (already working) router with the same System ID.

2) Two routers in the network with the same System ID, both are in start-up mode:

In this case, after expiring start-up mode timer, both routers are advertising their LSPs #0 into network. In this case procedure from 3.4.4 is performed (both S-bits are clear), if LSPs were advertised at almost the same time.

Regarding DIS on broadcast links: it is not clear from text that pseudonode LSP could be generated (along with LSP #0) in case start-up router is to be elected as DIS. Text says that only LSP #0 (without IS Neighbors) could be generated in start-up mode. In this case election of start-up router as DIS will break forwarding between routers in its LAN. But, even if procedure for generating pseudonode LSP is used from 10589 without modifications, it also could be disruptive, in case of duplicate System IDs in the network (not in the same LAN). Keeping in mind that Ethernet links will be used with high probability, there is chance that pseudonode LSP of start-up router will replace pseudonode LSP of existing router with the same System ID (provided that latter was elected as DIS as well, and both use the same LAN ID).

Thank you.

Best regards, Alexander Okonnikov

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 26 Mar 2017 02:10:24 +0000

Alexander -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, March 25, 2017 12:26 PM
To: [email-masked]; [email-masked]; Les Ginsberg (ginsberg)
Subject: RE: draft-ietf-isis-auto-conf

Hi Les,

[Les:] Under current draft, the router in startup mode (call it S) only generates LSP #0 and is forbidden from including IS Neighbors  or IP/IPv6 Reachability. Sequence # is 1.
The router NOT in startup mode (call it N) is guaranteed to have LSP #0  with at least sequence #2 since once it exited Startup mode it added neighbors/prefix reachability. This means the injection of S-00.00(Seq #1) will NOT produce any disruption since the existing LSP N-00.00(Seq # > 1) will be seen by all routers as newer.

When N-00.00(Seq # > 1)  is flooded to S, S will realize there is duplicate system-id and will restart with a new system-id.
No disruption to the network has occurred.

[Les:] There is no advantage to delaying the sending of LSP #0. In fact there is an advantage to sending it immediately since the two routers will discover more quickly that there is a duplicate.

[Les:] Prudent implementations – even in the absence of auto-config - delay DIS election on a LAN for a time so that they do not assume that role prematurely i.e. before they have brought up adjacencies with all the systems on the LAN.
The non-DIS systems cannot safely assume the node they have elected as DIS has actually assumed that role until they get both a LAN IIH with a non-zero LANID and a matching pseudo-node LSP. Purging of the old pseudo-node LSPs should not occur until after the new pseudo-node LSPs have been propagated.  If systems do not do these things then a DIS change will be disruptive even in the absence of duplicate system-ids. Therefore I do not see that any special behaviors are required for auto-config.

During this delay there is ample time to discover the existence of duplicate IDs.

   Les

Thank you.

On 25 марта 2017 г., 11:11 +0300, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>, wrote:

Alexander -

-----Original Message-----
From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Friday, March 24, 2017 5:09 AM
To: [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-isis-auto-conf

Hi authors,

Les

Thank you.

BR,

Alexander

---

From: Alexander Okonnikov <[email-masked]>
Date: Mon, 27 Mar 2017 11:32:57 +0300

Les, many thanks for explanation!

26.03.2017 05:10, Les Ginsberg (ginsberg) пишет:
>
> Alexander -
>
> *From:*Alexander Okonnikov [mailto:[email-masked]]
> *Sent:* Saturday, March 25, 2017 12:26 PM
> *To:* [email-masked]; [email-masked]; Les 
> Ginsberg (ginsberg)
> *Subject:* RE: draft-ietf-isis-auto-conf
>
> Hi Les,
>
> IS in start-up mode can establish adjacencies, but it doesn't 
> advertise its LSP#0 (and doesn't enlist it in its CSNP) until start-up 
> mode timer will be expired or until IS will determine that its System 
> ID is unique. After establishing adjacencies it receives CSNPs from 
> its neighbors. Even if it sees LSP description for its own System ID, 
> it still requests this LSP (rather than generates its new with higher 
> seq num). On receipt of this LSP it further analyses Fingerprint 
> value. If it is the same as its own, then there are two cases: 
> "bening" and "pathological" ones, as specified in draft. In this case 
> we follow DD-LSP procedure, specified in 3.4.6. If Fingerprint value 
> is not the same, start-up router regenerates its System ID and 
> restarts IS-IS process. It allows us to don't make disruption by 
> injecting LSP of start-up router into network and thus replacing LSP 
> of another (already working) router with the same System ID.
>
> */[Les:] Under current draft, the router in startup mode (call it S) 
> only generates LSP #0 and is forbidden from including IS Neighbors  or 
> IP/IPv6 Reachability. Sequence # is 1./*
>
> */The router NOT in startup mode (call it N) is guaranteed to have LSP 
> #0  with at least sequence #2 since once it exited Startup mode it 
> added neighbors/prefix reachability. This means the injection of 
> S-00.00(Seq #1) will NOT produce any disruption since the existing LSP 
> N-00.00(Seq # > 1) will be seen by all routers as newer./*
>
> *//*
>
> */When N-00.00(Seq # > 1)  is flooded to S, S will realize there is 
> duplicate system-id and will restart with a new system-id./*
>
> */No disruption to the network has occurred./*
>
> In this case, after expiring start-up mode timer, both routers are 
> advertising their LSPs #0 into network. In this case procedure from 
> 3.4.4 is performed (both S-bits are clear), if LSPs were advertised at 
> almost the same time.
>
> */[Les:] There is no advantage to delaying the sending of LSP #0. In 
> fact there is an advantage to sending it immediately since the two 
> routers will discover more quickly that there is a duplicate./*
>
> Regarding DIS on broadcast links: it is not clear from text that 
> pseudonode LSP could be generated (along with LSP #0) in case start-up 
> router is to be elected as DIS. Text says that only LSP #0 (without IS 
> Neighbors) could be generated in start-up mode. In this case election 
> of start-up router as DIS will break forwarding between routers in its 
> LAN. But, even if procedure for generating pseudonode LSP is used from 
> 10589 without modifications, it also could be disruptive, in case of 
> duplicate System IDs in the network (not in the same LAN). Keeping in 
> mind that Ethernet links will be used with high probability, there is 
> chance that pseudonode LSP of start-up router will replace pseudonode 
> LSP of existing router with the same System ID (provided that latter 
> was elected as DIS as well, and both use the same LAN ID).
>
> */[Les:] Prudent implementations – even in the absence of auto-config 
> - delay DIS election on a LAN for a time so that they do not assume 
> that role prematurely i.e. before they have brought up adjacencies 
> with all the systems on the LAN. /*
>
> */The non-DIS systems cannot safely assume the node they have elected 
> as DIS has actually assumed that role until they get both a LAN IIH 
> with a non-zero LANID and a matching pseudo-node LSP. Purging of the 
> old pseudo-node LSPs should not occur until after the new pseudo-node 
> LSPs have been propagated.  If systems do not do these things then a 
> DIS change will be disruptive even in the absence of duplicate 
> system-ids. Therefore I do not see that any special behaviors are 
> required for auto-config./*
>
> *//*
>
> */During this delay there is ample time to discover the existence of 
> duplicate IDs./*
>
> *//*
>
> */Les/*
>
> *//*
>
> Thank you.
>
> On 25 марта 2017 г., 11:11 +0300, Les Ginsberg (ginsberg) 
> <[email-masked] <mailto:[email-masked]>>, wrote:
>
> Alexander -
>
> I am not sure why you did not send your comments to the WG list as 
> well. I have added the WG alias as this may be of interest to other 
> folks in the WG.
> Inline.
>
>
> <mailto:[email-masked]>
> [Les:] As we have defined the S-bit(Startup) in the Fingerprint TLV 
> and the tie-breaking rules in case of duplicate system-ids favor the 
> router NOT in startup mode we accomplish the same thing - and also 
> handle the possible case when two routers who come up at roughly the 
> same time have duplicate system-ids - which would have to be handled 
> even we followed your suggestion as eventually the new routers have to 
> send their first LSP.
>
>
> [Les:] As per the base protocol (ISO10589) a router cannot declare 
> itself DIS until it has at least one neighbor established on the LAN. 
> As duplicate system-id detection via hellos prevents adjacencies from 
> coming up in the event of a duplicate system-id, normal procedures 
> regarding election of DIS can be safely used. Also the base protocol 
> rules about new DIS pseudo-node LSP generation and purging of the 
> pseudo-node LSPs generated by the old DIS can be safely used.
>
> Clever implementers find ways to avoid the disruption associated w DIS 
> change when a new router comes up by using "make-before-break" logic.
>
> Les
>
>
>
> Thank you.
>
>
> BR,
>
> Alexander
>