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

[Alexander Okonnikov <[e-mail]>]

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

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