Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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

From: Dhruv Dhody 
Sent: Wednesday, March 03, 2021 10:34 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; TEAS WG Chairs ; 
teas-...@ietf.org; TEAS WG (t...@ietf.org) ; 
lsr-cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Hi Les,
On Thu, Mar 4, 2021 at 1:17 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:

Dhruv -



Thanx for reviewing/supporting the draft.

Please see inline.



> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Dhruv Dhody

> Sent: Wednesday, March 03, 2021 2:09 AM

> To: Christian Hopps mailto:cho...@chopps.org>>

> Cc: TEAS WG Chairs mailto:teas-cha...@ietf.org>>; 
> teas-...@ietf.org; TEAS WG

> (t...@ietf.org) mailto:t...@ietf.org>>; 
> lsr-cha...@ietf.org; 
> lsr@ietf.org; lsr-

> a...@ietf.org

> Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

>

> 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 could call it "major change" :)



[Les:] I personally do not have an issue using the normative keywords in the 
Appendix. Not doing so I think might trigger someone to ask if there is some 
inconsistency between the Appendix text and the text in the body of the draft. 

If you know of some prohibition against using such keywords in an Appendix 
please provide the reference.


[Dhruv]: To me, the usefulness of this appendix is to find out what has changed 
in this bis. Very useful for any reviewer or implementor. The other option is 
to do rfcdiff :(

So in this context, I provided the above comments suggesting rewording the text 
as a list of changes with rewording. Adding a reference to the relevant section 
could be useful too. Feel free to ignore, if you think this adds no value!

The IANA change is a consequence of the introduction pf new  IPv6 Local ASBR 
identifier sub-TLV. I do not see the need to mention it in the Appendix.



I do not understand your comment about "major change". Could you explain?
[Dhruv]: The current text says -

Appendix A.  Changes to RFC 5316

   This document makes the following changes to RFC 5316.


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




>

> (2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.

> table in IANA section 6.2 does not use the same name as the table in

> section 3.1

>



[Les:] The use of " IPv6 Router ID" in Section 3.1 is inconsistent. I will fix 
that.

Thanx for pointing that out.



Thanks!
Dhruv


   Les



> Hope this helps!

>

> Thanks!

>

> Dhruv

>

>

>

> On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps 
> mailto:cho...@chopps.org>>

> 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, 2021.

> >

> > Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

> >

> > Thanks,

> > Chris, Acee, (Lou and Pavan).

> > ___

> > Teas mailing list

> > t...@ietf.org

> > https://www.ietf.org/mailman/listinfo/teas

>

> ___

> Lsr mailing list

> Lsr@ietf.org

> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Les Ginsberg (ginsberg)]

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 track to Informational track.

Let’s consider what content remains (ignoring boilerplate sections):

Section 2 notes that MT TLVs (RFC 5120) can support:
   o Topology specific SR-MPLS SIDs (defined in RFC 8667)
   o Topology specific SRv6 Locators and SIDs (defined in 
draft-ietf-lsr-isis-srv6-extensions)

Section 3 notes that MT TLVs can also support link attribute advertisements 
(defined in RFC 5305 and RFC 8570)

Also note that the IANA registries:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
 and
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237

also clearly document what is discussed in Sections 2 and 3.

Section 4 notes that topology specific forwarding entries can be installed in 
the forwarding plane based on topology specific routing calculations – 
something which was discussed in RFC 5120.

Section 5 notes that two different MTIDs could operate on the same physical 
topology - something clearly discussed in RFC 5120.

All of this adds nothing new to our understanding of the protocol. The only 
“new” content is the statement that VTNs could map to MTIDs.
But the substance of VTN and how it might be used is better discussed in a 
number of other drafts including:

   draft-ietf-spring-sr-for-enhanced-vpn
   draft-ietf-teas-enhanced-vpn
   draft-dong-lsr-sr-enhanced-vpn

The last draft is most notable because it proposes new IGP protocol encodings 
in support of VTN. Whether the encodings in that draft are accepted as 
currently defined or evolve to something different – it would be the 
authoritative draft on VTN IGP extensions.

The end result is that there is no meaningful content in 
draft-xie-lsr-isis-sr-vtn-mt. What it states is either already stated in 
existing RFCs or will be stated authoritatively in whatever 
draft-dong-lsr-sr-enhanced-vpn  evolves to (if indeed this work on VTNs is 
adopted by the WG).

Let’s please not waste WG time on this draft.

   Les


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, March 02, 2021 3:28 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Chongfeng Xie]

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 Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
Hi,
I have read this draft and It is well written and I support adoption of this 
work.
Here are a few comments and suggestions:
1.   What is VTN resource, how do we define network resource, is the 
resource a.   the label that is switched on the path of the LSP, b.   
is the resource physical resource assigned to LSP?c.   Is the resource a 
measure of the capacity of a link that is dedicated for use by the traffic on 
the LSP.d.   Is the resource referred to node or link in the network 
topology?Would it be great to provide VTN resource definition in the 
terminology section,[Chongfeng] The resource in this context is the forwarding 
resources (e.g. bandwidth and the associated buffer/queuing and scheduling 
resources). For detailed description about the resources allocated to VTN, 
please refer to draft-ietf-spring-resource-aware-segments and 
draft-ietf-spring-sr-for-enhanced-vpn.
In addition, I also recommend you to reference RFC8413 for resource definition. 
[Chongfeng] Thanks for the pointer, we will take a look at it.2.   Section 
2 said:“The MT-specific Link or Prefix TLVs are defined by adding additional 
two bytes, which includes 12-bit MT-ID field in  front of the ISN TLV and IP or 
IPv6 Reachability TLVs.”
Does this require protocol extension? Are these two bytes reserved fields?  
Where MT-ID is defined? In which RFC? Also ISN TLV, IP/Ipv6 Reachablity TLV, 
where these TLVS are defined? Please provide references.

[Chongfeng] As this is an informational draft, there is no new TLV defined. The 
MT-ID based TLVs are defined in RFC 5120. The ISN TLV and the IP Reachablity 
TLV is defined in RFC 5305, are the IPv6  Reachablity is defined in RFC 5308. 
We could add some references and pointers to make it clearer. 
 
-Qin Wu
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2021年3月3日 7:28
收件人: lsr@ietf.org
主题: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
 
This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption. 
 
This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020. 
 
Thanks,
Acee
 
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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 advertised in the
   Traffic Engineering Router ID TLV (134) if available (Section 3.1).




My response was:


