Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Alexander Okonnikov <alexander.okonnikov@gmail.com> Thu, 27 April 2017 23:59 UTC

Return-Path: <alexander.okonnikov@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED258127775; Thu, 27 Apr 2017 16:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb6ZuwNDKj0j; Thu, 27 Apr 2017 16:59:15 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE45512762F; Thu, 27 Apr 2017 16:56:20 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id 75so25635429lfs.2; Thu, 27 Apr 2017 16:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=a5p2qFvvRlOpiKvuwJRw++u+BOjaAFlHu+fempdJE8k=; b=nQHfq/nAALz8LsWyqp2ABtrY3iXWpV6s5lQJNpQ11ldR+6sGbGKflN0sWt82ZLxYZK wzh/haBvClif00gcuY+xOP+sYypNKuniRg8D/yAfQjPan0QPui08/7kZhuR+FtkmQU6e KgaOcDDWxnOmPOsX2isIBUK6k/iFTHYtEoa6lXQiTaA2pprCWFK3AisTtr3mWX7IJgMn KhcFre+wKP5I2790do8KwCrEBJNWe26rcKBXKa1EdFMep2gIkJPXzuWgD9jSotwc+hTs +Nbp7iJUk/UtxAjmQfQnSbVJPb8cJsGR1lWP2nNYfdFCVllIp19HZxP6B7XVFYmIfbQn K7TQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=a5p2qFvvRlOpiKvuwJRw++u+BOjaAFlHu+fempdJE8k=; b=TPTo8KCXh94F7lASErHDyMiwaaj8iPhExGPK8Wl2BsWaA9CKdgKq3ZaLv4lPP78Ubb 3sHXKDtHi8Yc+oGecCPz79rZd4sCSsPs4APVUFsPWb2Pqn2svA7gBtyZqBnV+TJTwvkW yDPt4QRfamOOfGM467/rgTGhI1iuDsnH5kJfqxyodkKSMRFWH0F07+NbbOPy0r8/+nBS BAJ0BUFnhvpsIZLkJG9N3K0/moH2VuQKkkE5PSaF9hlbhYs9R+V+NYrDxpVzqJ3yJOyM maQJHHwYpaVD6kSZ/3344B6box0I61OcU3TOO+mFUwh7Yrge7hlNJ3HM6zdalKTRplVj FZpw==
X-Gm-Message-State: AN3rC/6KnGulBROWYo5NmjuRoe2kXnwu+zr5grAXHLDYpayNFqs1cxN4 HGBhC3Qlr54Wng==
X-Received: by 10.46.83.83 with SMTP id t19mr525560ljd.102.1493337378924; Thu, 27 Apr 2017 16:56:18 -0700 (PDT)
Received: from [10.0.1.9] ([109.248.36.241]) by smtp.gmail.com with ESMTPSA id c68sm731680lfg.9.2017.04.27.16.56.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 16:56:18 -0700 (PDT)
Date: Fri, 28 Apr 2017 02:55:56 +0300
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "=?utf-8?Q?draft-ietf-isis-reverse-metric.authors=40ietf.org?=" <draft-ietf-isis-reverse-metric.authors@ietf.org>, "=?utf-8?Q?isis-wg=40ietf.org?=" <isis-wg@ietf.org>
Message-ID: <a222fa05-91e3-4146-a856-7af469239711@Spark>
In-Reply-To: <2c21406b1ad2414282b2b7375089cd39@XCH-ALN-001.cisco.com>
References: <f6c2518144e64aa8af7d66db894f9dde@XCH-ALN-001.cisco.com> <72C10D04-235B-41BA-81F3-A20D9E1A38A0@cisco.com> <1ee0be462930461fad0a7fba11e550b8@XCH-ALN-001.cisco.com> <97CE3949-CAE4-45DB-BAFD-13FD43F83E7C@cisco.com> <7AB352AD-67DA-405A-9B56-81A8F5F0CC75@cisco.com> <3cc44aa31d6847328836bcbb8b173ada@XCH-ALN-001.cisco.com> <0901fd7b-eb58-42ad-897d-449460960b84@Spark> <2c21406b1ad2414282b2b7375089cd39@XCH-ALN-001.cisco.com>
X-Readdle-Message-ID: a222fa05-91e3-4146-a856-7af469239711@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5902851e_19495cff_136"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/kdSHRFkZDvDpM5WDdcXgeTBlpoM>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 23:59:19 -0000

Les,

Exactly, and my concern about other implementations that adhere that Annex.

May be it would be good to make clarification in the draft about these specifics.

Thank you!

28 апр. 2017 г., 2:51 +0300, Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>, писал:
>
> Alex –
>
>
>
>
>
> I think you are referring to ISO 10589:2002 Annex C.2.4
>
>
> Note that this section is non-normative and is simply describing one possible way to implement the algorithm. When there is a question between this description and the normative portions of the specification the normative portions MUST be followed.
>
>
>
>
>
> Note that some implementations choose to initialize the tent from their own LSPs..
>
>
>
>
>
> Les
>
>
>
>
>
>
>
>
> From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com]
> Sent: Thursday, April 27, 2017 4:34 PM
> To: Naiming Shen (naiming); Les Ginsberg (ginsberg)
> Cc: draft-ietf-isis-reverse-metric.authors@ietf.org; isis-wg@ietf.org
> Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
>
>
>
>
>
>
>
> Hi Les,
>
> Yes, I agree that two-way check via LSPs is performed, thank you for correction.
>
> The problem that I'm talking is that in step 0 neighbors are put on the TENT from adjacency database, not from LSP of the router that is running SPF. Hence, for example above, when R1 will install routes via R2, metric for those routes will be based on the metric of R1's LAN interface, and not on sum of metrics 'R1 -> pseudonode' + 'pseudonode -> R2' from LSPs.
>
>
>
>
>
>
>
>
> 28 апр. 2017 г., 1:41 +0300, Les Ginsberg (ginsberg) <ginsberg@cisco.com (mailto:ginsberg@cisco.com)>, писал:
>
>
>
>
> Thanx Naiming – sounds good.
>
>
>
>
>
> Les
>
>
>
>
>
>
>
>
> From: Naiming Shen (naiming)
> Sent: Thursday, April 27, 2017 3:33 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis-wg@ietf.org (mailto:isis-wg@ietf.org); draft-ietf-isis-reverse-metric.authors@ietf.org (mailto:draft-ietf-isis-reverse-metric.authors@ietf.org)
> Subject: Re: Comments on draft-ietf-isis-reverse-metric-05
>
>
>
>
>
>
>
>
>
>
>
> and add a bit to ‘link-attribute’ bit value of the sub-TLV 19
>
>
> in the codepoint registry.
>
>
>
>
>
>
>
> thanks.
>
>
>
> - Naiming
>
>
>
>
>
> >
> > On Apr 27, 2017, at 3:30 PM, Naiming Shen (naiming) <naiming@cisco.com (mailto:naiming@cisco.com)> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Les,
> >
> >
> >
> >
> >
> >
> > We’ll add more text into the section 1.2 ‘Distributed Forwarding Planes.
> >
> >
> >
> > We’ll remove the reference to mobility in the text.
> >
> >
> >
> >
> >
> >
> >
> > thanks.
> >
> >
> >
> > - Naiming
> >
> >
> >
> >
> >
> >
> > >
> > > On Apr 26, 2017, at 9:07 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com (mailto:ginsberg@cisco.com)> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Naiming –
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thanx for the reply.
> > >
> > >
> > >
> > > Inline – look for LES:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: Naiming Shen (naiming)
> > > Sent: Wednesday, April 26, 2017 6:47 PM
> > > To: Les Ginsberg (ginsberg)
> > > Cc: isis-wg@ietf.org (mailto:isis-wg@ietf.org); draft-ietf-isis-reverse-metric.authors@ietf.org (mailto:draft-ietf-isis-reverse-metric.authors@ietf.org)
> > > Subject: Re: Comments on draft-ietf-isis-reverse-metric-05
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Les,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Thanks for the detailed comments. See some of my replies inline
> > >
> > >
> > >
> > >
> > > between [NS->] [<-NS]:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com (mailto:ginsberg@cisco.com)> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Naiming/Michael/Shane -
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Some comments on the draft.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Section 1.2. Distributed Forwarding Planes
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > RFC 5306 (Restart Signaling) has already defined use of the SA bit in the Restart TLV to request that a neighbor suppress advertisement of the adjacency thus preventing 2-way connectivity check from passing on that link. It is not clear to me why SA bit is not sufficient.
> > > >
> > > >
> > > >
> > > >
> > > > For that matter, the local system could simply not advertise the adjacency to the neighbor and achieve the same result. Why do we need any extension to handle the adjacency bringup case?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > I have some points on this:
> > >
> > >
> > >
> > >
> > > (1) if the linecard resets on the router, that is not a graceful restart case for IS-IS
> > >
> > >
> > >
> > >
> > > (2) related to the comments you were with Mikael on the ‘a matter of seconds’,
> > >
> > >
> > >
> > >
> > > this issue is more with BGP VPN than with IS-IS routes. IS-IS routes can be
> > >
> > >
> > >
> > >
> > > downloaded into the line card quickly, but millions of VPN routes may take
> > >
> > >
> > >
> > >
> > > a while
> > >
> > >
> > >
> > >
> > > (3) During this ‘take a while’, we still want to be the last resort of connection
> > >
> > >
> > >
> > >
> > > to our neighbors, instead of just blindly refuse any traffic inbound
> > >
> > >
> > >
> > >
> > > (4) Outbound traffic direction may not have any problem, we certainly want
> > >
> > >
> > >
> > >
> > > to reuse the link as soon as possible.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > How about we add some text to refer to those reasonings on this use-case?
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Les:] SA bit is not restricted to restart cases. This is discussed in RFC 5306. But SA bit is probably not the right mechanism here either as it is designed to delay adjacency advertisement until the full link state DB is acquired – this isn’t relevant here. Apologies for mentioning it.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > But in cases where the trigger (link/adjacency up) is known to all impacted routers at the same time reverse-metric is unnecessary.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Reverse metric can be useful when you want to administratively change the state of an operational link and have it impact traffic flow in both directions. Because there is no change to the operational state of the link all affected routers have to be notified of the administrative state change in some manner – reverse-metric makes this more convenient by requiring the administrative command to be signaled only on one node and have it immediately propagated to the other affected nodes. But it serves no purpose in cases where the operational state of the link is already being signaled to the control plane of all affected routers. it is in fact redundant in such cases as each router is already aware. If you use reverse-metric in such a case both routers will each tell the other one to do something that they are already doing.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Section 1.3 Mobility Cases
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I am not clear on why both ISs in such a case would not detect the change in proximity and both do metric adjustment. What is the need for use of reverse metric in this case?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Yes, you are right if the link is point-to-point. As described in RFC 8042
> > >
> > >
> > >
> > >
> > > “OSPF Two-Part Metric”, if the base-station is the DIS, it does not want
> > >
> > >
> > >
> > >
> > > to set link metric for all the remote stations, and it could be only one
> > >
> > >
> > >
> > >
> > > remote station moves away or closer.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > How about we remove the point-to-point circuit in the text of this use-case?
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Les:] I am struggling to see reverse-metric as equivalent to RFC 8042. If we support RFC 8042 then we don’t need reverse-metric.
> > >
> > >
> > >
> > > If we do not support RFC 8042, reverse-metric does not provide the same optimization as RFC 8042 as it requires multiple routers to send updates. Are you really positioning reverse-metric as an RFC 8042 alternative?
> > >
> > >
> > >
> > > Or am I missing something?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Section 2
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From the description what is being advertised in the new TLV is not a metric but a metric offset i.e. you want the receiving IS to add the advertised value to its existing configured metric. Identifying the metric field as "metric offset" would make this point more clearly.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Agreed.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > In regards to the use of sub-TLVs, I think the only use case you have is to advertise a TE metric offset - but this could easily be done as an additional fixed field in the TLV itself. Unless you foresee other sub-TLVs I think sub-TLVs could be eliminated from the TLV definition. (I also think advertising TE metric offset is unnecessary – see additional comments on TE below)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > If you want to retain sub-TLVs for future proofing you do not need both an S flag indicating the presence of sub-TLVs and a sub-TLV length field. One or the other will suffice.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > I think we were mainly for future proofing point on this. Sure, will get rid of the S flag.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Last Paragraph of Section 3.1 states:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "If the router does not understand the Reverse Metric TLV..."
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I don't think this needs to be said. It is standard IS-IS behavior to silently ignore TLVs which are not understood - and if a router does not understand the new TLV it certainly would not know what it is it "should not do". :-)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The point about allowing local policy to disable processing of the Reverse Metric TLV is a good one and the security reasons for it should be emphasized.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Agreed. Wll remove this sentence.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Section 3.5
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "During the period when a Reverse Metric TLV is used, IS-IS routers
> > > >
> > > >
> > > >
> > > >
> > > > that are generating and receiving a Reverse Metric TLV MUST NOT
> > > >
> > > >
> > > >
> > > >
> > > > change their existing IS-IS metric or Traffic Engineering parameters
> > > >
> > > >
> > > >
> > > >
> > > > in their persistent provisioning database"
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I would expect that use of Reverse Metric would often be associated with a maintenance window - in which case this is precisely the time to expect configuration changes. Because traffic has been diverted from the link this is actually the safest time to make configuration changes. Therefore I think this restriction is both unnecessary and undesirable.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Your suggested text (thread with Mikael):
> > >
> > >
> > >
> > >
> > > "The use of Reverse Metric does not alter IS-IS metric parameters stored in a router's persistent provisioning database.”
> > >
> > >
> > >
> > >
> > > looks good to me.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Regarding the TE related text
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > https://www.ietf.org/id/draft-ietf-ospf-link-overload-06.txt has highlighted that TE CSPF may not always be based on metric (IGP or TE). In which case altering the metric advertisement may not be sufficient to move TE traffic away from the link.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Sure, TE can be impacted by ‘color’, link congestion data from inband or out-band,
> > >
> > >
> > >
> > >
> > > and many other things. Its hard to cover all the things from SND point of view.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I think a more robust strategy would be to assign a bit in the link attributes sub-TLV defined in RFC 5029 to indicate that the state of the link is "maintenance" (or "overload") and that TE traffic should avoid this. That would be more robust than altering TE metric and would also eliminate the need to use the reverse metric to alter TE metric. Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22 .
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [NS->]
> > >
> > >
> > >
> > >
> > > Ok. But which TE traffic? You can say even if it’s ‘overloaded’ I still want to
> > >
> > >
> > >
> > >
> > > send certain TE traffic over. When this side of the link pushes a large
> > >
> > >
> > >
> > >
> > > offset value of reverse-metric over and the other side adds this to the
> > >
> > >
> > >
> > >
> > > link metric and TE metric values, if the controller wants to detect this
> > >
> > >
> > >
> > >
> > > condition (normally the network uses metric below 3000, and this
> > >
> > >
> > >
> > >
> > > link suddenly has the value of a billion, I’ll conside the other side of
> > >
> > >
> > >
> > >
> > > this link is ‘overloaded’.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I’m just saying I’m not sure if this is a real case. We can certainly
> > >
> > >
> > >
> > >
> > > add that if needed.
> > >
> > >
> > >
> > >
> > > [<-NS]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Les:] We agree that we do not want to try to account for every possible set of constraints. Metric is one possible constraint – but I do not see that it makes sense to treat this in a special way. If instead of modifying TE metric we advertise a link state (“maintenance” or “overload”) then TE on each router can decide for itself what adjustments it should make to all of the local tunnels independent of the set of constraints each tunnel has.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Les
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Best Regards,
> > >
> > >
> > >
> > >
> > > - Naiming
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Les
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org (mailto:Isis-wg@ietf.org)
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>
>
>