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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Aug 2016 13:25:05 -0700

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.

-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?) 

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Aug 2016 20:43:31 +0000

Ben -

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

> 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

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 18 Aug 2016 02:10:34 +0300

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) <[email-masked]>, писал:
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Aug 2016 00:04:16 +0000

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:[email-masked]]
Sent: Wednesday, August 17, 2016 4:11 PM
To: Ben Campbell; The IESG; Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

Hello Les,

Thanks.

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

Ben -

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

-1, paragraph 4:

Les

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

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 18 Aug 2016 04:08:46 +0300

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) <[email-masked]>, писал:
> 16 авг. 2016 г., 23:43 +0300, Les Ginsberg (ginsberg) <[email-masked] (mailto:[email-masked])>, писал:
>
>
>
>
> Ben -
>
>
>
>
>
> Cc: [email-masked] (mailto:[email-masked]); Christian Hopps; isis-
> [email-masked] (mailto:[email-masked]); [email-masked] (mailto:[email-masked]); [email-masked] (mailto:[email-masked])
> [email-masked] (mailto:[email-masked])

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 21:27:47 -0500

> Ben -

[...]

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

I don't dispute that it is effectively normative in ISO 10589. But it's 
not normative _here_. Normally 2119 keywords should be used to create 
materially new normative requirements, not to talk about existing ones. 
In my opinion, it's best to use descriptive language when talking about 
requirements established in other documents, with the exception of 
making direct quotes from the authoritative document.

But in any case, this is not a blocking comment; do with it what you 
will.

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

Okay.

> if you find that helpful.

I think it's helpful.

Thanks!

Ben.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Aug 2016 03:35:41 +0000

Ben -

I believe all of your comments have been addressed in the recently published V4 of the draft.
Please take a look and let me know.

   Les

> Sent: Wednesday, August 17, 2016 7:28 PM
> To: Les Ginsberg (ginsberg)
> Cc: The IESG; [email-masked]; Christian Hopps; isis-
> [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's No Objection on draft-ietf-isis-remaining-
> lifetime-03: (with COMMENT)
> 
> I don't dispute that it is effectively normative in ISO 10589. But it's not
> normative _here_. Normally 2119 keywords should be used to create
> requirements established in other documents, with the exception of making
> direct quotes from the authoritative document.
> 
> But in any case, this is not a blocking comment; do with it what you will.
> 
> 
> >
> >> -1, paragraph 4:
> >>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Aug 2016 03:45:34 +0000

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:[email-masked]]
Sent: Wednesday, August 17, 2016 6:09 PM
To: Ben Campbell; The IESG; Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-remaining-lifetime-03: (with COMMENT)

Les,

Thank you.

--
Best regards,
Alexander Okonnikov

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

Alexander –

   Les

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

Hello Les,

Thanks.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, August 16, 2016 1:25 PM
To: The IESG
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps; isis-

-1, paragraph 4:

Les

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Aug 2016 23:35:04 -0500

Yes, it does.

Thanks!

Ben.

On 17 Aug 2016, at 22:35, Les Ginsberg (ginsberg) wrote:

>> making
>>>> I’m no expert here, but are where the originator might want to 
>>>> let
>>>> the LSP