Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

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

Alexander –

Most implementations I know offer a config knob to configure MaxAge. And most implementations default to 1200.

Soooo, if you are concerned that some routers in your network may not support a value other than 1200, then you simply ensure that all routers are configured to use 1200 – which in most cases means you simply accept the default setting.

Similarly, what is discussed in Section 3.1 is supporting a configuration knob to set the value used for Remaining Lifetime when receiving a new LSP. If there is concern that some router in the network will reject LSPs with a Remaining Lifetime greater than 1200 then you don’t configure such a value.

   Les

From: Alexander Okonnikov [mailto:[e-mail]]
Sent: Wednesday, August 17, 2016 6:09 PM
To: Ben Campbell; The IESG; Les Ginsberg (ginsberg)
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

Les,

Only case I doubt is option to specify override value greater than MaxAge. If all routers use MaxAge=1200, but overriding router uses MaxAge=1200 and MaxAgeOverride=1300, then it will flood LSPs with Remaining Lifetime <1300 (except its own LSP). In case routers don't support variable MaxAge, it might pose problem.

Fully agree that practically all implementations today follow RFC 3719 2.1.

Thank you.

--
Best regards,
Alexander Okonnikov

18 авг. 2016 г., 3:04 +0300, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>, писал:

Alexander –

There is no dependence on RFC 3719 Section 2.1 in the draft.
Further, it is NOT required that all routers in the network use the same value for MaxAge. Use of MaxAge greater than 1200 (the architectural constant defined in ISO 10589) has been deployed for many years and I am not aware of any interoperability issues no matter whether all routers use the same value or inconsistent values are used.

The behavior defined in this draft is – when receiving a new LSP:

“If the Remaining Lifetime of the new LSP is less than MaxAge it
   is set to MaxAge.”

MaxAge is the local value. So if you use 65535 and I use 1200 and I receive your LSP with a value of 65000 – I will simply leave the lifetime as 65000. That is current behavior – unchanged by the draft.
If you receive my LSP with a value of 1100 you will set lifetime to 65535. This does no harm – it just means if I go down and am not able to refresh my LSP you will retain it in the database for a longer period of time – but will not use the content if I am unreachable.

Also, please read Section 3.1 of the draft – which suggests a way to make this mechanism more robust in the face of inconsistent MaxAge values.

   Les


From: Alexander Okonnikov [mailto:[e-mail]]
Sent: Wednesday, August 17, 2016 4:11 PM
To: Ben Campbell; The IESG; Les Ginsberg (ginsberg)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

Hello Les,

As I understand, described solution implicitly assumes that all routers in the network implement section 2.1 of RFC 3719. Otherwise, behavior could be detrimental in case different routers are configured with different MaxAge values. Once receiving router will override Remaining Lifetime to its local MaxAge, it will advertise this value in SNPs and in that LSP on flooding. If another router doesn't ignore greater value of MaxAge (i.e. it follows ISO 10589 rather than RFC 3719) and already holds the LSP with original Remaining Lifetime (before overriding), which is less than after overriding, then it will initiate purging of this LSP.

Hence, may be disclaimer about support of RFC 3719 section 2.1 as a requirement for all routers in the network needs to be added.

Thanks.



16 авг. 2016 г., 23:43 +0300, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>, писал:
Ben -

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]]
Sent: Tuesday, August 16, 2016 1:25 PM
To: The IESG
Cc: [e-mail]<mailto:[e-mail]>; Christian Hopps; isis-
[e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-
03: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-isis-remaining-lifetime-03: No Objection

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-remaining-lifetime/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have just a few minor comments:

- 1, 2nd paragraph: "... the checksum
field MUST NOT be altered..."

That sounds more like a statement of fact than a normative requirement.
[Les:] It is a normative requirement stated in the base protocol specification ISO 10589. It is repeated here in order to make the point that the reason RemainingLifetime is NOT included in the checksum is that doing so would require each router flooding the LSP to modify the checksum - which MUST NOT be done.

-1, paragraph 4:

I’m no expert here, but are where the originator might want to let the LSP
expire before it becomes unreachable? (e.g. during a graceful
shutdown?)

[Les:] I am not quite sure what you are suggesting.
If a router shuts down (gracefully or not) the adjacencies to it will quickly go down on its neighbors. This will make the router unreachable and any LSPs from that router will not be used by any other routers in the system.
If I wanted to be more proactive in case of a planned shutdown I could purge LSP #0 before bringing adjacencies. Base specification requires that LSP #0 from a given router be present in order to use any of the LSPs from that router.

But I don’t see the relevance of discussing any of this in the context of this draft.

-2, 4th paragraph from end: "An additional
action is added:
"
This document adds the additional action, or ISO10589 adds it?

[Les:] This document adds the additional action. I am fine with changing the text to say:

"This document introduces one additional action:"

if you find that helpful.

Les

_______________________________________________
Isis-wg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/isis-wg