[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.


Now you point out that the body of the text says “[RFC5305]” whereas the 
appendix says “TLV 134”.
Fine – I can make them consistent.
Now, can you respond to my comment regarding the lack of clarity in using 
quotes?

Thanx.

   Les


From: Alvaro Retana 
Sent: Wednesday, March 03, 2021 1:09 PM
To: Les Ginsberg (ginsberg) ; Dhruv Dhody 
; Christian Hopps 
Cc: TEAS WG Chairs ; lsr-...@ietf.org; teas-...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; TEAS WG (t...@ietf.org) 
Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

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:
> 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 advertised in the
>Traffic Engineering Router ID TLV (134) if available (Section 3.1).
>

[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 suppression tuning/timers and I think we have
little experience with it (yet).

Most importantly we are talking about topology wide changes so IMHO doing
it on the receiving node is not an option. It must be done on sender.
Receiver side suppression would be only valid if timers are hard in stone
in the RFC.

Thx,
R.

On Wed, Mar 3, 2021 at 11:34 PM Tarek Saad  wrote:

> 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 delay attribute is
> no different and IGPs can react to it just like RSVP-TE did.
>
>
>
> Obviously, any path that was computed and placed on a set of links based
> on a certain view of the network may quickly become stale. However, IMO,
> any per-path e2e SLA need to be validated (independent of the network
> topology) e.g., by active measurement using probes or other means.
>
>
>
> My 2cents.
>
>
>
> Regards,
>
> Tarek
>
>
>
> On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk"  on behalf of rob...@raszuk.net> wrote:
>
>
>
> 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 normalization timers (if user does not overwrite with their own).
> Likewise how Junos or Arista normalizes it today ?
>
>
>
> Thx,
>
> R.
>
>
>
> On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak  wrote:
>
> Tony,
>
> On 03/03/2021 19:14, Tony Li wrote:
> >
> > 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 difference in TWAMP. That would be reflected in an FA metric
> change. If you imagine a situation with multiiple parallel paths with
> nearly identical delays, you can easily imagine an oscillatory scenario.
>  IMHO, this is an outstanding concern with FA.
> >> yes, and that is what I referred to as "delay normalization", which can
> avoid that oscillation.
> >
> >
> > It can also negate the benefits of the feature. One might well imagine
> that Starlink would want to follow a min-delay path for optimality.  If the
> delay variations are “normalized” out of existence, then the benefits are
> lost.  The whole point is to track the dynamics.
>
> for all practical purposes that we use it for, the two values of min
> delay that differ by few microsecond can be treated as same without any
> loss of functionality. So it's about the required normalization interval
> - something that can be controlled by the user.
>
> thanks,
> Peter
>
>
>
> >
> >
> >>> Please note that I’m NOT recommending that we back away. Rather, we
> should seek to solve the long-standing issue of oscillatory routing.
> >>
> >> not that I disagree. History tells us that the generic case of
> oscillation which is caused by the traffic itself is a hard problem to
> solve.
> >
> >
> > Any oscillation is difficult to solve.  Positive feedback certainly can
> exacerbate the problem. But solving hard problems is why we are here.
> >
> > Yours in control theory,
> > Tony
> >
> >
> >
>
>
> Juniper Business Use Only
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tarek Saad]

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 topology (e.g. adding per link delays for traversed links - as those 
values may quickly become stale). Such validation IMO (if any are needed) will 
have to come based on active/passive measuring mechanisms..

Regards,
Tarek

On 3/3/21, 5:41 PM, "Lsr on behalf of Tony Li" 
mailto:lsr-boun...@ietf.org> on behalf of 
tony...@tony.li> wrote:


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 
mailto:ts...@juniper.net>> wrote:

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 delay attribute is no different 
and IGPs can react to it just like RSVP-TE did.

Obviously, any path that was computed and placed on a set of links based on a 
certain view of the network may quickly become stale. However, IMO, any 
per-path e2e SLA need to be validated (independent of the network topology) 
e.g., by active measurement using probes or other means.

My 2cents.

Regards,
Tarek

On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk" 
mailto:lsr-boun...@ietf.org> on behalf of 
rob...@raszuk.net> wrote:

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 
normalization timers (if user does not overwrite with their own). Likewise how 
Junos or Arista normalizes it today ?

Thx,
R.

On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Tony,

On 03/03/2021 19:14, Tony Li wrote:
>
> 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 difference in TWAMP. That would be reflected in an FA metric 
>>> change. If you imagine a situation with multiiple parallel paths with 
>>> nearly identical delays, you can easily imagine an oscillatory scenario.   
>>> IMHO, this is an outstanding concern with FA.
>> yes, and that is what I referred to as "delay normalization", which can 
>> avoid that oscillation.
>
>
> It can also negate the benefits of the feature. One might well imagine that 
> Starlink would want to follow a min-delay path for optimality.  If the delay 
> variations are “normalized” out of existence, then the benefits are lost.  
> The whole point is to track the dynamics.

for all practical purposes that we use it for, the two values of min
delay that differ by few microsecond can be treated as same without any
loss of functionality. So it's about the required normalization interval
- something that can be controlled by the user.

thanks,
Peter



>
>
>>> Please note that I’m NOT recommending that we back away. Rather, we should 
>>> seek to solve the long-standing issue of oscillatory routing.
>>
>> not that I disagree. History tells us that the generic case of oscillation 
>> which is caused by the traffic itself is a hard problem to solve.
>
>
> Any oscillation is difficult to solve.  Positive feedback certainly can 
> exacerbate the problem. But solving hard problems is why we are here.
>
> Yours in control theory,
> Tony
>
>
>


Juniper Business Use Only



Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Li]

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 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 delay attribute is 
> no different and IGPs can react to it just like RSVP-TE did.
>  
> Obviously, any path that was computed and placed on a set of links based on a 
> certain view of the network may quickly become stale. However, IMO, any 
> per-path e2e SLA need to be validated (independent of the network topology) 
> e.g., by active measurement using probes or other means.
>  
> My 2cents.
>  
> Regards,
> Tarek
>  
> On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk"   on behalf of rob...@raszuk.net 
> > wrote:
>  
> 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 
> normalization timers (if user does not overwrite with their own). Likewise 
> how Junos or Arista normalizes it today ? 
>  
> Thx,
> R.
>  
> On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak  > wrote:
>> Tony,
>> 
>> On 03/03/2021 19:14, Tony Li wrote:
>> > 
>> > 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 difference in TWAMP. That would be reflected in an FA metric 
>> >>> change. If you imagine a situation with multiiple parallel paths with 
>> >>> nearly identical delays, you can easily imagine an oscillatory scenario. 
>> >>>   IMHO, this is an outstanding concern with FA.
>> >> yes, and that is what I referred to as "delay normalization", which can 
>> >> avoid that oscillation.
>> > 
>> > 
>> > It can also negate the benefits of the feature. One might well imagine 
>> > that Starlink would want to follow a min-delay path for optimality.  If 
>> > the delay variations are “normalized” out of existence, then the benefits 
>> > are lost.  The whole point is to track the dynamics.
>> 
>> for all practical purposes that we use it for, the two values of min 
>> delay that differ by few microsecond can be treated as same without any 
>> loss of functionality. So it's about the required normalization interval 
>> - something that can be controlled by the user.
>> 
>> thanks,
>> Peter
>> 
>> 
>> 
>> > 
>> > 
>> >>> Please note that I’m NOT recommending that we back away. Rather, we 
>> >>> should seek to solve the long-standing issue of oscillatory routing.
>> >>
>> >> not that I disagree. History tells us that the generic case of 
>> >> oscillation which is caused by the traffic itself is a hard problem to 
>> >> solve.
>> > 
>> > 
>> > Any oscillation is difficult to solve.  Positive feedback certainly can 
>> > exacerbate the problem. But solving hard problems is why we are here.
>> > 
>> > Yours in control theory,
>> > Tony
>> > 
>> > 
>> > 
>> 
> 
> Juniper Business Use Only
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tarek Saad]

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 delay attribute is no different 
and IGPs can react to it just like RSVP-TE did.

Obviously, any path that was computed and placed on a set of links based on a 
certain view of the network may quickly become stale. However, IMO, any 
per-path e2e SLA need to be validated (independent of the network topology) 
e.g., by active measurement using probes or other means.

My 2cents.

Regards,
Tarek

On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk" 
mailto:lsr-boun...@ietf.org> on behalf of 
rob...@raszuk.net> wrote:

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 
normalization timers (if user does not overwrite with their own). Likewise how 
Junos or Arista normalizes it today ?

Thx,
R.

On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Tony,

On 03/03/2021 19:14, Tony Li wrote:
>
> 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 difference in TWAMP. That would be reflected in an FA metric 
>>> change. If you imagine a situation with multiiple parallel paths with 
>>> nearly identical delays, you can easily imagine an oscillatory scenario.   
>>> IMHO, this is an outstanding concern with FA.
>> yes, and that is what I referred to as "delay normalization", which can 
>> avoid that oscillation.
>
>
> It can also negate the benefits of the feature. One might well imagine that 
> Starlink would want to follow a min-delay path for optimality.  If the delay 
> variations are “normalized” out of existence, then the benefits are lost.  
> The whole point is to track the dynamics.

for all practical purposes that we use it for, the two values of min
delay that differ by few microsecond can be treated as same without any
loss of functionality. So it's about the required normalization interval
- something that can be controlled by the user.

thanks,
Peter



>
>
>>> Please note that I’m NOT recommending that we back away. Rather, we should 
>>> seek to solve the long-standing issue of oscillatory routing.
>>
>> not that I disagree. History tells us that the generic case of oscillation 
>> which is caused by the traffic itself is a hard problem to solve.
>
>
> Any oscillation is difficult to solve.  Positive feedback certainly can 
> exacerbate the problem. But solving hard problems is why we are here.
>
> Yours in control theory,
> Tony
>
>
>


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Donald Eastlake]

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 10:32 AM
> > To: Christian Hopps 
> > Cc: teas-cha...@ietf.org; teas-...@ietf.org; t...@ietf.org; lsr-
> > cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
> > Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> >
> > 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 the
> > following actions."
>
> [Les:] I understand your point.
> However, in this case we are inheriting allocations made by RFC5316 AND
> adding a new code point for the new IPv6 local ASBR identifier sub-TLV.
> Being 100% accurate requires identifying what has been done already vs
> what is new.
> But once the RFC is published the text will change to " IANA has made..."
> (as it is in RFC 5316) for all the code points (new and old).
> Having worked w IANA folks many times, I have great confidence that they
> will get things right even with the current less than 100% strictly
> accurate text - so I prefer not to invest time here.
> Hope that is OK with you.
>

 I agree that IANA will fix this so it is OK to not change.


