Dhruv –
This gives an impression (to me) that *all* changes made are listed here. Since
that is not what is happening here, I suggested calling it - Important or Major
or Motivation to update RFC 5316, whatever you like
Got it.
I will make that clear in the next revision.
Thanx.
Les
I oppose WG adoption for this draft.
I note that the authors – following significant comments received on V0 - have
removed much of the material that was considered confusing and/or inappropriate
– notably discussion of L2 bundle link members.
I also note the draft has moved from Standards
Hi, Qin,
Thanks a lot for your support. Please see some replies inline:
Chongfeng
chongfeng@foxmail.com
发件人： Qin Wu
发送时间： 2021-03-03 14:50
收件人： Acee Lindem (acee); lsr@ietf.org
主题： Re: [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment
Routing based Virtual
Alvaro –
Your comment was to put quotes:
I would recommend using quotes in the appendix:
OLD>
1. The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV (134) if available.
NEW>
1. The "Router ID SHOULD be identical" to the value
Hi Tarek,
Yes as Tony also just indicated it is completely different game here.
Headend can do whatever it likes.
But I think your point and also what Peter said earlier is to actually
throw the baby with the bath water by suppressing advertisements/flooding.
It is all subject to proper
Hi Tony,
Yes, I’m aware FA is hop-by-hop..
My point is per-link delay changes can be suppressed and advertised at periodic
intervals (usually order of mins) or immediately based on crossing a threshold.
The per-path delay cannot be accurately extracted from a “snapshot” of the view
of the
Hi Tarek,
Please recall that in FA there is no path setup. If the delay changes and it
propagates to other nodes, then the network will SPF and paths may change
immediately.
Tony
> On Mar 3, 2021, at 2:34 PM, Tarek Saad wrote:
>
> Hi Robert,
>
> The RSVP-TE world has had to deal with
Hi Robert,
The RSVP-TE world has had to deal with such churn resulting from frequent link
attribute changes (e.g. specific to available BW). In that case, such frequent
changes made their way to the network at periodic intervals and in the event
they crossed a threshold. In my mind, the link
Hi Les,
See below at
On Wed, Mar 3, 2021 at 3:47 PM Les Ginsberg (ginsberg)
wrote:
> Donald -
>
> Thanx for your careful review and your support of the draft.
> Replies inline.
>
> > -Original Message-
> > From: Lsr On Behalf Of Donald Eastlake
> > Sent: Wednesday, March 03, 2021
Les:
The text is not the same:
§3.1 reads: "The Router ID SHOULD be identical to the value advertised in
the Traffic Engineering Router ID TLV [RFC5305].”
I’m sure you’ll do the right thing.
Thanks!
Alvaro.
On March 3, 2021 at 3:54:42 PM, Les Ginsberg (ginsberg) (ginsb...@cisco.com)
wrote:
Alvaro -
Thanx for chiming in.
Inline.
> -Original Message-
> From: Alvaro Retana
> Sent: Wednesday, March 03, 2021 12:06 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps
> ; Dhruv Dhody
> Cc: TEAS WG Chairs ; lsr@ietf.org; lsr-...@ietf.org;
> lsr-
> cha...@ietf.org; TEAS WG
OK
Les
> -Original Message-
> From: Lsr On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, March 03, 2021 10:41 AM
> To: Donald Eastlake ; Christian Hopps
>
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
> cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
>
Donald -
Thanx for your careful review and your support of the draft.
Replies inline.
> -Original Message-
> From: Lsr On Behalf Of Donald Eastlake
> Sent: Wednesday, March 03, 2021 10:32 AM
> To: Christian Hopps
> Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
>
Peter,
> that differ by few microsecond
Really you normalize only single digit microseconds ???
What if link delay changes in milliseconds scale ? Do you want to compute
new topology every few milliseconds ?
Out of curiosity as this is not a secret - What are your default min delay
Dhruv -
Thanx for reviewing/supporting the draft.
Please see inline.
> -Original Message-
> From: Lsr On Behalf Of Dhruv Dhody
> Sent: Wednesday, March 03, 2021 2:09 AM
> To: Christian Hopps
> Cc: TEAS WG Chairs ; teas-...@ietf.org; TEAS WG
> (t...@ietf.org) ;
Speaking as WG member:
As long as we are revising, I'd suggest changing "ISIS" in the title and
several times in the text to "IS-IS" consistent with other IS-IS RFCs (at least
the newer ones).
Thanks,
Acee
On 3/3/21, 1:32 PM, "Donald Eastlake" wrote:
Hi,
I have a few comments.
Hi,
I have a few comments. Sorry to send these so late in the process. I
support publication of this draft regardless of whether any action is
taken on my comments.
1. Since there are non-allocation actions, I suggest that the first
sentence of Section 6 be more like "IANA is requested to take
Peter,
>> There are several link types in use that exhibit variable delay: satellite
>> links (e.g., Starlink), microwave links, and ancient link layers that
>> deliver reliability through retransmission.
>> Any of these (and probably a lot more) can create a noticeable and
>> measurable
I support the WG Adoption of this draft.
This information draft describes how RFC5305, RFC8570 are used to advertise
topology specific TE attributes, and SR VTN resource attribute. it is useful.
Linda Dunbar
From: Lsr On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 2, 2021 5:28 PM
To:
Tony,
On 03/03/2021 18:21, Tony Li wrote:
Peter,
Link delay was dynamic before this draft. As William mentioned,
TWAMP can already be used to provide a dynamic measurement of link
delay. That, coupled with the link delay metric already gave us
dynamic path computation requirements and
Tony,
> Please note that I'm NOT recommending that we back away. Rather, we should
> seek to solve the long-standing issue of oscillatory routing.
It's a fair point and I see Robert is also making a comment on Implementation
report of how the link-delay value is measured and flooded. Seems
Peter,
>> Link delay was dynamic before this draft. As William mentioned, TWAMP can
>> already be used to provide a dynamic measurement of link delay. That,
>> coupled with the link delay metric already gave us dynamic path computation
>> requirements and the possibilities of oscillation
Hi Everyone,
I read through the document and support its adoption.
Best Regards,
Huaimo
From: Lsr on behalf of Acee Lindem (acee)
Sent: Tuesday, March 2, 2021 6:27 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
Hi Peter,
> I was talking about requirements of generation and flooding of min
> > delay for the needs of this new constrain.
>
> yes, but the min delay is already being used by flex-algo as one of the
> possible metrics, so noting new is required.
>
I think it depends on one's use case.
The
Hi Robert,
On 03/03/2021 14:55, Robert Raszuk wrote:
Yes your proposal defines constrains for FAD. But ny point is that
if you are defining such constrain called Max Link Delay you better
make sure that parameter used to measure such Maximum is well
generated and flooded.
William,
Understood. From following the thread and draft basically like the RSVP TE
ERO link attributes "include" or "exclude" or applying infinity bits to
prune off low bandwidth links from the topology graph based on either new
"exclude maximum link delays" dynamic values or existing exclude
Robert,
Pls see inline...
Juniper Business Use Only
From: Robert Raszuk
Sent: Wednesday, March 3, 2021 6:50 PM
To: Shraddha Hegde
Cc: Peter Psenak ; Gyan Mishra ;
Rajesh M ; DECRAENE Bruno IMT/OLN
; Tony Li ; lsr@ietf.org; William
Britto A J
Subject: Re: [Lsr] New draft on Flex-Algorithm
Shraddha,
Yes your proposal defines constrains for FAD. But ny point is that if you
are defining such constrain called Max Link Delay you better make sure that
parameter used to measure such Maximum is well generated and flooded.
Otherwise this constrain becomes questionable.
What if
Robert,
The draft is not trying to define new delay metric.
A new constraint called " Exclude Maximum link delay " is being defined in the
draft.
This constraint when included in the FAD should be used prune links that have
RFC 8570 advertised
Unidirectional link delay larger than the value
Hi, all
I support the adoption of this document. It is straightforward and reasonable
to use MT to build VTNs with customized topology and attributes, and the
document is well written.
Best Regards
Zongpeng Du
duzongp...@foxmail.com & duzongp...@chinamobile.com
发件人： Acee Lindem \(acee\)
Support the adoption.
Zhibo Hu
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for
Segment Routing based Virtual Transport Network” -
Robert,
looking at the text from the draft:
"The link delay [RFC8570].as advertised by the sub-TLV 33
of the TLV 22/222/23/223/141 is compared against the Max link delay
advertised in FAEMD sub-TLV."
sub-TLV 33 is "Unidirectional Link Delay", which defined as "average"
link delay.
Hi,
Support the adoption as a coauthor.
This document describes a practical mechanism to use MT together with segment
routing to build SR based VTNs.
Best regards,
Jie
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:28 AM
To:
Hi,
I’m not aware of any relevant IPR.
Best regards,
Jie
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 7:35 AM
To: draft-xie-lsr-isis-sr-vrn...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] IPR Poll for "Using IS-IS Multi-Topology (MT) for
Not sure what's the difference between the two.
But I guess let't wait for authors to clarify their intentions here.
Cheers,
R.
On Wed, Mar 3, 2021, 11:47 Peter Psenak wrote:
> Robert,
>
> On 03/03/2021 11:41, Robert Raszuk wrote:
> >
> > Sorry but to me the draft is very clear that it does
Robert,
On 03/03/2021 11:41, Robert Raszuk wrote:
Sorry but to me the draft is very clear that it does not care about min
delay, but possible maximum delay of a link ...
"maximum link delay constraint" != "max link delay"
You are not listening.
Peter
After all for time sensitive
Sorry but to me the draft is very clear that it does not care about min
delay, but possible maximum delay of a link ...
After all for time sensitive applications we do care how long it will take
to actually traverse a path in practice not what would be the theoretical
min amount of time needed
On 03/03/2021 11:27, Robert Raszuk wrote:
I am not sure I follow your logic here ...
If we are already advertising "Min Unidirectional link delay" as
described in https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13 why
would we need to define it again here in this draft ?
we are not
I am not sure I follow your logic here ...
If we are already advertising "Min Unidirectional link delay" as described
in https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13 why would we
need to define it again here in this draft ?
Also does it really make sense to advertise maximum value of
Robert,
On 03/03/2021 11:10, Robert Raszuk wrote:
Hey Peter,
> Authors stated: "Whether egress queueing delay is included in the
link
> delay depends on the measuring mechanism."
I disagree with that statement - the Min Unidirectional Link Delay is
the value that does
Hey Peter,
> > Authors stated: "Whether egress queueing delay is included in the link
> > delay depends on the measuring mechanism."
>
> I disagree with that statement - the Min Unidirectional Link Delay is
> the value that does not include the queueing delay - that's why it is
> called Min.
Hi,
I went through the diff with RFC5316. The changes look good. Some
minor comments -
(1) Is it wise to use normative keywords MUST and SHOULD in the
appendix? The text is from section 3.1 but can it be reworded in the
appendix? Also wondering if other changes (IANA, nits) could be listed
or we
Robert,
On 03/03/2021 10:58, Robert Raszuk wrote:
Hi Peter,
To your last point ...
Authors stated: "Whether egress queueing delay is included in the link
delay depends on the measuring mechanism."
I disagree with that statement - the Min Unidirectional Link Delay is
the value that does
Hi Peter,
To your last point ...
Authors stated: "Whether egress queueing delay is included in the link
delay depends on the measuring mechanism."
So sure there will be thresholds etc ... but this may very well depend on
the traffic.
Thx,
R.
On Wed, Mar 3, 2021 at 10:34 AM Peter Psenak
Yali,
On 03/03/2021 06:02, wangyali wrote:
Hi Peter,
Thanks for your comments. Yes. I am improving this sentence. Please review the
following update.
OLD: " And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information
about LSPs that transmitted in a specific MFI are generated
Hi Tony,
On 01/03/2021 21:47, Tony Li wrote:
Robert,
Constructing arbitrary topologies with bw constrain is useful work. For example
I want to create a topology without links of the capacity less then 1 Gbps. All
cool. Of course if I have a case where two nodes have 10 L3 1Gbps links nicely
Hi,
I support the publication.
thanks,
Peter
On 17/02/2021 16:30, Christian Hopps wrote:
Hi LSR and TEAS,
This begins a joint WG last call for:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
Please discuss any issues on the LSR mailing list. The WGLC will end March 3,
Hi All,
I'm not aware of any IPR associated with this document.
B.R.
Chenhao Ma
发件人: Acee Lindem (acee)
发送时间: 2021年3月3日 7:35
收件人: draft-xie-lsr-isis-sr-vrn...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll for "Using IS-IS Multi-Topology (MT) for Segment
48 matches
Mail list logo
