Subject: Re: [Isis-wg] Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt

From: Shane Amante <[email-masked]>
Date: Thu, 14 Oct 2010 21:39:01 -0600

Jonathan,

Thanks for your review of the draft.  You have raised good points that we'll clarify in the next rev of the draft.

On Oct 14, 2010, at 04:17 MDT, Jonathan Harrison wrote:
> Hi Shane,
>  
> The new draft looks good.  I've just got a couple of comments/questions, mainly to clarify my understanding.
>  
> 1) The draft mentions that the Reverse Metric TLV can be used to update the IS-IS metric "and/or" TE parameters.  Is the "or" here correct? In particular, I can't see a way to use the Reverse Metric TLV to indicate that only the TE parameters should be updated.  I'm not sure there's a need for updating only the TE parameters, so I'd be quite happy if you just want to change the "and/or" to something like "and optionally".

Will change to "and optionally".  Since the intent, at the moment, is for the receiver to overwrite its metric, then surely we can't advertise 0 as the metric, just to allow updating of TE parameters.  OTOH, if we were to consider that the receiver treat the metric in the Reverse Metric TLV metric as 'additive' to its existing metric, then we could [safely] consider advertising 0 as metric and changing solely the TE parameters.  In that case, we could change the text in the draft from "and optionally" to "or".  Do you (and others) have a preference on overwrite vs. additive behavior?

FWIW, we went with 'overwrite' for simplicity, since the overwhelming use case is to send MAX_METRIC in the Reverse Metric TLV, because you want to have a high degree of confidence that you've completely removed that link/LAN from the topology.  It would be operationally "harmful" to send anything lower in the Reverse Metric TLV, because then you won't be sure that this link/LAN is still being used to forward traffic.  Regardless, the same behavior could be accomplished with 'additive' behavior so it's really a preference call.

> 2) Am I correct in thinking that there must only ever be one Reverse Metric TLV in a Hello?  If so, it's probably worth mentioning in the draft.  (This is related to point 1.  If you do want to allow the IS-IS metric and TE parameters to be adjusted independently, then an implementation could choose to add two Reverse Metric TLVs - one TLV setting the reverse IS-IS metric and another instance of the TLV setting the reverse TE parameters.)

The intent was to only ever send one Reverse Metric TLV in a Hello, so we'll clarify that.

> 3) Section 5, operational considerations, should discuss the potential interop problems of using non-zero metrics in the pseudonode LSP.

Will do.

Thanks!

-shane