> > 2. It should be called out as an explicit IANA action to replace all
> > References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> > with References to "[this document]".
> >
>
> [Les:] OK
>
> > 3. Use of "new" throughout the document for codepoints that were
> > assigned for RFC 5316 more than a decade ago should be eliminated.
>
> [Les:] Well, this document replaces RFC 5316. Which means future readers
> need not ever look at RFC 5316. In which case the distinction between what
> was "new" in 5316 and what is "new" in 5316bis becomes moot.
> So while I agree that strictly speaking you are correct I am not convinced
> that doing as you suggest aids clarity.


  I was not suggesting making any distinction between what is or isn't
new in 5316bis, except by implication in the IANA Considerations Section.
I actually just don't see any need to use the word "new" in this document.

> 4. I generally think it is better for implementation requirements to
> > be in the main text rather than the IANA Considerations, so I suggest
> > moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> > 25, 222, or 223 and MUST be ignored if they are included in any of
> > these TLVs." up to near the end of Section 3.1.
>
> [Les:] I have looked at other documents with similar cases (i.e., a
> sub-TLV that is permitted in only a subset of the TLVs in the combined
> registry) and they do not have such a statement at all. The "N" indication
> in the registry columns is deemed sufficient.
> I am therefore inclined to remove the Note altogether.
>

 OK.


> > 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> > the prose table at the beginning of 3.1 with the following. In any
> > case note that the usual IETF admonition regarding the reserved bits,
> > that they MUST be sent as zero and ignored on receipt, seems to be
> > missing in the document.
> >
> > 0   1   2   3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >|   Router ID (4 octets)|
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >|   default metric  | (3 octets)
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >|S|D| Rsvd  | (1 octet)
> >+-+-+-+-+-+-+-+-+
> >|sub-TLVs length| (1 octet)
> >+-+-+-+-+-+-+-+-+-+-+-+-
> >| sub-TLVs ...(0-246 octets)
> >+-+-+-+-+-+-+-+-+-+-+-+-
> >
> >  - S, D: Flooding-scope and up/down information discussed below.
> >  - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
> >  on receipt.
> >  - sub-TLVs length: gives the total number of octets of sub-TLVs,
> >  which is variable from zero to 246 octets, as an unsigned
> >  integer. sub-TLVs are structured as shown below. sub-TLVs
> >  with an unknown type MUST be ignored. If the value of the
> >  sub-TLVs length field is larger than 246, or the last
> >  sub-TLV extends beyond the sub-TLVs length, the TLV is
> >  malformed and MUST be ignored.
> >
> >+-+-+-+-+-+-+-+-+
> >| sub-type  |  

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Alvaro Retana]

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:

> 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 advertised in the
>Traffic Engineering Router ID TLV (134) if available (Section 3.1).
>

[Les:] So I am willing to make the change. But I have to say that for me as
a reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the
unquoted portion of the sentence the meaning of the quoted part is
incomplete.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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 (t...@ietf.org) ; teas-
> a...@ietf.org
> Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> On March 3, 2021 at 2:47:38 PM, Les Ginsberg wrote:
> > > From: Lsr On Behalf Of Dhruv Dhody
> 
> Les:
> 
> Hi!
> 
> ...
> > > (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 could call it "major change" :)
> >
> > [Les:] I personally do not have an issue using the normative keywords in
> > the Appendix. Not doing so I think might trigger someone to ask if there is
> > some inconsistency between the Appendix text and the text in the body of
> the
> > draft. 
> >
> > If you know of some prohibition against using such keywords in an
> Appendix
> > please provide the reference.
> 
> There's no specific prohibition against it -- in fact, sometimes an
> appendix can be normative so it is completely appropriate to have
> normative language.
> 
> In this case, the appendix is informative and the normative text is
> only reflecting what the main body of the draft says (which is where
> the specification is).  To avoid confusion about which piece of text
> is normative, and keep consistency, 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 advertised in the
>    Traffic Engineering Router ID TLV (134) if available (Section 3.1).
> 

[Les:] So I am willing to make the change. But I have to say that for me as a 
reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the 
unquoted portion of the sentence the meaning of the quoted part is incomplete.

??

   Les

> 
> Alvaro.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> 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. 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 the
> following actions."
> 
> 2. It should be called out as an explicit IANA action to replace all
> References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> with References to "[this document]".
> 
> 3. Use of "new" throughout the document for codepoints that were
> assigned for RFC 5316 more than a decade ago should be eliminated.
> 
> 4. I generally think it is better for implementation requirements to
> be in the main text rather than the IANA Considerations, so I suggest
> moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> 25, 222, or 223 and MUST be ignored if they are included in any of
> these TLVs." up to near the end of Section 3.1.
> 
> 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> the prose table at the beginning of 3.1 with the following. In any
> case note that the usual IETF admonition regarding the reserved bits,
> that they MUST be sent as zero and ignored on receipt, seems to be
> missing in the document.
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Router ID (4 octets)|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   default metric  | (3 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|S|D| Rsvd  | (1 octet)
>+-+-+-+-+-+-+-+-+
>|sub-TLVs length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLVs ...(0-246 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
>  - S, D: Flooding-scope and up/down information discussed below.
>  - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
>  on receipt.
>  - sub-TLVs length: gives the total number of octets of sub-TLVs,
>  which is variable from zero to 246 octets, as an unsigned
>  integer. sub-TLVs are structured as shown below. sub-TLVs
>  with an unknown type MUST be ignored. If the value of the
>  sub-TLVs length field is larger than 246, or the last
>  sub-TLV extends beyond the sub-TLVs length, the TLV is
>  malformed and MUST be ignored.
> 
>+-+-+-+-+-+-+-+-+
>| sub-type  | (1 octet)
>+-+-+-+-+-+-+-+-+
>| sub-TLV length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLV value ...   (variable)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
> 
> On Wed, Feb 17, 2021 at 10:30 AM 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, 2021.
> >
> > Authors, please indicate wether you are aware of any IPR related to this
> document to the list.
> >
> > Thanks,
> > Chris, Acee, (Lou and Pavan).
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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-
> cha...@ietf.org; lsr@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> 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 the
> following actions."
> 

[Les:] I understand your point.
However, in this case we are inheriting allocations made by RFC5316 AND adding 
a new code point for the new IPv6 local ASBR identifier sub-TLV.
Being 100% accurate requires identifying what has been done already vs what is 
new.
But once the RFC is published the text will change to " IANA has made..." (as 
it is in RFC 5316) for all the code points (new and old).
Having worked w IANA folks many times, I have great confidence that they will 
get things right even with the current less than 100% strictly accurate text - 
so I prefer not to invest time here.
Hope that is OK with you.


> 2. It should be called out as an explicit IANA action to replace all
> References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
> with References to "[this document]".
> 

[Les:] OK

> 3. Use of "new" throughout the document for codepoints that were
> assigned for RFC 5316 more than a decade ago should be eliminated.
> 

[Les:] Well, this document replaces RFC 5316. Which means future readers need 
not ever look at RFC 5316. In which case the distinction between what was "new" 
in 5316 and what is "new" in 5316bis becomes moot. 
So while I agree that strictly speaking you are correct I am not convinced that 
doing as you suggest aids clarity. 

> 4. I generally think it is better for implementation requirements to
> be in the main text rather than the IANA Considerations, so I suggest
> moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
> 25, 222, or 223 and MUST be ignored if they are included in any of
> these TLVs." up to near the end of Section 3.1.

[Les:] I have looked at other documents with similar cases (i.e., a sub-TLV 
that is permitted in only a subset of the TLVs in the combined registry) and 
they do not have such a statement at all. The "N" indication in the registry 
columns is deemed sufficient.
I am therefore inclined to remove the Note altogether.

> 
> 2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
> the prose table at the beginning of 3.1 with the following. In any
> case note that the usual IETF admonition regarding the reserved bits,
> that they MUST be sent as zero and ignored on receipt, seems to be
> missing in the document.
> 
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   Router ID (4 octets)|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|   default metric  | (3 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|S|D| Rsvd  | (1 octet)
>+-+-+-+-+-+-+-+-+
>|sub-TLVs length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLVs ...(0-246 octets)
>+-+-+-+-+-+-+-+-+-+-+-+-
> 
>  - S, D: Flooding-scope and up/down information discussed below.
>  - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
>  on receipt.
>  - sub-TLVs length: gives the total number of octets of sub-TLVs,
>  which is variable from zero to 246 octets, as an unsigned
>  integer. sub-TLVs are structured as shown below. sub-TLVs
>  with an unknown type MUST be ignored. If the value of the
>  sub-TLVs length field is larger than 246, or the last
>  sub-TLV extends beyond the sub-TLVs length, the TLV is
>  malformed and MUST be ignored.
> 
>+-+-+-+-+-+-+-+-+
>| sub-type  | (1 octet)
>+-+-+-+-+-+-+-+-+
>| sub-TLV length| (1 octet)
>+-+-+-+-+-+-+-+-+-+-+-+-
>| sub-TLV value ...   (variable)
>+-+-+-+-+-+-+-+-+-+-+-+-

[Les:] OK
It was not done this way in RFC 5316. When writing bis documents I am biased to 
NOT changing existing presentation if there is no actual change in 
functionality to that section.
But I agree diagrams are easier to read and it would be more consistent with 
other 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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
normalization timers (if user does not overwrite with their own). Likewise
how Junos or Arista normalizes it today ?

Thx,
R.

On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak  wrote:

> Tony,
>
> On 03/03/2021 19:14, Tony Li wrote:
> >
> > 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 difference in TWAMP. That would be reflected in an FA metric
> change. If you imagine a situation with multiiple parallel paths with
> nearly identical delays, you can easily imagine an oscillatory scenario.
>  IMHO, this is an outstanding concern with FA.
> >> yes, and that is what I referred to as "delay normalization", which can
> avoid that oscillation.
> >
> >
> > It can also negate the benefits of the feature. One might well imagine
> that Starlink would want to follow a min-delay path for optimality.  If the
> delay variations are “normalized” out of existence, then the benefits are
> lost.  The whole point is to track the dynamics.
>
> for all practical purposes that we use it for, the two values of min
> delay that differ by few microsecond can be treated as same without any
> loss of functionality. So it's about the required normalization interval
> - something that can be controlled by the user.
>
> thanks,
> Peter
>
>
>
> >
> >
> >>> Please note that I’m NOT recommending that we back away. Rather, we
> should seek to solve the long-standing issue of oscillatory routing.
> >>
> >> not that I disagree. History tells us that the generic case of
> oscillation which is caused by the traffic itself is a hard problem to
> solve.
> >
> >
> > Any oscillation is difficult to solve.  Positive feedback certainly can
> exacerbate the problem. But solving hard problems is why we are here.
> >
> > Yours in control theory,
> > Tony
> >
> >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Les Ginsberg (ginsberg)]

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) ; lsr-cha...@ietf.org; lsr@ietf.org; lsr-

> a...@ietf.org

> Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

>

> 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 could call it "major change" :)



