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) <ginsberg@cisco.com>, писал:
> Ben -
>
> > -----Original Message-----
> > From: Ben Campbell [mailto:ben@nostrum.com]
> > Sent: Tuesday, August 16, 2016 1:25 PM
> > To: The IESG
> > Cc: draft-ietf-isis-remaining-lifetime@ietf.org; Christian Hopps; isis-
> > chairs@ietf.org; chopps@chopps.org; isis-wg@ietf.org
> > 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
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg