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

[Tarek Saad]

Hi Tony,

Just so we are on same page, I think you are agreeing on the overhead per MT 
(and even MI) that would be incurred using the approach proposed in I-D. 
draft-xie-lsr-isis-sr-vtn-mt to realize a forwarding treatment on a shared 
resource.

To you’re point on flex-algo producing disconnected topologies,  
I-D.draft-bestbar-lsr-spring-sa is NOT adding any **new** considerations or a 
change that would impact the behavior for computing per prefix SID paths as 
described in I-D.draft-ietf-lsr-flex-algo. It is only proposing to associate a 
SID with a forwarding treatment.

Regards,
Tarek


On 3/8/21, 9:54 AM, "Tony Przygienda" 
mailto:tonysi...@gmail.com>> wrote:

[External Email. Be cautious of content]

This argument seems fairly bogus to me. if you use IGP to flood some stuff and 
then want the distributed computation stitch it together based on IGP topology 
to get you a nexthop you end in computation which is something like Bellman or 
Dijkstra or Boruvka. Unless you have some controller distributing next-hops but 
then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information 
everywhere (you don't have to compute if you're not part of [simple check on 
adjacencies] it but you still get stuff flooded). Some people like that 
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of the 
most vexing scenarios and there MT is @ an advantage since partitioned topology 
can be easily derived (and that's BTW why it's built that way with strict 
adjacency negotiation). Reading the bestbar draft and looking @ e.g. flex algo 
I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad 
mailto:ts...@juniper.net>> wrote:
Hi authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com<mailto:jie.d...@huawei.com>> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; 
Chongfeng Xie mailto:chongfeng@foxmail.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: 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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6822__;!!NEt6yMaO-gk!W0I8TTnvfmnvtp4AbIlYuPMM8_M1XF91FAbQTNSjvXvd9Qq8qoW8C7H7OSh6fw$>

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs g

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

[Tarek Saad]

Hi authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chosen as it 
can provide the required functionality with less overhead.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda 
Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
Subject: 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


Dear Authors

Why was MT chosen and not MI for VTN underlay network slice underpinning.  MT 
instances has separate topology but not separate LSDB where MI Multi instance 
RFC 6822 has a separate LSDB for resources isolation and I think would be a 
better fit for VTN underlay provisioning.

MI
https://tools.ietf.org/html/rfc6822

Thanks

Gyan

On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda 
mailto:tonysi...@gmail.com>> wrote:

Robert ruminated:

That said I think perhaps we are indeed missing LROW WG (Local Routing 
Operations WG) where just like in GROW WG where mainly (Global) BGP operational 
aspects are discussed there could be good place to discuss operational aspects 
of link state protocols deployment and use cases. In fact perhaps it would also 
free some LSR bandwidth to really focus on protocol extensions.


+1

IGPs grew a zoo of horns and bells by now and no'one tells the operators which 
spines are poisonous ;-)

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

[图像已被发件人删除。]

Gyan Mishra

Network Solutions Architect

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



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

[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 Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Tarek Saad]

I read this draft and I support its adoption.

Regards,
Tarek


> On Dec 1, 2020, at 1:12 PM, Acee Lindem (acee) 
> 
>  wrote:

>

> This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
> and deployment prior to IETF 109 and there was generally support for WG 
> adoption. This begins a two week WG adoption call. Please indicate your 
> support or objection to WG adoption on this list prior to 12:00 AM UTC on 
> December 16th, 2020. Also, review comments are certainly welcome.

> Thanks,

> Acee





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

[Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Tarek Saad]

I am aware of an IPR that applies to this. Its disclosure is being worked on -- 
in conformance with IETF rules.

Regards,
Tarek

Juniper Business Use Only
From: Acee Lindem (acee) 
Sent: Tuesday, December 1, 2020 4:21 PM
To: 
draft-bonica-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" 
- draft-bonica-lsr-ip-flexalgo-01

Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

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.

Thanks,
Acee



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

Re: [Lsr] [spring] IETF 106 - SPRING agenda

[Tarek Saad]

Thanks Robert,

Nothing new on the bgp-ls being able to carry link state ;) -  rfc7752 even 
states it..
“ .. a mechanism by which link-state and TE
   information can be collected from networks and shared with external
   components using the BGP routing protocol..”

Thanks for sharing your initial thoughts on the proposal.

Regards,
Tarek
From: Robert Raszuk 
Date: Thursday, November 7, 2019 at 4:52 AM
To: Tarek Saad 
Cc: SPRING WG List , "lsr@ietf.org" 
Subject: Re: [spring] IETF 106 - SPRING agenda




>   Once advertised in the network using a suitable link state protocol

>   (such as OSPF, ISIS or BGP-LS),



Whow ... never imagined that BGP-LS would be called one day a "link state 
protocol" and an equal sign would be made to OSPF and ISIS.



Best,

Robert.



PS. As to the proposal in draft itself it is clearly possible - but then 
troubleshooting and operating such mixed network would be a simple nightmare.




On Thu, Nov 7, 2019 at 3:25 AM Tarek Saad 
mailto:tsaad.@gmail.com>> wrote:
Hi SPRING WG and Chairs,

We would like to request a presentation time slot for
- I-D: https://tools.ietf.org/html/draft-saad-sr-fa-link-00
- Speaker: Tarek Saad
- Desired time: 10 minutes

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