[Les:] I personally do not have an issue using the normative keywords in the 
Appendix. Not doing so I think might trigger someone to ask if there is some 
inconsistency between the Appendix text and the text in the body of the draft. 

If you know of some prohibition against using such keywords in an Appendix 
please provide the reference.



The IANA change is a consequence of the introduction pf new  IPv6 Local ASBR 
identifier sub-TLV. I do not see the need to mention it in the Appendix.



I do not understand your comment about "major change". Could you explain?



>

> (2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.

> table in IANA section 6.2 does not use the same name as the table in

> section 3.1

>



[Les:] The use of " IPv6 Router ID" in Section 3.1 is inconsistent. I will fix 
that.

Thanx for pointing that out.



   Les



> Hope this helps!

>

> Thanks!

>

> Dhruv

>

>

>

> On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps 
> mailto:cho...@chopps.org>>

> 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, 2021.

> >

> > Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

> >

> > Thanks,

> > Chris, Acee, (Lou and Pavan).

> > ___

> > Teas mailing list

> > t...@ietf.org

> > https://www.ietf.org/mailman/listinfo/teas

>

> ___

> Lsr mailing list

> Lsr@ietf.org

> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Acee Lindem (acee)]

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. 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 the
following actions."

2. It should be called out as an explicit IANA action to replace all
References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
with References to "[this document]".

3. Use of "new" throughout the document for codepoints that were
assigned for RFC 5316 more than a decade ago should be eliminated.

4. I generally think it is better for implementation requirements to
be in the main text rather than the IANA Considerations, so I suggest
moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
25, 222, or 223 and MUST be ignored if they are included in any of
these TLVs." up to near the end of Section 3.1.

2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
the prose table at the beginning of 3.1 with the following. In any
case note that the usual IETF admonition regarding the reserved bits,
that they MUST be sent as zero and ignored on receipt, seems to be
missing in the document.

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Router ID (4 octets)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   default metric  | (3 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|D| Rsvd  | (1 octet)
   +-+-+-+-+-+-+-+-+
   |sub-TLVs length| (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLVs ...(0-246 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-

 - S, D: Flooding-scope and up/down information discussed below.
 - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
 on receipt.
 - sub-TLVs length: gives the total number of octets of sub-TLVs,
 which is variable from zero to 246 octets, as an unsigned
 integer. sub-TLVs are structured as shown below. sub-TLVs
 with an unknown type MUST be ignored. If the value of the
 sub-TLVs length field is larger than 246, or the last
 sub-TLV extends beyond the sub-TLVs length, the TLV is
 malformed and MUST be ignored.

   +-+-+-+-+-+-+-+-+
   | sub-type  | (1 octet)
   +-+-+-+-+-+-+-+-+
   | sub-TLV length| (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLV value ...   (variable)
   +-+-+-+-+-+-+-+-+-+-+-+-


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Wed, Feb 17, 2021 at 10:30 AM 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, 2021.
>
> Authors, please indicate wether you are aware of any IPR related to this 
document to the list.
>
> Thanks,
> Chris, Acee, (Lou and Pavan).

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Donald Eastlake]

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 the
following actions."

2. It should be called out as an explicit IANA action to replace all
References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
with References to "[this document]".

3. Use of "new" throughout the document for codepoints that were
assigned for RFC 5316 more than a decade ago should be eliminated.

4. I generally think it is better for implementation requirements to
be in the main text rather than the IANA Considerations, so I suggest
moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
25, 222, or 223 and MUST be ignored if they are included in any of
these TLVs." up to near the end of Section 3.1.

2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
the prose table at the beginning of 3.1 with the following. In any
case note that the usual IETF admonition regarding the reserved bits,
that they MUST be sent as zero and ignored on receipt, seems to be
missing in the document.

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Router ID (4 octets)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   default metric  | (3 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|D| Rsvd  | (1 octet)
   +-+-+-+-+-+-+-+-+
   |sub-TLVs length| (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLVs ...(0-246 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-

 - S, D: Flooding-scope and up/down information discussed below.
 - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
 on receipt.
 - sub-TLVs length: gives the total number of octets of sub-TLVs,
 which is variable from zero to 246 octets, as an unsigned
 integer. sub-TLVs are structured as shown below. sub-TLVs
 with an unknown type MUST be ignored. If the value of the
 sub-TLVs length field is larger than 246, or the last
 sub-TLV extends beyond the sub-TLVs length, the TLV is
 malformed and MUST be ignored.

   +-+-+-+-+-+-+-+-+
   | sub-type  | (1 octet)
   +-+-+-+-+-+-+-+-+
   | sub-TLV length| (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLV value ...   (variable)
   +-+-+-+-+-+-+-+-+-+-+-+-


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Wed, Feb 17, 2021 at 10:30 AM 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, 
> 2021.
>
> Authors, please indicate wether you are aware of any IPR related to this 
> document to the list.
>
> Thanks,
> Chris, Acee, (Lou and Pavan).

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Li]

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 difference in TWAMP. That would be reflected in an FA metric 
>> change. If you imagine a situation with multiiple parallel paths with nearly 
>> identical delays, you can easily imagine an oscillatory scenario.   IMHO, 
>> this is an outstanding concern with FA.
> yes, and that is what I referred to as "delay normalization", which can avoid 
> that oscillation.


It can also negate the benefits of the feature. One might well imagine that 
Starlink would want to follow a min-delay path for optimality.  If the delay 
variations are “normalized” out of existence, then the benefits are lost.  The 
whole point is to track the dynamics.


>> Please note that I’m NOT recommending that we back away. Rather, we should 
>> seek to solve the long-standing issue of oscillatory routing.
> 
> not that I disagree. History tells us that the generic case of oscillation 
> which is caused by the traffic itself is a hard problem to solve.


Any oscillation is difficult to solve.  Positive feedback certainly can 
exacerbate the problem. But solving hard problems is why we are here.

Yours in control theory,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Linda Dunbar]

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: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 the possibilities of 
oscillation and instability. We have chosen to charge ahead, without 
addressing those concerns already.


TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the 
other side this value is calculated based on multiple measurements 
over period of time and an average is used. Also, smart 
implementations can normalize the value so that a small fluctuation of 
the delay is not causing the traffic to shift or cause ECMP loss.


What is important here is that the Min Unidirectional Link Delay is a 
link characteristic, not something that is affected by the amount of 
traffic on the link or subject to queuing delay. Same applies to 
Maximum link bandwidth.



I do understand that the minimum link delay is not meant to include 
queuing delay. That, however, does NOT make it a constant.


I never claimed it is constant. It should not be affected though by the 
amount of traffic on the link itself, but rather by the characteristics 
of the underlying physical path.




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 difference in TWAMP. That would be reflected in an FA metric 
change. If you imagine a situation with multiiple parallel paths with 
nearly identical delays, you can easily imagine an oscillatory scenario. 
  IMHO, this is an outstanding concern with FA.
yes, and that is what I referred to as "delay normalization", which can 
avoid that oscillation. There are implementations that do that today. 
You normalize the measured value so that values that are close enough 
are advertised as same value. That works well for min delay case, which 
does not change significantly very often.




Please note that I’m NOT recommending that we back away. Rather, we 
should seek to solve the long-standing issue of oscillatory routing.


not that I disagree. History tells us that the generic case of 
oscillation which is caused by the traffic itself is a hard problem to 
solve.


thanks,
Peter



Regards,
Tony



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

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 like either a 
clarification draft on RFC 8570 or an 8570bis would make sense.

RFC 8570 has been around for sometime. I would be interested to hear if there 
are deployments of dynamically measured link-delay.

Rgds
Shraddha



Juniper Business Use Only
From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, March 3, 2021 10:52 PM
To: Peter Psenak 
Cc: Robert Raszuk ; Gyan Mishra ; 
DECRAENE Bruno IMT/OLN ; Shraddha Hegde 
; Rajesh M ; lsr@ietf.org; William 
Britto A J 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


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 and instability. We have 
chosen to charge ahead, without addressing those concerns already.

TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the other 
side this value is calculated based on multiple measurements over period of 
time and an average is used. Also, smart implementations can normalize the 
value so that a small fluctuation of the delay is not causing the traffic to 
shift or cause ECMP loss.

What is important here is that the Min Unidirectional Link Delay is a link 
characteristic, not something that is affected by the amount of traffic on the 
link or subject to queuing delay. Same applies to Maximum link bandwidth.


I do understand that the minimum link delay is not meant to include queuing 
delay. That, however, does NOT make it a constant.

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 
difference in TWAMP. That would be reflected in an FA metric change. If you 
imagine a situation with multiiple parallel paths with nearly identical delays, 
you can easily imagine an oscillatory scenario.  IMHO, this is an outstanding 
concern with FA.

Please note that I'm NOT recommending that we back away. Rather, we should seek 
to solve the long-standing issue of oscillatory routing.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Tony Li]

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 and instability. We have 
>> chosen to charge ahead, without addressing those concerns already.
> 
> TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the other 
> side this value is calculated based on multiple measurements over period of 
> time and an average is used. Also, smart implementations can normalize the 
> value so that a small fluctuation of the delay is not causing the traffic to 
> shift or cause ECMP loss.
> 
> What is important here is that the Min Unidirectional Link Delay is a link 
> characteristic, not something that is affected by the amount of traffic on 
> the link or subject to queuing delay. Same applies to Maximum link bandwidth.


I do understand that the minimum link delay is not meant to include queuing 
delay. That, however, does NOT make it a constant.  

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 
difference in TWAMP. That would be reflected in an FA metric change. If you 
imagine a situation with multiiple parallel paths with nearly identical delays, 
you can easily imagine an oscillatory scenario.  IMHO, this is an outstanding 
concern with FA. 

Please note that I’m NOT recommending that we back away. Rather, we should seek 
to solve the long-standing issue of oscillatory routing.

Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Huaimo Chen]

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) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03


This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.



This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.



Thanks,

Acee




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 fact that we are advertising this min delay today to me does not mean
that we are done with it for ever and every use case :).

All,

Is there any document or implementation report summarizing how different
implementations generate and how (by default) trigger flooding of the
changed min delay value per link ?

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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. 

 The Maximum delay in FAD is compared against min delay
advertised per link as  in RFC 8570.

    so maximum delay is not required to be
generated and flooded  for every link.


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.


thank,
Peter


Thx,
R.



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Gyan Mishra]

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 link
affinity FAD static values.  Do I have it right?

Kind Regards

Gyan

On Mon, Mar 1, 2021 at 5:24 AM William Britto A J 
wrote:

> Hi Gyan,
>
>
>
> This draft aims to provide the protocol constructs to define a
> flex-algorithm which is suitable for sending high bandwidth traffic. Flex-Algo
> is a very useful feature for network consolidation use-cases which requires
> different metric-types for SPF. We are trying introduce the protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
>
>
> This draft does not attempt to do bandwidth management nor reservation
> like what RSVP does. For LDP based networks that use igp metric relative to
> bandwidth, Flex-Algo provides an easy alternate.
>
>
>
> Thanks,
>
> William
>
>
>
> *From: *Gyan Mishra 
> *Date: *Saturday, 27 February 2021 at 9:40 PM
> *To: *Robert Raszuk 
> *Cc: *DECRAENE Bruno IMT/OLN , Rajesh M <
> mraj...@juniper.net>, Shraddha Hegde , William
> Britto A J , lsr@ietf.org 
> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi William & Co-authors
>
>
>
> From first read of the draft it does appear your are trying to apply RSVP
> TE PCALC path and reserve message link attributes constraints such as
> concept of affinity bits to exclude low bandwidth or delay of individual
> links without taking into account all of what RSVP TE is reserving of
> bandwidth in the end to end path with the Path and Reserve message.  As
> mentioned Looking at individual links will not provide the end to end path
> view or bandwidth requirements for the entire path to be reserved as
> accomplished by RSVP TE.
>
>
>
> As Tony and Robert have mentioned I agree this is a good first step but
> does need more refinement to make useful.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk  wrote:
>
> Hi William & co-authors,
>
>
>
> I read the draft and have two basic questions.
>
>
>
> 1.
>
> Both bw & delay can be used as defined in the draft to construct new
> forwarding topologies. But how practical such topologies would be in the
> real life when 40GB links may be heavily occupied with bursty traffic and
> 10G links can sit idle ? I suppose you are trying to address the case where
> say 12 gbps holographic stream needs to be sent across a network.. But then
> I don't think if sending it in a single flow instead of spreading into many
> sub-flows and use as much as possible ecmp would not be a better option.
>
>
>
> 2.
>
> Likewise how good is my accumulated link delay value if in between there
> are deep buffer network elements and say egress queuing to each link (which
> max is unaccounted for in your draft) can significantly alter the end to
> end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link
> basis (still as static value).  So if some traffic is delay sensitive we
> will have a much better accuracy not to get into a trap of queuing related
> delays.
>
>
>
> Thx a lot,
>
> Robert.
>
>
>
>
>
> On Fri, Feb 26, 2021 at 8:37 AM William Britto A J  40juniper@dmarc.ietf.org> wrote:
>
> All,
>
>
>
> We would like to draw your attention to a new ID:
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00
> 
>
>
>
> The draft talks about introducing link bandwidth related constraints in
> Flex-Algorithm which can be used to define a Flex-Algorithm based on
> bandwidth based metric.
>
>
>
> Please review. Any questions and comments are welcome.
>
>
>
> Thanks,
>
> William
>
>
>
>
>
> *From: *internet-dra...@ietf.org 
> *Date: *Monday, 22 February 2021 at 10:56 PM
> *To: *Bruno Decraene , Rajesh M <
> mraj...@juniper.net>, Rajesh M , Shraddha Hegde <
> shrad...@juniper.net>, William Britto A J , William
> Britto A J 
> *Subject: *New Version Notification for
> draft-hegde-lsr-flex-algo-bw-con-00.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
> has been successfully submitted by Shraddha Hegde and posted to the
> IETF repository.
>
> Name:   draft-hegde-lsr-flex-algo-bw-con
> Revision:   00
> Title:  Flexible Algorithms Bandwidth Constraints
> Document date:  2021-02-22
> Group:  Individual Submission
> Pages:  21
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$
> 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

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 Bandwidth Constraints

[External Email. Be cautious of content]

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.
 The Maximum delay in FAD is compared against min delay advertised 
per link as  in RFC 8570.
   so maximum delay is not required to be generated and 
flooded  for every link.

Otherwise this constrain becomes questionable.

What if implementation will choose to advertise Minimum Link Delay of the 
period of 1 week or have this as constant value configured wheen you test your 
link before deploying it in production ? What if it never will include egress 
queueing delay. How practical will be your constrain in such cases ?
 If statically configured link delay values are used in production, 
the existing exclude link affinity FAD constraints will be good enough to 
achieve any required  topology pruning in the Flex-algo. The "Exclude maximum 
link delay" defined in this document is useful when dynamic link-delay 
measurement is used.

Many thx,
R.






On Wed, Mar 3, 2021 at 2:03 PM Shraddha Hegde 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
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 defined in this FAD constraint.
We will post the -01 version when the window opens. We have clearer text and 
also
fixed some confusions in IANA section.

Rgds
Shraddha





Juniper Business Use Only
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, March 3, 2021 4:12 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Tony Li mailto:tony...@tony.li>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; DECRAENE Bruno IMT/OLN 
mailto:bruno.decra...@orange.com>>; Shraddha Hegde 
mailto:shrad...@juniper.net>>; Rajesh M 
mailto:mraj...@juniper.net>>; 
lsr@ietf.org; William Britto A J 
mailto:40juniper@dmarc.ietf.org>>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


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 for this path to be traversed.

And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 
3.2.2.:


   Similarly, exclude maximum link delay constraint is also defined in

   this document.  Links may have the link delay measured dynamically

   and advertised in delay metric in IGP.  For usecases that deploy low

   latency flex-algo, may want to exclude links that have delay more

   than a defined threshold.

Thx,

R.

On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
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 defining the metric here, we are defining the constraint that
says what is the maximum value of that metric that can be used.

thanks,
Peter
>
> Also does it really make sense to advertise maximum value of
> minimum value ?
>
> Thx,
> R.
>
> On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak 
> mailto:ppse...@cisco.com>
> >> wrote:
>
> 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 not include the queueing delay - that's
> why it is
>  > called Min.
>  >
>  >
>  >
>  > But draft we are 

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 implementation will choose to advertise Minimum Link Delay of
the period of 1 week or have this as constant value configured wheen you
test your link before deploying it in production ? What if it never will
include egress queueing delay. How practical will be your constrain in such
cases ?

Many thx,
R.






On Wed, Mar 3, 2021 at 2:03 PM Shraddha Hegde  wrote:

> 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 defined in this FAD
> constraint.
>
> We will post the -01 version when the window opens. We have clearer text
> and also
>
> fixed some confusions in IANA section.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, March 3, 2021 4:12 PM
> *To:* Peter Psenak 
> *Cc:* Tony Li ; Gyan Mishra ;
> DECRAENE Bruno IMT/OLN ; Shraddha Hegde <
> shrad...@juniper.net>; Rajesh M ; lsr@ietf.org;
> William Britto A J 
> *Subject:* Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> 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 for this path to be traversed.
>
>
>
> And it does define it here as brand new metric.
>
>
>
> Just read this paragraph as well as sections 3.1.2 and 3.2.2.
> :
>
>
>
>
>Similarly, exclude maximum link delay constraint is also defined in
>
>this document.  Links may have the link delay measured dynamically
>
>and advertised in delay metric in IGP.  For usecases that deploy low
>
>latency flex-algo, may want to exclude links that have delay more
>
>than a defined threshold.
>
> Thx,
>
> R.
>
>
>
> On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak  wrote:
>
> 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 defining the metric here, we are defining the constraint that
> says what is the maximum value of that metric that can be used.
>
> thanks,
> Peter
> >
> > Also does it really make sense to advertise maximum value of
> > minimum value ?
> >
> > Thx,
> > R.
> >
> > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak  > > wrote:
> >
> > 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 not include the queueing delay - that's
> > why it is
> >  > called Min.
> >  >
> >  >
> >  >
> >  > But draft we are discussing here does not talk about "Min" delay.
> >  > Contrary it talks about "Max"
> >  >
> >  > *Maximum*  Delay sub-TLV
> >  >
> >  > That is also I asked that very question up front.
> >
> > I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
> > Delay"
> > as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> > advertise
> > the maximum value of the "Min Unidirectional Link Delay" that is
> > allowed
> > for the particular FA.
> >
> > The text should be improved in that regard though, it's not obvious,
> > but
> > I believe that's what it is.
> >
> > thanks,
> > Peter
> >
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  >
> >  >
> >  >
> >
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Shraddha Hegde]

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 defined in this FAD constraint.
We will post the -01 version when the window opens. We have clearer text and 
also
fixed some confusions in IANA section.

Rgds
Shraddha





Juniper Business Use Only
From: Robert Raszuk 
Sent: Wednesday, March 3, 2021 4:12 PM
To: Peter Psenak 
Cc: Tony Li ; Gyan Mishra ; DECRAENE 
Bruno IMT/OLN ; Shraddha Hegde 
; Rajesh M ; lsr@ietf.org; William 
Britto A J 
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]


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 for this path to be traversed.

And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 
3.2.2.:


   Similarly, exclude maximum link delay constraint is also defined in

   this document.  Links may have the link delay measured dynamically

   and advertised in delay metric in IGP.  For usecases that deploy low

   latency flex-algo, may want to exclude links that have delay more

   than a defined threshold.

Thx,

R.

On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
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 defining the metric here, we are defining the constraint that
says what is the maximum value of that metric that can be used.

thanks,
Peter
>
> Also does it really make sense to advertise maximum value of
> minimum value ?
>
> Thx,
> R.
>
> On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak 
> mailto:ppse...@cisco.com>
> >> wrote:
>
> 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 not include the queueing delay - that's
> why it is
>  > called Min.
>  >
>  >
>  >
>  > But draft we are discussing here does not talk about "Min" delay.
>  > Contrary it talks about "Max"
>  >
>  > *Maximum*  Delay sub-TLV
>  >
>  > That is also I asked that very question up front.
>
> I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
> Delay"
> as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> advertise
> the maximum value of the "Min Unidirectional Link Delay" that is
> allowed
> for the particular FA.
>
> The text should be improved in that regard though, it's not obvious,
> but
> I believe that's what it is.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>  >
>  >
>  >
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[duzongp...@foxmail.com]

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\)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption. 
 
This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020. 
 
Thanks,
Acee
 
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Huzhibo]

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” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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.


I would argue this should be Min Delay.

The draft proposes to use "Maximum link bandwidth" (TLV-9) as a metric 
(indirectly) and is using the same TLV-9 to compare against the "Min 
Bandwidth" constraint.


The same should be used for metric - it uses Min delay (TLV-34) as 
metric and it should use the same TLV-34 to compare against the "Maximum 
Delay" constraint.


Usage of the "average" delay that is subject to change depending on the 
traffic crossing the link would make the problem of traffic osculation 
much more real and I'm not sure we want to go that path - history has 
proved that to be quite difficult.


thanks,
Peter


On 03/03/2021 11:54, Robert Raszuk wrote:

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 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 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 for this path to be traversed.
 >
 > And it does define it here as brand new metric.
 >
 > Just read this paragraph as well as sections 3.1.2 and 3.2.2.
 > :
 >
 >     Similarly, exclude maximum link delay constraint is also
defined in
 >     this document.  Links may have the link delay measured
dynamically
 >     and advertised in delay metric in IGP.  For usecases that
deploy low
 >     latency flex-algo, may want to exclude links that have delay more
 >     than a defined threshold.
 >
 > Thx,
 > R.
 >
 >
 > On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak mailto:ppse...@cisco.com>
 > >> wrote:
 >
 >     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 defining the metric here, we are defining the
constraint
 >     that
 >     says what is the maximum value of that metric that can be used.
 >
 >     thanks,
 >     Peter
 >      >
 >      > Also does it really make sense to advertise maximum value of
 >      > minimum value ?
 >      >
 >      > Thx,
 >      > R.
 >      >
 >      > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak
mailto:ppse...@cisco.com>
 >     >
 >      > 
      >
 >      >     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 not include the queueing
delay -
 >     that's
 >      >     why it is
 >      >      >     called Min.
 >      >      >
 >      >      >
 >      >      >
 >      >      > But draft we are discussing here does not talk
about "Min"
 >     delay.
 >      >      > Contrary it talks about "Max"
 >      >      >
 >      >      > *Maximum*  Delay sub-TLV
 >      >      >
 >      >      > That is also I asked that very question up front.
 >      >
 >      >     I'm afraid you misunderstood it. FA uses "Min
Unidirectional Link
 >      >     Delay"
 >      >     as one of its metrics. The "Maximum Delay sub-TLV"  is
used to
 >      >     advertise
 >      >     the maximum value of the "Min Unidirectional Link
Delay" that is
 >      >     allowed
 >      >     for the 

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Dongjie (Jimmy)]

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: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03

[Dongjie (Jimmy)]

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 Segment 
Routing based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03

