sco@dmarc.ietf.org>>;
lsr@ietf.org<mailto:lsr@ietf.org>;
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints"
cee=40cisco@dmarc.ietf.org>>;
lsr@ietf.org<mailto:lsr@ietf.org>;
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constrai
: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) ; Tony Li
Cc: Acee Lindem (acee) ; lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Ket
raft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped..
1. Since the draft is covering FlexAlg
From: Lsr on behalf of gregory.mir...@ztetx.com
Sent: 25 May 2021 22:02
Inline under
Tom Petch
Hi Tony,
thank you for clarifying your view on this. Please find my notes in-line below
under the GIM>> tag.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datat
Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please ind
Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please ind
Hi Ketan,
On 27/05/2021 15:37, Ketan Talaulikar (ketant) wrote:
For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that
different values for different applications is not allowed. Maximum Link
bandwidth is also allowed with all bits set to zero in SABM/UDABM or
each
-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped..
1. Since the draft is covering FlexAlgo, I would have expected that Generic
Metric is carried only i
xible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped..
5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints,
I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA
-
https://datatracker.ie
thms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
On 27/05/2021 14:36, Shraddha Hegde wrote:
>> we only need the new TLV to carry FAPM if we make the Generic Metric's size
>> variable. If we keep it fixed size, we >should be fine with th
Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or objection by May 27th, 2021
12, 2021 at 5:09 PM
To: "lsr@ietf.org"
Cc: "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
Subject: LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This be
"Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Hi Tony,
Please check inline below.
From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf
Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Tala
cee Lindem (acee) ; lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Hi Ketan,
1.
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee)
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Hi Tony, Ketan,
ee Lindem (acee)
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Hi Tony, Ketan,
On 26/05/2021 18:40, Tony Li wrote:
>> */[KT] Generic Met
Hi Tony, Ketan,
On 26/05/2021 18:40, Tony Li wrote:
*/[KT] Generic Metric is used for the links. When we get to the
computation of inter-area or external routes, we will need to get into
FAPM. The draft at a minimum should discuss the applicability of the
Generic Metric and its use as FAPM.
Hi Aijun,
>> My suggestion is still not introduce such non-cumulative metric to
>> cumulative based SPF calculation process.
>
> Again, what we’re proposing is cumulative.
>
> [WAJ] My arguments is that your cumulative proposal (section 4.1.1.1 or
> 4.1.1.2) can get unexpected result,
Hi Ketan,
> Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4
> byte size and so why not the same for ISIS? Elsewhere in the document, I do
> see MAX METRIC being referred to as 4,261,412,864.
>
>
> Because I’m a lazy sod.
>
> It’s far easier to detect metric
width,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Aijun,
My suggestion is still not introduce such non-cumulative metric to cumulative
based SPF calculation process.
Again, what we’re proposing is cumulative.
[WAJ] My arguments is that your
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Ketan,
In general, I support the adoption of this document. There is, however, one
specific point which is not clear to me (8) below that I would appreciate some
clarity on before adoption.
As the chairs have noted
[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>>>
That’s not a big deal, but when we make the base more precise, we lose range.
If we go with 32 bits of nanoseconds, we limit ourselve
>>>
That’s not a big deal, but when we make the base more precise, we lose
range. If we go with 32 bits of nanoseconds, we limit ourselves to a link
delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and
his inter-planetary Internet. :-)
>>>
The current 24 bits of usec delay
vision
E: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: TonyLi
To: gregory mirsky10211915;
CC: lsr;
Date: 2021/05/25 09:52
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw
Mail
Sender: AnoopGhanwani
To: gregory mirsky10211915;
CC: lsr@ietf.org;
Date: 2021/05/25 00:11
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Greg,
One thing to keep in mind is
] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Snipped …
>Shraddha, you've said
>"The measurement mechanisms and advertisements in ISIS support micro-second
>granularity (RFC 85
Hi Greg,
> Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10
> nanoseconds or 100 nanoseconds.
>
Ok. The specific precision isn’t particularly relevant to me. The real
questions are whether microseconds are the right base or not, and whether we
should shift to
Hi Aijun,
> My suggestion is still not introduce such non-cumulative metric to cumulative
> based SPF calculation process.
Again, what we’re proposing is cumulative.
Tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Dear All,
thank you for the discussion of my question on the unit of the Maximum Link
Delay parameter.
Firs
Greg,
One thing to keep in mind is that even though we can measure latency at a
precision of 10's or 100's of nanoseconds, does it hurt to round the link
delay up to the nearest microsecond? One way to look at this is that by
doing such rounding up, we add at most 1 usec worth of additional
Dear All,
thank you for the discussion of my question on the unit of the Maximum Link
Delay parameter.
Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10
nanoseconds or 100 nanoseconds.
To Tony's question, the delay is usually calculated from the timestamps
Hi, Tony:
7. The document introduces a new Generic Metric type called Bandwidth
metric. I’ve been trying to follow some of the discussion related to this on
the mailing list – about it being cumulative or not. I am perhaps somewhat
confused by those discussions. The OSPF/ISIS SPT
Hi Tony,
On 24/05/2021 20:44, Tony Li wrote:
Hi Ketan,
In general, I support the adoption of this document. There is,
however, one specific point which is not clear to me (8) below that I
would appreciate some clarity on before adoption.
As the chairs have noted, adoption is binary and
Hi Ketan,
> In general, I support the adoption of this document. There is, however, one
> specific point which is not clear to me (8) below that I would appreciate
> some clarity on before adoption.
As the chairs have noted, adoption is binary and not contingent upon rough
consensus on the
-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
dha Hegde
, Tony Li , "lsr@ietf.org"
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
The part that Chris mentioned (transmission delay) doesn't depend on speed of
light or cab
Yes, I think that would be useful.
On Mon, May 24, 2021 at 8:42 AM Tony Li wrote:
>
>
> On May 24, 2021, at 8:39 AM, Anoop Ghanwani wrote:
>
> I thought that it might help operators and vendors think about
> these components.
>
>
>
>
> I would have no objection to simply enumerating the
> On May 24, 2021, at 8:39 AM, Anoop Ghanwani wrote:
>
> I thought that it might help operators and vendors think about these
> components.
I would have no objection to simply enumerating the possibilities and noting
the consistency requirement.
Tony
>
> On Mon, May 24, 2021 at 8:33
I thought that it might help operators and vendors think about
these components.
On Mon, May 24, 2021 at 8:33 AM Tony Li wrote:
>
>
> On May 24, 2021, at 8:27 AM, Anoop Ghanwani wrote:
>
> I think it might be a good idea if the draft mentioned what delay(s)
> "SHOULD" be used.
>
>
> Why?
>
>
> On May 24, 2021, at 8:27 AM, Anoop Ghanwani wrote:
>
> I think it might be a good idea if the draft mentioned what delay(s) "SHOULD"
> be used.
Why?
It seems like this is local to a domain. The network administrator is free to
do as he sees fit and include whatever parameters make sense
gt; >
> > Combination of bandwidth attribute of link and other metric
> > that is cumulative may be another co-exist way to completely
> > address this issue.
> >
> >
> >
> >
g Mirsky
> Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
> , "lsr@ietf.org" ,
> "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
> , Acee Lindem
>
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
:56 PM
>> To: Greg Mirsky
>> Cc: Shraddha Hegde , "peng.sha...@zte.com.cn"
>> , "lsr@ietf.org" ,
>> "draft-hegde-lsr-flex-algo-bw-...@ietf.org"
>> , Acee Lindem
>>
>> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexibl
少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日期：2021年05月18日 13:01
主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
Algorithms: Bandwidth, Delay, Metrics and Constraints"
metric/TE metric/delay
> > metric,
> >
> >
> >
> > so that SPF based on bandwidth-metric may get an unexpected
> > path (see the example of the original mail).
> >
> > Can more text be added in the draft to describe
少富10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日期：2021年05月18日 13:01
主题：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
Algorithms: Bandwidth, Delay, Metrics and Constraints"
sco@dmarc.ietf.org>;
lsr@ietf.org<mailto:lsr@ietf.org>;
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-
>>
> Cc: acee=40cisco@dmarc.ietf.org <mailto:40cisco@dmarc.ietf.org>;
> lsr@ietf.org <mailto:lsr@ietf.org>; draft-hegde-lsr-flex-algo-bw-...@ietf.org
> <mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
> Subject: Re:[Lsr] LSR WG Adoption Poll for "
> *Cc:* acee=40cisco@dmarc.ietf.org; lsr@ietf.org;
> draft-hegde-lsr-flex-algo-bw-...@ietf.org
> *Subject:* Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> Bandwidth, Delay, Metrics and Constraints" -
> draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
>
Hi Aijun,
>>> [WAJ] The operator must plan carefully for the metric assignment
>>> accordingly to their specific topology to let the traffic pass the
>>> necessary high bandwidth path as done in the following example.
>>
>>
>> That’s only if they have no concerns about the hop count.
> [WAJ]
Hi, Tony:
Aijun Wang
China Telecom
> On May 22, 2021, at 07:35, Tony Li wrote:
>
>
> Hi Aijun,
>
>> [WAJ] The operator must plan carefully for the metric assignment accordingly
>> to their specific topology to let the traffic pass the necessary high
>> bandwidth path as done in the
Hi Aijun,
> [WAJ] The operator must plan carefully for the metric assignment accordingly
> to their specific topology to let the traffic pass the necessary high
> bandwidth path as done in the following example.
That’s only if they have no concerns about the hop count.
Previous experience
Hi, Gyan:
Aijun Wang
China Telecom
> On May 22, 2021, at 06:59, Gyan Mishra wrote:
>
>
> Aijun
>
> This is a similar concept to what exists today with most vendors CLI
> configured reference bandwidth that can be overridden by manual metrics link
> by link to skew traffic to avoid
Hi, Gyan:
Aijun Wang
China Telecom
> On May 22, 2021, at 06:59, Gyan Mishra wrote:
>
>
>
> Aijun
>
> This is a similar concept to what exists today with most vendors CLI
> configured reference bandwidth that can be overridden by manual metrics link
> by link to skew traffic to avoid
Hi, Tony:
Aijun Wang
China Telecom
> On May 22, 2021, at 06:40, Tony Li wrote:
>
>
>
> Hi Aijun,
>
With the introduce of additional constraint information, the problem
described in “Introduction” part(Section 1) can be solved.
>>>
>>>
>>> Please say more. Claims without
Aijun
This is a similar concept to what exists today with most vendors CLI
configured reference bandwidth that can be overridden by manual metrics
link by link to skew traffic to avoid bottle necks, but now applying that
same concept that has existed historically to Flex Algo new “bandwidth
Hi Aijun,
>>> With the introduce of additional constraint information, the problem
>>> described in “Introduction” part(Section 1) can be solved.
>>
>>
>> Please say more. Claims without rationale are not reasoning.
> [WAJ] The introduction part talks mainly how to divert the elephant
f.org"
>
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>
>
> Hi Aijun,
>
>
> I support the adoption of the “FAD constraint sub-TLV” part(Section
Hi, Tony:
Aijun Wang
China Telecom
> On May 21, 2021, at 23:29, Tony Li wrote:
>
>
>
> Hi Aijun,
>
>> 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
Hi Tony, Aijun,
From: Tony Li on behalf of Tony Li
Date: Friday, May 21, 2021 at 11:29 AM
To: Aijun Wang
Cc: Acee Lindem , lsr ,
"draft-hegde-lsr-flex-algo-bw-...@ietf.org"
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Const
Hi Aijun,
> 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.
As I understand it, we don’t get a line item veto, so I don’t know how the
chairs will take
Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or object
Lindem (acee)
; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>[Jie] I can understand how this works for a single Flex-A
ex-algo-bw-...@ietf.org;
日 期 ：2021年05月20日 18:22
主 题 ：Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Speaking as WG member:
I agree with Tony.
Furthermore, the extensions in the draf
ee=40cisco@dmarc.ietf.org; lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
, 2021 at 12:20 AM
To: "peng.sha...@zte.com.cn"
Cc: "shrad...@juniper.net" , Acee Lindem
, "lsr@ietf.org" ,
"draft-hegde-lsr-flex-algo-bw-...@ietf.org"
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Const
Hi Peng Shaofu,
> On May 19, 2021, at 6:55 PM, peng.sha...@zte.com.cn wrote:
>
> Let's go back to the bandwidth-metric related to bandwidth capability. My
> worry is that bandwidth-metric (whether it is automatically calculated or
> manually configured) is not cumulative in nature, which is
ft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
10053815;
抄送人：acee=40cisco@dmarc.ietf.org;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月18日 13:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi
gt;>; Acee
Lindem (acee)
mailto:acee=40cisco@dmarc.ietf.org>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Cc:
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwid
to:lsr@ietf.org>
Cc:
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Jimmy,
Than
draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi authors,
I've read the latest version of this document and have the following comments:
r@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Hi Shraddha,
The two methods of automa
) ; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi authors,
I’ve read the latest version of this document and have the followin
;lsr@ietf.org;draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月17日 12:15
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Pengshaofu,
I was suggesting to manually assign
...@zte.com.cn
Sent: Monday, May 17, 2021 7:40 AM
To: Shraddha Hegde
Cc: acee=40cisco@dmarc.ietf.org; lsr@ietf.org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo
期 ：2021年05月13日 21:01
主 题 ：RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Hi Peng shaofu,
As per the draft, if automatic metric calculation with reference bandwidth
method is used to
gt; Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>
> Hi Jie,
>
> please see the response for one of your questions inline:
>
> On 14/05/2021 09:52, Dongjie (Jimmy)
] *On Behalf Of *Acee Lindem (acee)
*Sent:* Thursday, May 13, 2021 5:09 AM
*To:* lsr@ietf.org
*Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
*Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
Bandwidth, Delay, Metrics and Constraints" -
draft-hegde-lsr-flex-algo-bw-con-02
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the follo
lgo-bw-con
时 间：2021-05-13 06:14:57
主 题：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatrac
Support
Juniper Business Use Only
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Wednesday, May 12, 2021 5:09 PM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints&quo
Support as co-author.
I am not aware of any IPR on this draft.
Tony
> On May 12, 2021, at 2:09 PM, Acee Lindem (acee) wrote:
>
> Esteemed Members of the LSR WG,
>
> This begins a 2 week WG adoption call for the following draft:
>
>
org;
draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Sorry for spelling mistakens in the previous email.
Hi Acee,
I am not aware of any IPR related to this draft.
thanks,
Peter
On 12/05/2021 23:09, Acee Lindem (acee) wrote:
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
idth.
Do I misunderstand anything ?
Regards,
PSF
发件人：AceeLindem(acee)
收件人：lsr@ietf.org;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints&quo
AceeLindem(acee)
收件人：lsr@ietf.org;
抄送人：draft-hegde-lsr-flex-algo-bw-...@ietf.org;
日 期 ：2021年05月13日 05:49
主 题 ：[Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
ee)
> *Sent:* Thursday, May 13, 2021 2:39 AM
> *To:* lsr@ietf.org
> *Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
> *Subject:* LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
>
>
>
>
Delay,
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
[External Email. Be cautious of content]
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate yo
Yes/support
Regards,
Jeff
> On May 12, 2021, at 15:14, Acee Lindem (acee)
> wrote:
>
>
> Esteemed Members of the LSR WG,
>
> This begins a 2 week WG adoption call for the following draft:
>
> https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
>
> Please
Esteemed Members of the LSR WG,
This begins a 2 week WG adoption call for the following draft:
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
Please indicate your support or objection by May 27th, 2021.
Authors, please respond to the list indicating whether you are
93 matches
Mail list logo
