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

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

Alexander -

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

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.

[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.

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.

[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.

Best regards, Alexander Okonnikov

On 25 марта 2017 г., 11:11 +0300, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>, 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.


-----Original Message-----
From: Alexander Okonnikov [mailto:[e-mail]]
Sent: Friday, March 24, 2017 5:09 AM
To: [e-mail]<mailto:[e-mail]>
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