Authors,

Are you aware of any other IPR that applies to draft-xie-lsr-issi-sr-vtn-mt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Note that no IPRs have been declared - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-xie-lsr-isis-sr-vtn-mt

Thanks,
Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 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 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 for this path to be traversed.
> >
> > And it does define it here as brand new metric.
> >
> > Just read this paragraph as well as sections 3.1.2 and 3.2.2.
> > :
> >
> > Similarly, exclude maximum link delay constraint is also defined in
> > this document.  Links may have the link delay measured dynamically
> > and advertised in delay metric in IGP.  For usecases that deploy low
> > latency flex-algo, may want to exclude links that have delay more
> > than a defined threshold.
> >
> > Thx,
> > R.
> >
> >
> > On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak  > > wrote:
> >
> > 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 defining the metric here, we are defining the constraint
> > that
> > says what is the maximum value of that metric that can be used.
> >
> > thanks,
> > Peter
> >  >
> >  > Also does it really make sense to advertise maximum value of
> >  > minimum value ?
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak  > 
> >  > >> wrote:
> >  >
> >  > 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 not include the queueing delay -
> > that's
> >  > why it is
> >  >  > called Min.
> >  >  >
> >  >  >
> >  >  >
> >  >  > But draft we are discussing here does not talk about "Min"
> > delay.
> >  >  > Contrary it talks about "Max"
> >  >  >
> >  >  > *Maximum*  Delay sub-TLV
> >  >  >
> >  >  > That is also I asked that very question up front.
> >  >
> >  > I'm afraid you misunderstood it. FA uses "Min Unidirectional
> Link
> >  > Delay"
> >  > as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> >  > advertise
> >  > the maximum value of the "Min Unidirectional Link Delay" that
> is
> >  > allowed
> >  > for the particular FA.
> >  >
> >  > The text should be improved in that regard though, it's not
> > obvious,
> >  > but
> >  > I believe that's what it is.
> >  >
> >  > thanks,
> >  > Peter
> >  >
> >  >  >
> >  >  > Thx,
> >  >  > R.
> >  >  >
> >  >  >
> >  >  >
> >  >  >
> >  >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 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 for this path to be traversed.


And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 3.2.2. 
:


Similarly, exclude maximum link delay constraint is also defined in
this document.  Links may have the link delay measured dynamically
and advertised in delay metric in IGP.  For usecases that deploy low
latency flex-algo, may want to exclude links that have delay more
than a defined threshold.

Thx,
R.


On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak > wrote:


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 defining the metric here, we are defining the constraint
that
says what is the maximum value of that metric that can be used.

thanks,
Peter
 >
 > Also does it really make sense to advertise maximum value of
 > minimum value ?
 >
 > Thx,
 > R.
 >
 > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak mailto:ppse...@cisco.com>
 > >> wrote:
 >
 >     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 not include the queueing delay -
that's
 >     why it is
 >      >     called Min.
 >      >
 >      >
 >      >
 >      > But draft we are discussing here does not talk about "Min"
delay.
 >      > Contrary it talks about "Max"
 >      >
 >      > *Maximum*  Delay sub-TLV
 >      >
 >      > That is also I asked that very question up front.
 >
 >     I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
 >     Delay"
 >     as one of its metrics. The "Maximum Delay sub-TLV"  is used to
 >     advertise
 >     the maximum value of the "Min Unidirectional Link Delay" that is
 >     allowed
 >     for the particular FA.
 >
 >     The text should be improved in that regard though, it's not
obvious,
 >     but
 >     I believe that's what it is.
 >
 >     thanks,
 >     Peter
 >
 >      >
 >      > Thx,
 >      > R.
 >      >
 >      >
 >      >
 >      >
 >



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 for this path to be traversed.

And it does define it here as brand new metric.

Just read this paragraph as well as sections 3.1.2 and 3.2.2.:

   Similarly, exclude maximum link delay constraint is also defined in
   this document.  Links may have the link delay measured dynamically
   and advertised in delay metric in IGP.  For usecases that deploy low
   latency flex-algo, may want to exclude links that have delay more
   than a defined threshold.

Thx,
R.


On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak  wrote:

> 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 defining the metric here, we are defining the constraint that
> says what is the maximum value of that metric that can be used.
>
> thanks,
> Peter
> >
> > Also does it really make sense to advertise maximum value of
> > minimum value ?
> >
> > Thx,
> > R.
> >
> > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak  > > wrote:
> >
> > 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 not include the queueing delay - that's
> > why it is
> >  > called Min.
> >  >
> >  >
> >  >
> >  > But draft we are discussing here does not talk about "Min" delay.
> >  > Contrary it talks about "Max"
> >  >
> >  > *Maximum*  Delay sub-TLV
> >  >
> >  > That is also I asked that very question up front.
> >
> > I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
> > Delay"
> > as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> > advertise
> > the maximum value of the "Min Unidirectional Link Delay" that is
> > allowed
> > for the particular FA.
> >
> > The text should be improved in that regard though, it's not obvious,
> > but
> > I believe that's what it is.
> >
> > thanks,
> > Peter
> >
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  >
> >  >
> >  >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 defining the metric here, we are defining the constraint that 
says what is the maximum value of that metric that can be used.


thanks,
Peter


Also does it really make sense to advertise maximum value of 
minimum value ?


Thx,
R.

On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak > wrote:


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 not include the queueing delay - that's
why it is
 >     called Min.
 >
 >
 >
 > But draft we are discussing here does not talk about "Min" delay.
 > Contrary it talks about "Max"
 >
 > *Maximum*  Delay sub-TLV
 >
 > That is also I asked that very question up front.

I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
Delay"
as one of its metrics. The "Maximum Delay sub-TLV"  is used to
advertise
the maximum value of the "Min Unidirectional Link Delay" that is
allowed
for the particular FA.

The text should be improved in that regard though, it's not obvious,
but
I believe that's what it is.

thanks,
Peter

 >
 > Thx,
 > R.
 >
 >
 >
 >



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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 minimum value
?

Thx,
R.

On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak  wrote:

> 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 not include the queueing delay - that's why it is
> > called Min.
> >
> >
> >
> > But draft we are discussing here does not talk about "Min" delay.
> > Contrary it talks about "Max"
> >
> > *Maximum*  Delay sub-TLV
> >
> > That is also I asked that very question up front.
>
> I'm afraid you misunderstood it. FA uses "Min Unidirectional Link Delay"
> as one of its metrics. The "Maximum Delay sub-TLV"  is used to advertise
> the maximum value of the "Min Unidirectional Link Delay" that is allowed
> for the particular FA.
>
> The text should be improved in that regard though, it's not obvious, but
> I believe that's what it is.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
> >
> >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 not include the queueing delay - that's why it is
called Min.



But draft we are discussing here does not talk about "Min" delay. 
Contrary it talks about "Max"


*Maximum*  Delay sub-TLV

That is also I asked that very question up front.


I'm afraid you misunderstood it. FA uses "Min Unidirectional Link Delay" 
as one of its metrics. The "Maximum Delay sub-TLV"  is used to advertise 
the maximum value of the "Min Unidirectional Link Delay" that is allowed 
for the particular FA.


The text should be improved in that regard though, it's not obvious, but 
I believe that's what it is.


thanks,
Peter



Thx,
R.






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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.



But draft we are discussing here does not talk about "Min" delay. Contrary
it talks about "Max"

*Maximum* Delay sub-TLV

That is also I asked that very question up front.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Dhruv Dhody]

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 could call it "major change" :)

