Hi,
I support the adoption of the “FAD constraint sub-TLV” part(Section 3), but
not support the introduce of “Bandwidth Metric Advertisement” part (Section 4)
and other related parts.
With the introduce of additional constraint information, the problem described
in “Introduction”
Hi Shraddha,
Thanks for your further explanation.
I agree if operators design it properly, it could provide the desired result of
excluding links whose maximum bandwidth is lower than the specified constraint.
As you said it is not related to the bandwidth management or reservation, thus
it
Dear Acee, Tony,
Thanks!
Tony's explanation gives the essential use of bandwidth-metric. My previous
understanding is mainly based on the problem to be solved in another draft
https://datatracker.ietf.org/doc/draft-lp-lsr-fa-bandwidth/. Sorry to insert an
advertisement in this adoption.
Hi Shraddha,
Thanks for your reply. I have no questions any more.
Regards,
PSF
原始邮件
发件人：ShraddhaHegde
收件人：彭少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 12:17
主 题 ：RE: Re:[Lsr] LSR WG Adoption
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : Area Proxy for IS-IS
Authors : Tony Li
Sarah Chen
None of the cases you described are used for routing.
And advertising information for which we do not know the use seems a bad
idea.
The abstraction that lets us talk about func bits and arg bits is nice.
But in fact, the operational structures do not depend upon that.
I really think
Joel,
Joel,
On 20/05/2021 15:59, Joel M. Halpern wrote:
I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing. It confuses operational information with routing
information. Given
Joel,
On 20/05/2021 15:59, Joel M. Halpern wrote:
I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing. It confuses operational information with routing
information. Given taht the
Hi All,
The author team together with AD have been working hard on this document and
made significant enhancements to this document.
The LSVR WG starts a working group last call for "draft-ietf-lsvr-bgp-spf-13".
Please send your comments to the LSVR list before Thursday June 3, 2021.
I have been watching this debate, and I am left with the impression that
the information being defined in section 9 of this draft is simply not
useful for routing. It confuses operational information with routing
information. Given taht the information has to come from somewhere
outside the
Roman Danyliw has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain
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
Hi Murray,
thanks for your comments, please see inline (##PP):
On 20/05/2021 10:38, Murray Kucherawy via Datatracker wrote:
Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain
When responding, please keep the subject line intact and
Hi Benjamin,
thanks for your comments, please see inline (#PP):
On 18/05/2021 22:29, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss
When responding, please keep the subject line intact and
Hi Erik,
thanks for your comment, please see inline:
On 19/05/2021 03:58, Erik Kline via Datatracker wrote:
Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss
When responding, please keep the subject line intact and reply to all
email
Hi Acee,
> -Original Message-
> From: Acee Lindem (acee)
> Sent: 20 May 2021 11:28
> To: Rob Wilton (rwilton) ; The IESG
> Cc: draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com
> Subject: Re: Robert Wilton's No
Hi Rob,
On 5/20/21, 5:11 AM, "Robert Wilton via Datatracker" wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included
Speaking as WG member:
I agree with Tony.
Furthermore, the extensions in the draft provide mechanisms to constraint
bandwidth beyond your concern that bandwidth be used as a cumulative metric. I
support WG adoption.
Thanks,
Acee
From: Tony Li on behalf of Tony Li
Date: Thursday, May 20,
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: 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
Murray Kucherawy has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Abstain
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
19 matches
Mail list logo