(2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.
table in IANA section 6.2 does not use the same name as the table in
section 3.1

Hope this helps!

Thanks!

Dhruv



On Wed, Feb 17, 2021 at 9:00 PM 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, 
> 2021.
>
> Authors, please indicate wether you are aware of any IPR related to this 
> document to the list.
>
> Thanks,
> Chris, Acee, (Lou and Pavan).
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 not include the queueing delay - that's why it is 
called Min.




So sure there will be thresholds etc ... but this may very well depend 
on the traffic.


no.

thanks,
Peter



Thx,
R.



On Wed, Mar 3, 2021 at 10:34 AM Peter Psenak > wrote:


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 doing ECMP I will not
include those which may be a problem.
 >
 >
 > I agree that it may be a problem. Maybe it’s not the right tool
for the job at hand. That doesn’t make it a bad tool, just the wrong
one. I try not to turn screws with a hammer. And I try not to drive
nails with a screwdriver.
 >
 > I will happily stipulate that we need more tools and that these
are not enough.  We should not reject a tool simply because it
doesn’t solve all problems. Let’s work towards the right set of
tools. Linear algebra tells us that we want an orthogonal set of
basis vectors. What are they? Adding them one at a time is not
horrible progress.
 >
 >
 >> However my observation is precisely related to your last sentence.
 >>
 >> Is this extension to be used with static or dynamic data ? If
static all fine. But as William replied to me earlier link delay may
be dynamically computed and may include queue wait time. That to me
means something much different if Flex-Algo topologies will become
dynamically adjustable. And I am not saying this is not great idea
.. My interest here is just to understand the current scope.
 >
 >
 > 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 and instability. We have chosen to charge ahead, without
addressing those concerns already.

TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the
other side this value is calculated based on multiple measurements over
period of time and an average is used. Also, smart implementations can
normalize the value so that a small fluctuation of the delay is not
causing the traffic to shift or cause ECMP loss.

What is important here is that the Min Unidirectional Link Delay is a
link characteristic, not something that is affected by the amount of
traffic on the link or subject to queuing delay. Same applies to
Maximum
link bandwidth.

thanks,
Peter


 >
 > Regards,
 > Tony
 >
 > ___
 > Lsr mailing list
 > Lsr@ietf.org 
 > https://www.ietf.org/mailman/listinfo/lsr
 >
 >



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Robert Raszuk]

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  wrote:

> 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 doing ECMP I will not include those which may be a
> problem.
> >
> >
> > I agree that it may be a problem. Maybe it’s not the right tool for the
> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
> to turn screws with a hammer. And I try not to drive nails with a
> screwdriver.
> >
> > I will happily stipulate that we need more tools and that these are not
> enough.  We should not reject a tool simply because it doesn’t solve all
> problems. Let’s work towards the right set of tools. Linear algebra tells
> us that we want an orthogonal set of basis vectors. What are they? Adding
> them one at a time is not horrible progress.
> >
> >
> >> However my observation is precisely related to your last sentence.
> >>
> >> Is this extension to be used with static or dynamic data ? If static
> all fine. But as William replied to me earlier link delay may be
> dynamically computed and may include queue wait time. That to me means
> something much different if Flex-Algo topologies will become dynamically
> adjustable. And I am not saying this is not great idea .. My interest here
> is just to understand the current scope.
> >
> >
> > 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 and instability. We have
> chosen to charge ahead, without addressing those concerns already.
>
> TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the
> other side this value is calculated based on multiple measurements over
> period of time and an average is used. Also, smart implementations can
> normalize the value so that a small fluctuation of the delay is not
> causing the traffic to shift or cause ECMP loss.
>
> What is important here is that the Min Unidirectional Link Delay is a
> link characteristic, not something that is affected by the amount of
> traffic on the link or subject to queuing delay. Same applies to Maximum
> link bandwidth.
>
> thanks,
> Peter
>
>
> >
> > Regards,
> > Tony
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[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 to synchronize the LSDB 
corresponding to the specific MFI."

NEW: " And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP containing information 
about LSPs that transmitted in a specific MFI are generated to synchronize the 
MFI-specific sub-LSDB. Each MFI-specific sub-LSDB is subdivided from a single LSDB."


please specify sub-LSDB.

thanks,
Peter




Best,
Yali

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Tuesday, March 2, 2021 5:12 PM
To: wangyali ; Gyan Mishra ; Robert 
Raszuk 
Cc: Huzhibo ; Aijun Wang ; Tony Li 
; lsr ; Tianran Zhou 
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

Yali,

On 01/03/2021 10:49, wangyali wrote:

Hi Peter,

Many thanks for your feedback. First of all, I'm sorry for the confusion I had 
caused you from my previous misunderstanding.

And I want to clarify that a single and common LSDB is shared by all MFIs.


well, the draft says:

"information about LSPs that transmitted in a
   specific MFI are generated to synchronize the LSDB corresponding to
   the specific MFI."

If the above has changed, then please update the draft accordingly.

thanks,
Peter





Best,
Yali

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Sunday, February 28, 2021 8:23 PM
To: Gyan Mishra ; Robert Raszuk

Cc: Huzhibo ; Aijun Wang
; Tony Li ; lsr
; Tianran Zhou ; wangyali

Subject: Re: [Lsr] New Version Notification for
draft-wang-lsr-isis-mfi-00.txt

Gyan,

On 26/02/2021 17:19, Gyan Mishra wrote:


MFI seems more like flex algo with multiple sub topologies sharing a
common links in a  topology where RFC 8202 MI is separated at the
process level separate LSDB.  So completely different and of course
different goals and use cases for MI versus MFI.


I would not use the fle-algo analogy - all flex-algos operate on top of a 
single LSDB, contrary to what is being proposed in MFI draft.



    MFI also seems to be a flood reduction mechanism by creating
multiple sub topology instances within a common LSDB.  There are a
number of flood reduction drafts and this seems to be another method
of achieving the same.


MFI draft proposes to keep the separate LSDB per MFI, so the above analogy is 
not correct either.

thanks,
Peter




Gyan

On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk mailto:rob...@raszuk.net>> wrote:

  Aijun,

  How multi instance is implemented is at the discretion of a vendor.
  It can be one process N threads or N processes. It can be both and
  operator may choose.

  MFI is just one process - by the spec - so it is inferior.

  Cheers,
  R.


  On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang mailto:wang...@chinatelecom.cn>> wrote:

  Hi, Robert:

  Separate into different protocol instances can accomplish the
  similar task, but it has some deployment overhead.
  MFIs within one instance can avoid such cumbersome work, and
  doesn’t affect the basic routing calculation process.

  Aijun Wang
  China Telecom


  On Feb 26, 2021, at 19:00, Robert Raszuk mailto:rob...@raszuk.net>> wrote:

  Hi Yali,

  If this was precise, then the existing multi-instance
  mechanism would be sufficient.
  [Yali]: MFI is a different solution we recommend to solve
  this same and valuable issue.


  Well the way I understand this proposal MFI is much weaker
  solution in terms of required separation.

  In contrast RFC8202 allows to separate ISIS instances at the
  process level, but here MFIs as defined must be handled by the
  same ISIS process

  This document defines an extension to
  IS-IS to allow*one standard instance*  of
  the protocol to support multiple update
  process operations.

  Thx,
  R.

  ___
  Lsr mailing list
  Lsr@ietf.org 
  https://www.ietf.org/mailman/listinfo/lsr


  ___
  Lsr mailing list
  Lsr@ietf.org 
  https://www.ietf.org/mailman/listinfo/lsr

--



*Gyan Mishra*

/Network Solutions A//rchitect /

/M 301 502-1347
13101 Columbia Pike
/Silver Spring, MD












___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak]

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 
doing ECMP I will not include those which may be a problem.



I agree that it may be a problem. Maybe it’s not the right tool for the job at 
hand. That doesn’t make it a bad tool, just the wrong one. I try not to turn 
screws with a hammer. And I try not to drive nails with a screwdriver.

I will happily stipulate that we need more tools and that these are not enough. 
 We should not reject a tool simply because it doesn’t solve all problems. 
Let’s work towards the right set of tools. Linear algebra tells us that we want 
an orthogonal set of basis vectors. What are they? Adding them one at a time is 
not horrible progress.



However my observation is precisely related to your last sentence.

Is this extension to be used with static or dynamic data ? If static all fine. 
But as William replied to me earlier link delay may be dynamically computed and 
may include queue wait time. That to me means something much different if 
Flex-Algo topologies will become dynamically adjustable. And I am not saying 
this is not great idea .. My interest here is just to understand the current 
scope.



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 and instability. We have 
chosen to charge ahead, without addressing those concerns already.


TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the 
other side this value is calculated based on multiple measurements over 
period of time and an average is used. Also, smart implementations can 
normalize the value so that a small fluctuation of the delay is not 
causing the traffic to shift or cause ECMP loss.


What is important here is that the Min Unidirectional Link Delay is a 
link characteristic, not something that is affected by the amount of 
traffic on the link or subject to queuing delay. Same applies to Maximum 
link bandwidth.


thanks,
Peter




Regards,
Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

[Peter Psenak]

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, 
2021.

Authors, please indicate wether you are aware of any IPR related to this 
document to the list.

Thanks,
Chris, Acee, (Lou and Pavan).



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 回复: IPR Poll for "Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03

[ma chenhao]

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 Routing 
based Virtual Transport Network" - draft-xie-lsr-isis-sr-vtn-mt-03


Authors,



Are you aware of any other IPR that applies to draft-xie-lsr-issi-sr-vtn-mt?



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.



Note that no IPRs have been declared - 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-xie-lsr-isis-sr-vtn-mt



Thanks,

Acee


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr