Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Peter,

The E-bit is defined as part of the L2 bundle attribute, which will be used by 
controller for path computation based on Flex-Algo and the L2 bundle 
information. This aligns with the usage of IGP L2 bundle.

Best regards,
Jie

From: Peter Psenak 
Sent: Tuesday, April 2, 2024 5:06 PM
To: Dongjie (Jimmy) ; Les Ginsberg (ginsberg) 
; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 02/04/2024 10:57, Dongjie (Jimmy) wrote:
Hi Peter,

Thanks for the quick reply.

Do you mean IGP L2 bundle should be abandoned?

Quote from RFC 8668:

“If entities external to IS-IS wish to control traffic flows on the individual 
physical links that comprise the Layer 2 interface bundle, link attribute 
information about the bundle members is required. This document introduces the 
ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle 
Members. “



no, absolutely not.

I was referring to the new E-bit.



thanks,
Peter

Best regards,
Jie

From: Peter Psenak <mailto:ppse...@cisco.com>
Sent: Tuesday, April 2, 2024 4:47 PM
To: Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; Les 
Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 02/04/2024 10:18, Dongjie (Jimmy) wrote:
Hi Peter,

Please see inline:

From: Peter Psenak <mailto:ppse...@cisco.com>
Sent: Thursday, March 21, 2024 5:39 PM
To: Dongjie (Jimmy) 
<mailto:jie.dong=40huawei@dmarc.ietf.org>;
 Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Fully agree Flex-Algo is a routing concept and works on L3 control plane, 
while it shows a gap in how to map Flex-Algos to different subset of resources 
for network slicing. Currently traffic of different Flex-Algos would share the 
same set of resources on the L3 outgoing interfaces.

The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] QoS PHB is per-hop behavior, which cannot provide end-to-end resource 
guarantee at NRP/Slice granularity. Consider the difference between DiffServ 
and IntServ. And within each NRP, QoS is still needed.

Reserving an L2 bundle member link for NRP is the approach proposed in this 
document.

Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Agree that per-hop traffic classification has many problems.

What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do 

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Peter,

Thanks for the quick reply.

Do you mean IGP L2 bundle should be abandoned?

Quote from RFC 8668:

“If entities external to IS-IS wish to control traffic flows on the individual 
physical links that comprise the Layer 2 interface bundle, link attribute 
information about the bundle members is required. This document introduces the 
ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle 
Members. “

Best regards,
Jie

From: Peter Psenak 
Sent: Tuesday, April 2, 2024 4:47 PM
To: Dongjie (Jimmy) ; Les Ginsberg (ginsberg) 
; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 02/04/2024 10:18, Dongjie (Jimmy) wrote:
Hi Peter,

Please see inline:

From: Peter Psenak <mailto:ppse...@cisco.com>
Sent: Thursday, March 21, 2024 5:39 PM
To: Dongjie (Jimmy) 
<mailto:jie.dong=40huawei@dmarc.ietf.org>;
 Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Fully agree Flex-Algo is a routing concept and works on L3 control plane, 
while it shows a gap in how to map Flex-Algos to different subset of resources 
for network slicing. Currently traffic of different Flex-Algos would share the 
same set of resources on the L3 outgoing interfaces.

The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] QoS PHB is per-hop behavior, which cannot provide end-to-end resource 
guarantee at NRP/Slice granularity. Consider the difference between DiffServ 
and IntServ. And within each NRP, QoS is still needed.

Reserving an L2 bundle member link for NRP is the approach proposed in this 
document.

Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Agree that per-hop traffic classification has many problems.

What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do this. There is no need to advertise anything to do 
what you describe, as this is all a local behavior of the node. There is no 
need to add a new E-bit, and there is not even a need to advertise affinities 
for the L2 bundle members.

[Jie] The distributed path computation is still based on the L3 
links/interfaces, the change is in the forwarding entry installation. Thanks 
for confirming it works.

The advertisement of the L2bundle information is for the controller or ingress 
nodes to perform path computation based on NRP-specific constraints and can use 
Algo-specific SIDs together with bundle member Adj-SIDs in building the SID 
list, this aligns with the usage of L2 bundle and extends its applicability to 
Flex-Algo-specific SIDs.

The E bit is to indicate the L2 bundle is working in th

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Chris,

Sorry for the delayed response. Please see inline: 

> -Original Message-
> From: Christian Hopps 
> Sent: Monday, March 25, 2024 1:08 AM
> To: Dongjie (Jimmy) 
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Dongjie (Jimmy)
> ; lsr@ietf.org;
> draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org; Les Ginsberg (ginsberg)
> 
> Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
> 
> [as wg-member]
> 
> Hi Jie,
> 
> If different topologies need to use different members of a link bundle, then 
> the
> link bundle has been incorrectly defined. You should re-bundle your links
> according to their expected topological use and then everything just works w/o
> any new tech needed. "KISS" seems to apply here.

In this proposal, an L3 link participate in multiple Flex-Algos, this is 
allowed by the Flex-Algo mechanism as defined in RFC 9350. In typical cases 
each sub-interface belongs to a different NRP, which means if each Flex-Algo 
select a separate L3 interface, these subinterfaces cannot be bundled anymore, 
and this would cause significant increase of L3 links into the network.  

Currently L2bundle allows controllers to steer traffic to a member link of the 
bundle using member link Adj-SIDs. This document extends that mechanism so that 
Flex-Algo SIDs can also be used to steer traffic to the corresponding member 
links. 

> It sounds from the discussion like you are trying to define a solution to a
> self-created problem (incorrect link-bundle definitions). Given this, I agree 
> with
> the other detractors.

As mentioned above, an alternative solution is to create separate L3 
sub-interfaces for each NRP/Flex-Algo. It works but would also introduce some 
problems. If people think this approach is also useful, we can add it to the 
document as another candidate. What do you think?

Best regards,
Jie

> 
> Thanks,
> Chris.
> 
> > On Mar 22, 2024, at 13:00, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Jie –
> >  Just a short summary from my POV.
> >  Multiple people have provided input to you as to why what you are trying
> to do won’t work.
> > I won’t repeat what has been said before.
> >  I know you really want your solution to work – but it does not.
> > If you think otherwise, I think it is only because you have not yet
> implemented/tested it – or you have not tested the problematic scenarios – I
> provided you with one easy example.
> >  This draft should not go forward – and I say that regardless as to whether
> you are headed towards Standards track or Informational. The solution you are
> advocating does not work.
> >  Thanx for the good discussion.
> > Les
> >   From: Dongjie (Jimmy) 
> > Sent: Thursday, March 21, 2024 6:32 PM
> > To: Peter Psenak (ppsenak) ; Dongjie (Jimmy)
> > ; Les Ginsberg (ginsberg)
> > ; lsr@ietf.org;
> > draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
> > Subject: RE: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
> >  Hi Peter,
> >  Please see inline:
> >  From: Peter Psenak 
> > Sent: Thursday, March 21, 2024 7:39 PM
> > To: Dongjie (Jimmy) ; Les
> > Ginsberg (ginsberg) ; lsr@ietf.org;
> > draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
> > Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
> >  Hi Jie,
> >  On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
> > Hi Les,
> >  Thanks for providing your opinion with an example.
> >  In your example, the default IGP metric is used, which is normally
> calculated based on bandwidth. While Flex-Algo can support metric types such
> as TE metric and delay.  When Flex-Algo is used as the control plane of NRP,
> usually the metric types other than IGP metric would be used. We could add
> some notes about the selection of metric type to this document. In most cases
> per Flex-Algo metric type would not be needed.
> >  Your proposal of making each member link an L3 link is an alternative
> solution, while that would bring back the problems we discussed during the L2
> bundle standardization, and can impact the network stability and scalability.
> Your second proposal (controller based path computation and construction)
> works for scenarios where strict TE-path SID-list is used to steer traffic 
> into
> specific bundle member links on each hop, while traffic with Flex-Algo prefix
> SIDs will be mixed up and ECMP among the member links of the L3 interface.
> >  So we do see there is a gap in using Flex-Algo to support NRP, and would
> like to hear feedbacks from the WG on possible solutions (including this one).
> > there is no gap in Flex-algo. Flex-algo is a routing concept and as such 
> > only
> works on L

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Les,

Sorry for the delayed response. Please see inline:

From: Les Ginsberg (ginsberg) 
Sent: Saturday, March 23, 2024 1:01 AM
To: Dongjie (Jimmy) ; Peter Psenak (ppsenak) 
; Dongjie (Jimmy) ; 
lsr@ietf.org; draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Jie –

Just a short summary from my POV.

Multiple people have provided input to you as to why what you are trying to do 
won’t work.
I won’t repeat what has been said before.

[Jie] Please take a look at the conversation I had with Peter in this thread.

I know you really want your solution to work – but it does not.
If you think otherwise, I think it is only because you have not yet 
implemented/tested it – or you have not tested the problematic scenarios – I 
provided you with one easy example.

[Jie] This solution is designed for some of the scenarios, not for all 
scenarios. For example, using bandwidth as Flex-Algo metric type is not 
recommended as you pointed out, This could be mentioned in next version of the 
draft.

This draft should not go forward – and I say that regardless as to whether you 
are headed towards Standards track or Informational. The solution you are 
advocating does not work.

[Jie] Please see Peter’s comments on this solution, it works.

Thanx for the good discussion.

[Jie] Thank you for the discussion.

Best regards,
Jie

   Les


From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Thursday, March 21, 2024 6:32 PM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
Dongjie (Jimmy) 
mailto:jie.dong=40huawei@dmarc.ietf.org>>;
 Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: RE: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Peter,

Please see inline:

From: Peter Psenak mailto:ppse...@cisco.com>>
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) 
mailto:jie.dong=40huawei@dmarc.ietf.org>>;
 Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is not 
changed. The gap is in using Flex-Algo for NRP in some scenarios.



The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] The concept of NRP is different from QoS, and QoS can be used within an 
NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset of 
resources allocated to an NRP, thus Flex-Algo specific SR SID also needs to be 
able to steer traffic to the subset of resources of the associated NRP.



Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Yes people probably do not want to do per-hop classification for NRPs.



What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because b

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Peter,

Please see inline:

From: Peter Psenak 
Sent: Thursday, March 21, 2024 5:39 PM
To: Dongjie (Jimmy) ; Les Ginsberg 
(ginsberg) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Fully agree Flex-Algo is a routing concept and works on L3 control plane, 
while it shows a gap in how to map Flex-Algos to different subset of resources 
for network slicing. Currently traffic of different Flex-Algos would share the 
same set of resources on the L3 outgoing interfaces.

The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] QoS PHB is per-hop behavior, which cannot provide end-to-end resource 
guarantee at NRP/Slice granularity. Consider the difference between DiffServ 
and IntServ. And within each NRP, QoS is still needed.

Reserving an L2 bundle member link for NRP is the approach proposed in this 
document.

Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Agree that per-hop traffic classification has many problems.

What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do this. There is no need to advertise anything to do 
what you describe, as this is all a local behavior of the node. There is no 
need to add a new E-bit, and there is not even a need to advertise affinities 
for the L2 bundle members.

[Jie] The distributed path computation is still based on the L3 
links/interfaces, the change is in the forwarding entry installation. Thanks 
for confirming it works.

The advertisement of the L2bundle information is for the controller or ingress 
nodes to perform path computation based on NRP-specific constraints and can use 
Algo-specific SIDs together with bundle member Adj-SIDs in building the SID 
list, this aligns with the usage of L2 bundle and extends its applicability to 
Flex-Algo-specific SIDs.

The E bit is to indicate the L2 bundle is working in the exclusive mode (rather 
than load balancing), which means the Flex-Algo SIDs can be used to steer 
traffic to the corresponding member links.

Best regards,

Jie



I see no need for this draft.

thanks,
Peter





Best regards,
Jie

From: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07


Jie -



Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.



Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Gyan,

Sorry for the delayed response, please see some replies inline:


From: Gyan Mishra 
Sent: Friday, March 22, 2024 1:04 PM
To: Dongjie (Jimmy) 
Cc: Les Ginsberg (ginsberg) ; Peter Psenak 
; draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie

I thought about this and how applying your L2 member link extension to SR algo 
would work and would it be feasible or not.

I believe subinterface would work since each subinterface has an L3 logical IP 
on it so could map multiple NRPs to multiple L3 sub interfaces and that would 
work as each subinterface becomes a ECMP next hop for sr algo sr-mpls prefix 
sid steered path.

[Jie] Making each sub-interface an L3 logical interface could work, while an 
potential issue is the increased number of L3 links in the network, which 
results in the problems as discussed when IGP L2bundle was introduced. If WG 
thinks it is useful, we can add descriptions about the L3 logical interface 
based approach.

Let’s say for example you create a network slice and allocate a NRP ID which 
maps to a subset of links that belong to a sub topology and in a case where the 
subset of links have multiple link coloring being part of multiple NRPs 
depicting a degree of isolation and other links let’s say being part of a 
single NRP total isolation, but now wanting to be able to extend the NRP sub 
topology concept to not just L3 links but L2 member links that are part of 
bundles being used within the NRP SR Algo sub topology.

[Jie] Yes L2bundle is used here to provide the required resource partitioning 
and reduce the number of L3 interfaces, without changing the SR Flex-Algo 
sub-topology computation.

SR Algo in SR-MPLS used a prefix sid next hop endpoint constraint defined for 
the NRP on egress PE  with discrete label x advertise in IGP for sub topology 
to be instantiated as an ECMP loose hops steered path from the SR source node 
is a L3 NH construct is the problem.

SR Algo in SRv6 used a locators advertised in IGP by each nodes link coloring 
for the NRP to instantiate ECMP loose hops steered path from the SR source node 
along the sub topology to egress PE L3 NH locator endpoint.

[Jie] Per-Algo SIDs are installed in forwarding plane to steer traffic through 
the outgoing interfaces. If an outgoing interface is partitioned into L2 member 
links as defined in this document, traffic will be steered to the member link 
corresponding to the Flex-Algo on the outgoing interface.

The construct to build the SR Algo sub topology for both SR MPLS is L3 NH 
prefix sid or SRv6 NH locator is the issue with extending SR Algo to support L2 
member links.

[Jie] The topology used for Flex-Algo path computation is still L3, just the 
forwarding entries associated with the Algo-specific SIDs are the corresponding 
member links. In this case the Algo-specific SIDs are resource aware segments.

When you think of QOS/PHB that applies to L3 per next hop basis queuing as well 
for NRP resources and not L2. Even if H-QOS was used with interfaces and 
subinterfaces it would all be L3 and not L2 interfaces and subinterfaces.

[Jie] IMO the NRP resources could be instantiated as either L3 interfaces, L2 
interfaces, or a subset of queue/buffer resources under the interface. The 
difference of using L3 or L2 is mainly in how NRP attributes are advertised in 
control plane.

Hope this helps.

Best regards,
Jie

Kind Regards


[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347



On Thu, Mar 21, 2024 at 9:32 PM Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Peter,

Please see inline:

From: Peter Psenak mailto:ppse...@cisco.com>>
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability an

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Peter,

Please see inline:

From: Peter Psenak 
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) ; Les Ginsberg 
(ginsberg) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is not 
changed. The gap is in using Flex-Algo for NRP in some scenarios.



The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] The concept of NRP is different from QoS, and QoS can be used within an 
NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset of 
resources allocated to an NRP, thus Flex-Algo specific SR SID also needs to be 
able to steer traffic to the subset of resources of the associated NRP.



Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Yes people probably do not want to do per-hop classification for NRPs.



What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do this. There is no need to advertise anything to do 
what you describe, as this is all a local behavior of the node. There is no 
need to add a new E-bit, and there is not even a need to advertise affinities 
for the L2 bundle members.

[Jie] To me there is not change to the routing decision in L3. The member link 
is still part of the L3 outgoing interface. And the advertisement of the bundle 
member link information is to allow the controller or the ingress node to do TE 
path computation take the individual member links into consideration, this 
aligns with the usage of the L2 bundle as defined in their RFCs.

Best regards,

Jie



I see no need for this draft.

thanks,
Peter





Best regards,
Jie

From: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) <mailto:jie.d...@huawei.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org>
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07


Jie -



Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.



Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple topology (Layer 3 links):



B

  /   \

A   D

 \   /

C





All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total bandwidth 
of the bundle links are the same.

On link B-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 100 Mb of bandwidth.

On link C-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 1 GB of bandwidth.

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

Best regards,
Jie

From: Les Ginsberg (ginsberg) 
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07


Jie -



Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.



Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple topology (Layer 3 links):



B

  /   \

A   D

 \   /

C





All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total bandwidth 
of the bundle links are the same.

On link B-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 100 Mb of bandwidth.

On link C-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 1 GB of bandwidth.



The L3 SPF associated with algo 128 utilizes Layer 3 metric advertisements. 
Based on that, traffic from A to D will be equally balanced via B and C.

However, what you intend is that when algo 128 traffic is forwarded by B it 
will utilize a 100 Mb link – whereas when algo 128 traffic is forwarded by C it 
will utilize a 1 Gb link.

Clearly the ECMP traffic flow which is the output of the L3 SPF is sub-optimal.



How could this be fixed?



1)Do not use L2 bundles on B and C. Make each bundle member an L3 link and run 
IS-IS on the Layer 3 interfaces. In such a case different L3 metrics can be 
advertised for each L3 link and Flex Algo 128 can be associated only with the 
desired L3 link on C and D.

Standard flex-algo as defined in RFC 9350 works and requires no modifications.



2)Do not use L3 routing/flex algo. Define some other mechanism to mark packets 
in a way that the forwarding recognizes as mapping to the appropriate L2 link.

The L2 bundle advertisements provided by IS-IS as per RFC 8668 can be used by 
this (external to IS-IS) mechanism.

For example this mechanism could use the admin group advertised for each 
L2Bundle member to determine the mapping between an NRP and a link.

All of the functionality required is already defined in RFC 8668 – the only 
thing you need to define is this new mechanism – which is not part of IS-IS and 
therefore does not belong in an LSR draft.



NOTE: Please do not suggest that a different metric-type can be used for each 
Flex-Algo. Such an approach does not scale as it requires as many metric-types 
as Flex-Algos – which we do not have. 



What you MUST NOT do is use L3 routing to make a routing decision for a 
topology which is not part of the input to the routing decision process. But 
that is exactly what you are proposing in this draft.



Hope this example is clear.



As regards the clarity of Section 4, that section simply says (using the 
SR-MPLS text):



“A forwarding entry MUST be installed in the forwarding plane using the MPLS 
label that corresponds to the Prefix-SID associated with the Flex-algorithm 
corresponding to the NRP.”



But this entry must have next hops which include only the L2 links associated 
with the NRP mapped to Flex-algo 128. How this is done is not described – but 
as it requires using information advertised in the L2 Bundle Member Descriptors 
this clearly cannot be done by IS-IS w/o violating RFC 8668. IS-IS will simply 
attempt to install a forwarding entry based on the L3 topology – which will 
indicate to use the L3 link. How this forwarding entry is discarded/overwritten 
is not specified. But, this is a problem which should never need to be solved.



   Les







> -Original Message-

> From: Dongjie (Jimmy) mailto

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Dongjie (Jimmy)]

Hi Ketan,

Thanks for sharing the use cases of this new flag. It would be helpful if some 
brief description could be added to the document.

Best regards,
Jie

From: Ketan Talaulikar 
Sent: Thursday, March 21, 2024 1:18 AM
To: Acee Lindem 
Cc: Dongjie (Jimmy) ; lsr ; 
draft-chen-lsr-anycast-f...@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Acee/Jie,

The most common users of the anycast property of a prefix are external 
controllers/PCE that perform path computation exercises. As an example, knowing 
the anycast prefix of a pair of redundant ABRs allows that anycast prefix SID 
to be in a SRTE path across the ABRs with protection against one of those ABR 
nodes going down or getting disconnected. There are other use cases. An example 
of local use on the router by IGPs is to avoid picking anycast SIDs in the 
repair segment-list prepared for TI-LFA protection - this is because it could 
cause an undesirable path that may not be aligned during the FRR window and/or 
post-convergence.

That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the burden of 
this justification of an use-case, I hope the same burden would not fall on 
this OSPFv2 document simply because it only has this one specific extension.

Thanks,
Ketan


On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Jie,

I asked this when the flag was added to IS-IS and then to OSPFv3. I agree it 
would be good to know why knowing a prefix is an Anycast address is "useful" 
when the whole point is that you use the closest one (or some other criteria).

Thanks,
Acee

> On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
> mailto:jie.d...@huawei.com>> wrote:
>
> Hi authors,
>
> I just read this document. Maybe I didn't follow the previous discussion, but 
> it seems in the current version it does not describe how this newly defined 
> flag would be used by the receiving IGP nodes?
>
> Best regards,
> Jie
>
> -Original Message-
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Acee Lindem
> Sent: Wednesday, March 20, 2024 4:43 AM
> To: lsr mailto:lsr@ietf.org>>
> Cc: 
> draft-chen-lsr-anycast-f...@ietf.org<mailto:draft-chen-lsr-anycast-f...@ietf.org>
> Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
> advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
> This starts the Working Group adoption call for draft-chen-lsr-anycast-flag. 
> This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4 
> prefixes to align with IS-IS and OSPFv3.
>
> Please send your support or objection to this list before April 6th, 2024.
>
> Thanks,
> Acee
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org<mailto: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] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Les,

Thanks for the review and comments. 

Please see some replies inline:

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Thursday, March 21, 2024 7:32 AM
> To: lsr@ietf.org; draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
> Subject: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
> 
> This draft discusses how to use flex-algo in support of Network Resource
> Partitions (NRPs). In particular, it proposes to use a combination of L3 
> links and
> L2 Bundle member links as the topology associated with a given NRP. In those
> cases where an L3 link is using an L2 bundle and individual bundle members
> are "assigned" to different NRPs, it then proposes to associate the parent L3
> link with multiple flex-algos. The intent seems to be to utilize the L3 algo
> specific SIDs to assign the traffic to subsets of the L2 Bundle members.

Your reading of the intent of this document is correct. 

With the proposed mechanism, traffic with Flex-Algo specific SIDs could be 
steered to different partitions of the L3 link resources. 

The only thing I'd like to mention is the L2 bundle members could be virtual or 
physical, they are just used to represent different subsets of the link 
resources.


> This is extremely problematic.
> 
> The output of the L3 algo-specific SPF will be to install nexthops pointing 
> to the
> L3 interface for packets which arrive with the L3 algo specific SID. But 
> since the
> intent is to only forward traffic for a given algo specific SID via specific 
> L2
> Bundle members, the L3 forwarding entries will have to be overwritten - in a
> manner not specified by the draft.

Section 4 of this document specifies the required forwarding plane behavior and 
the forwarding entry installation.


> The implementation complexities this introduces arise because the proposed
> solution attempts to use a Layer 3 technology (flex-algo) to control the use 
> of
> L2 links. This should not be done.

In the proposed mechanism, Flex-Algo is still used for constraint path 
computation, and only the L3 links attributes are used in the computation. The 
L2 member links are only to partition the resources used by different Flex-Algo 
traffic. 


> Indeed, even independent of flex-algo, trying to use a Layer 3 routing 
> protocol
> to control traffic flow on an L2 sub-topology is broken.
> It means that the L2 bundles have been improperly defined for use by the L3
> routing protocol.

There is no routing computation based on the "L2 sub-topology", as L2 bundle 
member links are not visible in the L3DB. All the Flex-Algo computation is 
based on the attributes of L3 links.


> RFC 8668 defines the advertisements of L2 Bundle member link attributes by
> IS-IS. The introduction of RFC 8668 states:
> 
> "...the new advertisements defined in this document are intended to be
> provided to external (to IS-IS) entities."
> 
> This means these advertisements are not to be used by the routing protocol
> itself. The association of these advertisements with the Layer 3 SIDs defined 
> by
> Flex-Algo is a clear violation of the intended use as stated by RFC 8668.

As stated above, L2 bundle link attributes are not used in path computation. 
The Flex-Algo specific SIDs still point to the L3 interface based on that 
computation. The only change is that a Flex-Algo SID can further points to the 
resource of an L2 member link (consider it as a subset of the resource of the 
L3 link if that is easier to understand). So the L2 bundle information is only 
used for associating different Flex-Algo SIDs with different subsets of 
resources of a l3 link.  


> This draft should be abandoned.
> 
> NOTE: None of the points above should be interpreted to mean that flex-algo
> cannot be used in support of NRPs. (Whether that is a good idea or not is out
> of scope for this discussion).

AFAIK people are talking about using Flex-Algo to support NRPs. This document 
provides a solution to meet their needs. 


> But the proper way to do that is when the NRP maps to an L3 topology. Such a
> usage is fully supported by RFC 9350 and there is no need to write an
> additional document to define how this is to be done.

In some cases it is possible to map different NRPs to non-overlapping L3 
sub-topologies, while in many other cases the same L3 link needs to participate 
in multiple NRPs, each of which is assigned with a subset of the link 
resources. The latter case cannot be supported by RFC 9350, and it is the 
target of this document. 


> In cases where an NRP maps to an L2 topology, some other mechanism needs
> to be defined as to how forwarding entries for a given NRP are determined and
> installed. Such a mechanism would qualify as "external to IS-IS" and therefore
> could make use of RFC 8668 advertisements.

This document also provides descriptions about this. As I mentioned it is after 
L3 computation, and makes use of the L2 bundle information. 


> But attempts to utilize the Layer 3 Flex-Algo 

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Dongjie (Jimmy)]

Hi authors,

I just read this document. Maybe I didn't follow the previous discussion, but 
it seems in the current version it does not describe how this newly defined 
flag would be used by the receiving IGP nodes? 

Best regards,
Jie

-Original Message-
From: Lsr  On Behalf Of Acee Lindem
Sent: Wednesday, March 20, 2024 4:43 AM
To: lsr 
Cc: draft-chen-lsr-anycast-f...@ietf.org
Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06


This starts the Working Group adoption call for draft-chen-lsr-anycast-flag. 
This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4 
prefixes to align with IS-IS and OSPFv3. 

Please send your support or objection to this list before April 6th, 2024. 

Thanks,
Acee


___
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 Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Dongjie (Jimmy)]

Hi Acee and Liyan,

Please see some replies inline with [Jie] :

From: Acee Lindem [mailto:acee.i...@gmail.com]
Sent: Sunday, March 10, 2024 5:37 AM
To: Liyan Gong mailto:gongli...@chinamobile.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Dongjie 
(Jimmy) mailto:jie.d...@huawei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>; ketan Talaulikar 
mailto:ketant.i...@gmail.com>>
Subject: Re: [Lsr] WG Adoption Call 
-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

All,

With respect to the naming of the OSPF constants, I think we should go with:

 LSLinkInfinity- 0x
 MaxReachableLinkMetric - 0xfffe

LSLinkInfinity is analogous to LSInfinity.

[Jie]  This is OK to me.



See inline.




On Mar 2, 2024, at 06:16, Liyan Gong 
mailto:gongli...@chinamobile.com>> wrote:


Hi Gyan and Jie,

I am not entirely sure if the suggestions from Ketan in previous email can 
address these two concerns. If not fully addressed, please feel free to let us 
know.

Overall, this feature is applicable to all FAs, including FA0. The next version 
will further elaborate on the relationships between new features and FAs, as 
well as optimize the use-case descriptions and corresponding name to reflect 
"Unreachable" in a way that is easier to understand.

Appreciate everyone's discussion. It is very helpful.


[Jie] Thanks, this aligns with my understanding: it applies to all SPF 
computations (including Flexible Algorithms) which make use of IGP metric. And 
it would be good to replace unreachable with some more accurate description.





Best Regards,

Liyan




邮件原文
发件人：Gyan Mishra  mailto:hayabusa...@gmail.com>>
收件人："Dongjie (Jimmy)" 
mailto:jie.dong=40huawei@dmarc.ietf.org>>
抄　送: Yingzhen Qu  mailto:yingzhen.i...@gmail.com>>,lsr 
 mailto:lsr@ietf.org>>,lsr-chairs  
mailto:lsr-cha...@ietf.org>>
发送时间：2024-03-01 11:27:32
主题：Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)
Hi Jie

Some answers in-line

On Thu, Feb 29, 2024 at 2:31 AM Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Yingzhen,

I’ve read the latest version of this document and support its adoption.  It is 
a useful feature in general to exclude some of the links from SPF  computation.

I also have some comments for the authors to consider, they can be solved after 
the adoption.


1.   I’m not sure the purpose is to advertise an unreachable link in OSPF, 
from the use cases in the draft, the link is still reachable and  can be used 
for some services, just it needs be excluded from normal SPF calculation. If 
this is correct, it is better the title of the draft and the name of the new 
capability Flag need to be updated to reflect this.

LSLinkInfinity would always indicate the link is unreachable. However, there is 
no real need to advertise it for other services since in these cases the 
advertisement is optional.

[Jie] IMO once LSLinkInfinity is advertised for a link, it would impact all 
services which rely on SPF computation based on IGP metric.  Regarding “for 
other services the advertisement is optional”, do you mean other services would 
rely on metric-types other than IGP metric? This is true for services which use 
TE paths, while there maybe issue with Flex Algorithm (as discussed below).

 Gyan> I agree with you and that is as well stated in the draft that 
MaxLinkMetric (0x) does not exclude the link from SPF and thus requires RI 
LSA with capability bit set for MaxLinkMetric (0x) for link to be excluded 
from SPF. Maybe “OSPF RI Capability LSA”.

I think the capability should be LSLinkInfinity support.

[Jie] This is OK.




2.   In the Flex-Algo use case, if the metric of a link is set to 
MaxLinkMetric (0x) to exclude it from normal SPF computation, while a  
Flex-Algo is defined to use the same metric type for path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x be used in the Flex-Algo computation? In other word, 
the interaction between  this new feature and Flex-Algo needs to be further 
elaborated.
Gyan>  I agree that the RI LSA capability flag for MaxLinkMetric (0x) 
is applicable to base Algo 0 and any Algo.  However AFAIK you would have to 
explicitly set the RI flag the particular Algo.  The use case described in this 
draft is when you are using flex algo for network slicing meaning you have both 
algo 0 and 128 on the same links and not a separate sub topology and in that 
case in order to avoid best effort traffic from going over the same link used 
for algo 128  you would need to use this RI capability flag.  This concept we 
have talked about comes into play of degree of network slicing and isolation to 
meet SLO SLE  requiremen

[Lsr] FW: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-07.txt

[Dongjie (Jimmy)]

Hi all, 

A new revision of draft-zhu-lsr-isis-sr-vtn-flexalgo has been submitted. It 
describes a Flexible Algorithm based mechanism to build SR based NRPs in some 
network scenarios. 

There are several changes since its last presentation in IETF 114:

1. The background of this work and its relationship with the IETF network slice 
draft is described. 

2. Following the consensus of TEAS WG about terminology alignment between VTN 
and NRP, the VTNs in this document are now replaced by NRP.

3. The approach to correlate a subset of link resources with a Flex-Algo is 
elaborated. 

4. The targeted scenario and the scalability considerations of the proposed 
mechanism is described.

5. Editorial changes to improve the readability. 

As always review and comments are welcome. 

Best regards,
Jie (on behalf of the authors)

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, March 4, 2024 3:30 PM
To: Dongjie (Jimmy) ; Yongqing Zhu 
; Huzhibo 
Subject: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-07.txt

A new version of Internet-Draft draft-zhu-lsr-isis-sr-vtn-flexalgo-07.txt has 
been successfully submitted by Yongqing Zhu and posted to the IETF repository.

Name: draft-zhu-lsr-isis-sr-vtn-flexalgo
Revision: 07
Title:Using Flex-Algo for Segment Routing (SR) based Network Resource 
Partition (NRP)
Date: 2024-03-04
Group:Individual Submission
Pages:10
URL:  
https://www.ietf.org/archive/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-07.txt
Status:   https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Abstract:

   Enhanced VPNs aim to deliver VPN services with enhanced
   characteristics, such as guaranteed resources, latency, jitter, etc.,
   so as to support customers requirements for connectivity services
   with these enhanced characteristics.  Enhanced VPN requires
   integration between the overlay VPN connectivity and the
   characteristics provided by the underlay network.  A Network Resource
   Partition (NRP) is a subset of the network resources and associated
   policies on each of a connected set of links in the underlay network.
   An NRP could be used as the underlay to support one or a group of
   enhanced VPN services.

   In some network scenarios, each NRP can be associated with a unique
   Flexible Algorithm (Flex-Algo), which can provide constraint-path
   computation based on the customized topological constraints.  This
   document specifies a mechanism to build Segment Routing (SR) based
   NRPs by combining SR Flex-Algo and IGP L2 bundles with minor
   extensions.



The IETF Secretariat


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

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Dongjie (Jimmy)]

Hi Yingzhen,

I’ve read the latest version of this document and support its adoption.  It is 
a useful feature in general to exclude some of the links from SPF computation.

I also have some comments for the authors to consider, they can be solved after 
the adoption.


1.   I’m not sure the purpose is to advertise an unreachable link in OSPF, 
from the use cases in the draft, the link is still reachable and can be used 
for some services, just it needs be excluded from normal SPF calculation. If 
this is correct, it is better the title of the draft and the name of the new 
capability Flag need to be updated to reflect this.



2.   In the Flex-Algo use case, if the metric of a link is set to 
MaxLinkMetric (0x) to exclude it from normal SPF computation, while a 
Flex-Algo is defined to use the same metric type for path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x be used in the Flex-Algo computation? In other word, 
the interaction between this new feature and Flex-Algo needs to be further 
elaborated.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)


Hi,



This email begins a 2 week WG adoption poll for the following draft:

https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/



Please review the document and indicate your support or objections by March 
8th, 2024.

Authors and contributors, please respond to the list indicating whether you are 
aware of any IPR that applies to the draft.

Thanks,

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

Re: [Lsr] [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06

[Dongjie (Jimmy)]

Hi Acee and Chongfeng,

First of all, as a coauthor I support to progress this document to publication.

Please see some replies inline:


发件人：Chongfeng Xie 
收件人：Acee Lindem ;lsr ;teas 
;spring 
时 间：2024-01-20 10:44:46
主 题：Re: [Lsr] [spring] Shepherd's Review of "Applicability of IS-IS 
Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" 
- draft-ietf-lsr-isis-sr-vtn-mt-06

Hi Acee,
Many thanks for your review and suggestions. I agree with them and will update 
the draft accordingly.
Please see some further replies inline [Chongfeng]:


From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of Acee Lindem
Sent: Saturday, January 20, 2024 2:42 AM
To: Lsr mailto:lsr@ietf.org>>; 
t...@ietf.org; spr...@ietf.org
Subject: [spring] Shepherd's Review of "Applicability of IS-IS Multi-Topology 
(MT) for Segment Routing based Network Resource Partition (NRP)" - 
draft-ietf-lsr-isis-sr-vtn-mt-06

Speaking as WG Member and Document Shepherd:


I have reviewed the document and have three comments.

  1. The document can go forward implying that 
draft-dong-lsr-sr-enhanced-vpn-10 is the accepted solution for supporting 
higher scale of NRPs. While the reference is informative, the text implies 
this. I’d remove the reference altogether and this is reflected in my comments.
[Chongfeng]: This is OK, we will follow this change in next revision.

  2. To support NRPs in IS-IS, three pieces are required - IS-IS SR (MPLS 
and SRv6), IS-IS Multi-topology, and the SR resource-aware segment. The latter 
is not being progressed in SPRING yet. If it is not accepted, the draft will be 
stranded on awaiting publication. I’ve added the SPRING WG to the to list.
[Chongfeng] Understood. Resource-aware segments is a WG document and IMO it has 
been stable for a while, hopefully it will progress quickly in SPRING.
[Jie] Yes the resource-aware segments draft is stable and the plan is to move 
it to WG last call soon.

  3. There is design principle phrasing in 
draft-ietf-teas-nrp-scalability-03 which discourage the usage of “any” 
IGP-based solution (as Les commented). If you read the entire document, this is 
not the case and I’d suggest these principles be qualified to match the intent. 
  Since there are common authors on both documents, I’d hope this could be 
accomplished.
[Chongfeng] I will leave this to the co-author of the nrp-scalability draft to 
comment, personally I agree with your reading of that document.
[Jie] Speaking as coauthor of the NRP scalability draft, the intention of the 
design principle section is to show that there are possible limitations in 
control protocols in supporting a large number of NRPs, and some optimization 
needs to be considered, while discouraging the usage of “any” IGP-based 
solution is not the purpose.  Also, that text is still open for further 
refinement.

See the attached diff for editorial comments and addressing #1.
[Chongfeng] Thanks a lot for providing the diff.

Speaking as LSR WG Co-chair:

Of these comments, #1 is easy to remedy and #3 is on the other TEAS document. 
IMO, #2 remains the only potential blocker to moving forward with publication. 
I’d solicit others opinions on this point. While 
draft-ietf-spring-resource-aware-segments-08 simply defines the semantics for 
resource-aware segments, it is not certain that it will go forward and it seems 
to be critical to draft-ietf-lsr-isis-sr-vtn-mt.
[Chongfeng] Understood. It would be efficient if both documents could move 
forward in parallel.
[Jie] Agree, that would be perfect.
Best regards,
Jie

Thanks,
Acee


Best regards
Chongfeng



> On Jan 8, 2024, at 5:50 PM, Acee Lindem 
> mailto:acee.i...@gmail.com>> wrote:
>
> This begins a two week LSR Working Group last call for the “Applicability of 
> IS-IS Multi-Topology (MT) for Segment Routing based Network Resource 
> Partition (NRP)”. Please express your support or objection prior to Tuesday, 
> January 23rd, 2024.
>
> Thanks,
> Acee


___
spring mailing list
spr...@ietf.org
https://www.ietf.org/mailman/listinfo/spring


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

Re: [Lsr] IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)"

[Dongjie (Jimmy)]

Hi Acee,

No, I'm not aware of any IPR that applies to this document.

Best regards,
Jie

> -Original Message-
> From: Acee Lindem [mailto:acee.i...@gmail.com]
> Sent: Tuesday, January 9, 2024 6:43 AM
> To: draft-ietf-lsr-isis-sr-vtn...@ietf.org
> Cc: Lsr 
> Subject: IPR Poll for WG Last Call of "Applicability of IS-IS Multi-Topology 
> (MT)
> for Segment Routing based Network Resource Partition (NRP)"
> 
> Co-Authors,
> 
> Are you aware of any IPR that applies to draft-ietf-lsr-isis-sr-vtn-mt-06.
> 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 been disclosed in conformance with IETF rules.
> 
> Thanks,
> Acee

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

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Dongjie (Jimmy)]

Hi authors,

I’ve read both the draft and the recent discussion on the list. IMO Bruno’s 
concern is reasonable.

As MP-TLV is not the default behavior for all TLVs specified in existing RFCs, 
operator has to be careful when enabling the MP-TLV behavior for existing TLVs, 
especially for TLVs which are related to IGP route computation. While the risk 
may be less for TLVs which are not related to IGP computation.

Thus it would be helpful if the document could separate the default behavior 
for TLVs related to route computation, and TLVs which are not related to route 
computation.

Another point is whether the MP-TLV mechanism should be considered as short 
term or long term approach. If it is just a short term mechanism to accommodate 
existing implementations, do we need a long term approach?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com
Sent: Thursday, November 30, 2023 6:51 PM
To: Tony Li ; draft-pkaneria-lsr-multi-...@ietf.org
Cc: Yingzhen Qu ; lsr ; Aijun Wang 

Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

Hi authors,

Ø  We are documenting existing behavior, codifying what we believe most 
implementations are already doing

Could the authors share with the WG what are those existing behaviors (TLVs 
supporting MP-TLV) and implementations?

Many be this is a reason for some disconnect as
-   On one hand, if all implementations already support MP-TLV for all TLVs 
indicated in this draft, then there is less deployment issues/risks. (Although 
there are still some risks as not all nodes will get the support at the same 
time, in particular for legacy platforms which will lack the MP TLV support for 
years)
-   On the other hand, if only a couple of implementations support MP-TLV 
for a couple of TLVs,  the risk seems much higher.

If this is not known (1), we can’t assume that this is safe and deployable 
without risk.

(1) or not sharable for some reasons, although a priori vendors should be proud 
of their innovations

Ø  If the MP-TLV support capability declaration  doesn’t mean support all 
relevant TLVs, and conform to the draft can’t assure the interoperability, 
then, what the purpose of this draft?
Same question with :s/draft/capability
Although I believe I had already raised that point.

Regards,
--Bruno

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Thursday, November 30, 2023 5:06 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)


Hi Aijun,

If the MP-TLV support capability declaration  doesn’t mean support all relevant 
TLVs, and conform to the draft can’t assure the interoperability, then, what 
the purpose of this draft?


We are documenting existing behavior, codifying what we believe most 
implementations are already doing, and documenting the direction that we think 
we should be going.


If you persist this direction, as proposed by Bruno, I think that documents the 
capabilities(includes the definition of the key) for every TLV in one Yang 
file(draft-isis-pics-multi-TLV”?) maybe more better.


Then YANG model for reporting capabilities is a mostly orthogonal document.


The operator can compare such yang files from different vendor, and if they 
support the multipart of the same TLV, and the key is same, then the operator 
can safely enable the sending and receiving of the multi-part of this TLV.


That alone is not sufficient.


Or else, we should think other solution to solve this issue.


There is no other solution.

Regards,
Tony





Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Dongjie (Jimmy)]

Robert,

We are on the same page. What I said was “summarize the common parts, and 
highlight their differences”.

-Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, August 31, 2023 5:36 PM
To: Dongjie (Jimmy) 
Cc: Les Ginsberg (ginsberg) ; Huzhibo 
; Peter Psenak (ppsenak) ; linchangwang 
; Acee Lindem ; lsr 
; draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

>  it would be helpful to summarize the common parts of the two solutions,

Actually IMO it would be much more helpful to summarise differences of both 
solutions not common parts.

Thx,
r.



On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Les and Robert,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Robert Raszuk
Sent: Thursday, August 31, 2023 4:19 PM
To: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>
Cc: Huzhibo 
mailto:40huawei@dmarc.ietf.org>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 
linchangwang mailto:linchangwang.04...@h3c.com>>; 
Acee Lindem mailto:acee.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; 
draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org<mailto:draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org>
Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Hi Les,

> But existing implementations will NOT ignore a prefix reachability 
> advertisement just because
> it has a source Router ID set to 0 as 
> draft-wang-lsr-prefix-unreachable-annoucement defines.

True, but let's do not forget the bigger picture here. The dst is already 
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the new 
trigger.

[Jie] Agreed. Consider the existence of the summary route, advertising 
Max_Metric for a prefix covered by the summary route will not make it 
unreachable. A router needs to either understand the new flags as defined in 
draft-ppsenak, or understand the semantic of the NULL originator as specified 
in draft-wang to behave accordingly. This make me wonder whether it is still 
necessary to set the metric of that prefix to Max?

After several rounds of update, to me the two solutions becomes similar in 
principle , just choose different ways to encode the trigger information.


Dear LSR chairs,

I am not sure what harm would it make to start WG adoption call on both drafts 
and see the results.

[Jie] This sounds like a reasonable suggestion.

And since the WG has been discussing this problem and the two solution drafts 
for a while, it would be helpful to summarize the common parts of the two 
solutions, and highlight their difference, so that people can understand the 
current state and make their decision.

Best regards,
Jie

So far I am not seeing strong and uniform adoption support for either one :)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo 
> mailto:40huawei@dmarc.ietf.org>>

> Sent: Wednesday, August 30, 2023 6:33 PM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
> Peter Psenak (ppsenak)

> mailto:ppse...@cisco.com>>; linchangwang 
> mailto:linchangwang.04...@h3c.com>>;

> Acee Lindem mailto:acee.i...@gmail.com>>; lsr 
> mailto:lsr@ietf.org>>

> Cc: 
> draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org<mailto:draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org>

> Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix

> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

>

> Hi Les:

>

> I think you may have connected something. Existing routers, on receiving a

> prefix reachability advertisement with a

> U-Flag described in 
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>

> ureach-prefix-announce/<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
>  also will interpret that prefix as being reachable.



[LES:] This statement is incorrect.

RFC 5305 states:





If a prefix is advertised with a metric larger then MAX_PATH_METRIC

   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

   during the normal SPF computation.  This allows advertisement of a

   prefix for purposes other than building the normal IP rou

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Dongjie (Jimmy)]

Hi Les and Robert,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, August 31, 2023 4:19 PM
To: Les Ginsberg (ginsberg) 
Cc: Huzhibo ; Peter Psenak (ppsenak) 
; linchangwang ; Acee Lindem 
; lsr ; 
draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Hi Les,

> But existing implementations will NOT ignore a prefix reachability 
> advertisement just because
> it has a source Router ID set to 0 as 
> draft-wang-lsr-prefix-unreachable-annoucement defines.

True, but let's do not forget the bigger picture here. The dst is already 
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the new 
trigger.

[Jie] Agreed. Consider the existence of the summary route, advertising 
Max_Metric for a prefix covered by the summary route will not make it 
unreachable. A router needs to either understand the new flags as defined in 
draft-ppsenak, or understand the semantic of the NULL originator as specified 
in draft-wang to behave accordingly. This make me wonder whether it is still 
necessary to set the metric of that prefix to Max?

After several rounds of update, to me the two solutions becomes similar in 
principle , just choose different ways to encode the trigger information.


Dear LSR chairs,

I am not sure what harm would it make to start WG adoption call on both drafts 
and see the results.

[Jie] This sounds like a reasonable suggestion.

And since the WG has been discussing this problem and the two solution drafts 
for a while, it would be helpful to summarize the common parts of the two 
solutions, and highlight their difference, so that people can understand the 
current state and make their decision.

Best regards,
Jie

So far I am not seeing strong and uniform adoption support for either one :)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo 
> mailto:40huawei@dmarc.ietf.org>>

> Sent: Wednesday, August 30, 2023 6:33 PM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
> Peter Psenak (ppsenak)

> mailto:ppse...@cisco.com>>; linchangwang 
> mailto:linchangwang.04...@h3c.com>>;

> Acee Lindem mailto:acee.i...@gmail.com>>; lsr 
> mailto:lsr@ietf.org>>

> Cc: 
> draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org

> Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix

> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

>

> Hi Les:

>

> I think you may have connected something. Existing routers, on receiving a

> prefix reachability advertisement with a

> U-Flag described in 
> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-

> ureach-prefix-announce/
>  also will interpret that prefix as being reachable.



[LES:] This statement is incorrect.

RFC 5305 states:





If a prefix is advertised with a metric larger then MAX_PATH_METRIC

   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

   during the normal SPF computation.  This allows advertisement of a

   prefix for purposes other than building the normal IP routing table.





(Equivalent statement in RFC 5308 for IPv6)



Existing implementations will ignore the advertisement purely on the basis of 
the metric value - this does not depend upon understanding the U bit.



But existing implementations will NOT ignore a prefix reachability 
advertisement just because it has a source Router ID set to 0 as 
draft-wang-lsr-prefix-unreachable-annoucement defines.



It is worth noting that AFTER the publication of 
draft-ppsenak-lsr-igp-pfx-reach-loss-00 in March 2022 (subsequently renamed as 
draft-ppsenak-lsr-igp-ureach-prefix-announce), the authors of 
draft-wang-lsr-prefix-unreachable-annoucement apparently realized they had  an 
interoperability problem with existing routers (something many of us had been 
highlighting for years) and in V10 (published in Jul 2022) an option was added 
to advertise using maximum metric (the solution already proposed by 
draft-ppsenak). But because the authors apparently didn’t want to abandon the 
use of "Router ID = 0", the new version of the draft proposed a dependency on 
how the unreachable prefix should be advertised. If all routers in the network 
indicated support for the new extension (indicated by yet another protocol 
extension - a new Router Capability sub-TLV for IS-IS) then the use of Router 
ID = 0 

Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm

[Dongjie (Jimmy)]

Hi Krzysztof,

If my understanding is correct, you and Louis are considering about two 
separate optimizations:


1.  Allowing multiple “Virtual Flex-Algos” to share the SPF calculation of 
one “legacy” Flex-Algo.



This can be addressed by the mechanisms described in section 2 of 
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-08.



More specifically, that document allows multiple NRPs to associate with the 
same Flex-Algo, so that the Flex-Algo computation could be reused. NRP is used 
to represent different set of network resources, and Flex-Algo is still used to 
specify the topology and computation constraints for the NRP. In that way, no 
change to Flex-Algo is needed.



2.  Reducing the amount of SR SIDs which are used to indicate different set 
of bandwidth reservation.

The approach of using SR SIDs to represent different set of network resources 
is suitable for networks in which the number of NRPs are relatively small. As 
the number of NRPs increases, there will be scalability challenge not only in 
the control plane but also in the data plane. In that case, a more scalable and 
IGP friendly approach is to introduce a network-wide NRP ID into the packet. 
This is also described in section 5.3 of draft-dong-lsr-sr-enhanced-vpn-08.

Hope this helps.

Best regards,
Jie

From: Lsr  On Behalf Of Krzysztof Szarkowicz
Sent: Wednesday, April 12, 2023 11:42 PM
To: Robert Raszuk 
Cc: linchangwang ; Acee Lindem 
; Peter Psenak ; 程伟强 
; Louis Chan ; Les Ginsberg 
(ginsbe ; lsr 
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset 
forFlex-Algorithm

Hi,

It is the question, if we could for example have more than 20 (e.g. 200), for 
200 different service bandwidth guarantees (but having only one - or handful - 
SPF calculation domains, where one SPF calculation domain is one ‘legacy’ 
flex-algo ). The challenge is with SPP calculations, once the number of 
flex-algos goes high.

Thanks,
Krzysztof



On 2023 -Apr-12, at 17:13, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:


[External Email. Be cautious of content]



Ok you can use 20 flex algos today with no extension. Is going to another level 
of nesting really necessary ?

On Wed, Apr 12, 2023 at 4:52 PM linchangwang 
mailto:linchangwang.04...@h3c.com>> wrote:
Hi Acee

An operator's backbone network is divided into different flex algorithms planes 
according to different SLA requirements of users.
A flex algo represents a service requirement, such as bandwidth requirements.
20 flex algorithms represent 20 different service bandwidth guarantees, 
corresponding to different resource requirements.

Thanks,
Changwang lin

From: Acee Lindem [mailto:acee.i...@gmail.com]
Sent: Wednesday, April 12, 2023 10:12 PM
To: Peter Psenak
Cc: linchangwang (RD); 程伟强; Louis Chan; Les Ginsberg (ginsbe; lsr; Krzysztof 
Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset 
forFlex-Algorithm

Hi Weiqiang,

I’m also curious as to how you are using 20 different flex algorithms. Is this 
just a hypothetical scenario
to illustrate the mathematics or do you have an actual use case?

On Apr 12, 2023, at 09:31, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

Changwang,

please see inline (##PP2):


On 12/04/2023 15:13, linchangwang wrote:
Hi Peter
 Please see inline [changwang lin].
We've met the same problem when applying Flex Algo in SRv6 network.
what problem exactly, can you please describe it?
[changwang lin]
Advertisement size of per Flex-Algo Adj-SID in the network
Related to F(# of node, # of FA, # of links)
For a node with 1,000 links and 20 Flex-Algo
   n x 20 x 1000
   MPLS-SR：If n = 10 bytes, it is 200K bytes
   SRv6：   If n = 24 bytes, it is 400K+ bytes
If 500 nodes:
   MPLS-SR：it is 200K*500   =  10k bytes
   SRv6：   it is 400K+ * 500  = 20k bytes
If interface mtu=1500, lsp length = 1497
 LSPs num:
   MPLS-SR：1k bytes/1497 = 66800  lsps
   SRv6：   2k bytes/1497 = 160320 lsps
The number of LSPs is too large, and IS-IS needs to periodically refresh LSPs,
resulting in a decrease in ISIS performance and unstable network operation.

##PP2
above is hardly a realistic estimation.

In a network with 1k nodes, not every node will have 1k links.

Advertising large number of LSPs is not caused by Adj-SIDs.
With TE enabled the amount of data flooded per link is larger than 
advertisement of the 20 Adj-SID. The problem you are highlighting is not 
specific to Adj-SIDs, it's generic.

LSP refresh time can be set to 18 hours and any reasonable implementation does 
not refresh all LSPs at the same time.

So we need to optimize on the control surface to save LSP space.

##PP2
with all the respect, I don't agree. The problem as you described it does not 
exist.

Through the optimization notification mechanism mentioned in these two 
documents,
we have greatly saved LSP space for IS-IS and improved the performance of IS-IS 
flex algo in large-scale networking.

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Dongjie (Jimmy)]

Support.

It provides necessary OSPF extensions for SRv6 which is equivalent to the IS-IS 
SRv6 extensions.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

[Dongjie (Jimmy)]

Hi authors, WG,

I also have some comments which aligns with Ketan’s first and third points as 
below:

Firstly, both RFC 5305 and 5308 say that:

“If a prefix is advertised with a metric larger then MAX_PATH_METRIC (call it 
infinite metric), this prefix MUST NOT be considered during the normal SPF 
computation. This allows advertisement of a prefix for purposes other than 
building the normal IP routing table.”

It only mandates that this prefix not be used in SPF computation, and leave the 
possibility of using it for other purposes, where “indicating the prefix is 
unreachable” could be one of the possible use cases.

According to these RFCs, a node which receives such a prefix with a metric 
larger than MAX_PATH_METRIC will not take it into consideration for SPF 
computation, but if there is another summary prefix which covers this one, this 
prefix will still be reachable based on the summary prefix.

To indicate this prefix is unreachable even if there is a summary prefix exist, 
additional behavior is required on the receiving node, and this needs to be 
indicated with some additional information in the prefix advertisement.

Secondly, section 2.1 of this document says

“…Such an advertisement can be interpreted by the receiver as a UPA.”

And

 “Optionally, an implementation may use local configuration to limit the set of 
metric values which will be interpreted as UPA.”

This shows that such an advertisement may be interpreted by the receiver as 
something else, and it is expected that not all of the metric values larger 
then MAX_PATH_METRIC will be interpreted as “prefix is unreachable”.

To avoid possible mis-interpretation of the purpose of this prefix 
advertisement, and to save the effort of local configuration, a protocol 
mechanism is needed to carry the accurate indication of the purpose of this 
advertisement.

In summary,


1)  Treating such a prefix as unreachable is not the behavior defined in 
the existing RFCs, a standard track document would be needed for it.

2)  Additional information in the advertisement is needed to accurately 
reflect the purpose and the required behavior.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, July 28, 2022 2:27 PM
To: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
Cc: lsr 
Subject: [Lsr] Comments on draft-ppsenak-lsr-igp-ureach-prefix-announce

Hello Authors,

Sharing some comments upfront on this draft given the packed LSR agenda.

1) There is currently no change in protocol encoding (see also further 
comment), however, there are protocol procedures at the ABR being specified 
using normative language. Specifically, the text related to the propagation of 
UPA across levels/areas/domains. Therefore, I believe that this draft should be 
moved to the standards track.

2) The document refers to "prefix reachability" in a generic sense. My 
understanding is that this refers to the "base" prefix reachability in the IGPs 
- i.e., Extended IP Reachability (TLV 135) and its MT & IPv6 siblings in ISIS, 
the OSPFv2 Type 3 LSA, and the OSPFv3 Inter-Area Prefix LSA (and its Extended 
LSA sibling). It would be good to specify these for clarity.

3) I also prefer (like some other WG members) that there is an explicit 
indication that is carried along with the UPAs. E.g., a UPA flag. This will 
help in more accurate monitoring and handling of these updates. It will also 
help differentiate the usual/existing max/infinite metric advertisements that 
may be triggered for other reasons from a UPA.

Thanks,
Ketan

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

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[Dongjie (Jimmy)]

Hi Gyan,

Thanks for your further clarification.

My understanding is the IGP Flex-Algo document (draft-ietf-lsr-flex-algo) 
specifies both the base IGP Flex-Algo mechanisms (the FAD, the constraints and 
the calculation) and the application of Flex-Algo in SR data plane (which is 
called SR Flex-Algo). Then draft-ietf-lsr-ip-flexalgo introduces the 
application of Flex-Algo in native IP data plane (which is called IP Flex-Algo).

Since this document is based on SR data plane, maybe it is more accurate to say 
it is based on SR Flex-Algo, and reference the Flex-Algo base document 
(draft-ietf-lsr-flex-algo), as it is where SR Flex-Algo is specified.

The application of IP Flex-Algo to VTN or NRP may be specified in a separate 
document.

Regarding the 1:1 mapping between VTN or NRP and Flex-Algo, it is agreed that 
the scalability is limited, and in this document this is considered as a 
mechanism for network scenarios where a relatively small number of VTNs are 
needed. The advantage is that we can reuse existing mechanisms with very small 
extension.

The mechanism John mentioned (allocating per-NRP resource-aware SIDs and let 
multiple NRPs share the same Flex-Algo) is more scalable, while requires 
further protocol extensions. This mechanism is specified in another document 
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-07. IMO 
both mechanisms have their targeted scenarios.

Best regards,
Jie

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Thursday, May 19, 2022 12:55 PM
To: Dongjie (Jimmy) 
Cc: Dongjie (Jimmy) ; 
adr...@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Jie

Very welcome!

I was actually referring to “SR” Flex Algo not IP Flex Algo comment I made.  
This is a bit confusing which is why I brought it up.

Since the original Flex Algo draft is the base draft for Flex Algo it was 
termed by the authors “IGP Flex Algo” not “SR Flex Algo” as the base has 
extensibility to other data planes such as RSVP-TE, IP and future data planes.  
However today the base only supports SR.

Base Flex Algo = IGP Flex Algo

Only Applies to SR data plane SR-MPLS prefix sid or SRv6 locator but is 
extensible to other data planes

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-20

Extensible starting with below IP Flex Algo

IP Flex Algo

Only applies to IP data plane destination prefix based algo

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo

So in the draft you mentioned SR Flex Algo so I was just stating based on above 
to be more accurate per below recommendation.

s/ SR Flex Algo/ IGP Flex Algo

Regarding TEAS terminology VTN versus NRP, as Enhanced VPN / VPN+ aligns with 
VTN I see your point to keep the VTN terminology in this draft as 5G and VPN+ 
are mentioned.

https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-10

My thoughts were that as the NRP scalability draft also has references to VPN+ 
and uses the NRP terminology it seems to make sense for drafts referencing IETF 
network slice underlay resource  provisioning to refer to NRP for consistency.  
I am OK with either direction but I think for the reader consistency is always 
good as terminology can get confusing.

What are your thoughts on the latter part of the email discussion related to 
NRP and Flex Algo identifier and instead of the 1 for 1 mapping Flex Algo to 
NRP does not scale as well for slicing.

What John mentioned was a set of resource SIDs, one per NRP allocated on links 
that are currently part of the FAD topology algo. So then a label would be 
allocated by each node to represent [FAD,NRP] tuple.

This idea would be a way to provide better control plane scalability for IETF 
network slicing using Flex Algo and not be limited to 128 slices.

I had not thought about it but  IP Flex Algo could also be used for IETF 
network slicing for sure.

Kind Regards

Gyan


On Wed, May 18, 2022 at 11:58 PM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Gyan,

Thanks for your review and useful comments.

The VTN concept is introduced in VPN+ framework 
(https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn) in TEAS, and 
its relationship with NRP is described in that document. VTN can be used to 
support VPN+ service, which provides a realization of network slice.

This document provides a mechanism to build SR based VTNs using the combination 
of existing techniques (Flex-Algo, L2 bundle) with minor extensions. Calling it 
VTN or NRP does not impact the mechanism or the extensions in this document. We 
prefer to continue to the term VTN to align with VPN+ framework, but we are 
open to suggestions.

Your comment about the IP Flex-Algo is more interesting. Since the L2 bundle 
relies on different SR SIDs for traffic steering to different member links, my 
feeling is it is mostly applicable to SR based data plane. If needed we could 
have f

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[Dongjie (Jimmy)]

Hi Gyan,

Thanks for your review and useful comments.

The VTN concept is introduced in VPN+ framework 
(https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn) in TEAS, and 
its relationship with NRP is described in that document. VTN can be used to 
support VPN+ service, which provides a realization of network slice.

This document provides a mechanism to build SR based VTNs using the combination 
of existing techniques (Flex-Algo, L2 bundle) with minor extensions. Calling it 
VTN or NRP does not impact the mechanism or the extensions in this document. We 
prefer to continue to the term VTN to align with VPN+ framework, but we are 
open to suggestions.

Your comment about the IP Flex-Algo is more interesting. Since the L2 bundle 
relies on different SR SIDs for traffic steering to different member links, my 
feeling is it is mostly applicable to SR based data plane. If needed we could 
have further discussion about whether and how IP Flex-Algo can be used for VTN 
or NRP.

Best regards,
Jie

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Wednesday, May 18, 2022 12:51 PM
To: Dongjie (Jimmy) 
Cc: adr...@olddog.co.uk; draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

Hi Jie

I reviewed the draft as well and it seems to parallel SR VTN MT draft  Enhanced 
VPN / VPN+  underpinning to IETF slice underlay TEAS NRP  mapped to an ISIS or 
OSPF MTID control plane instance.

Similarly here with this draft mapping of TEAS NRP to a Flex Algo FAD realizing 
of IETF network slice and now bundle members with this draft extensions to RFC 
8668 ISIS and OSPF draft
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-03 can now 
be mapped to an NRP.

VTN MT
https://datatracker.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt

Suggestion for s/VTN/NRP using updated TEAS Network slicing terminology.

This draft updates RFC 8668 for ISIS but should also update the OSPF draft 
above.

I think Adrian may have mentioned in his review I would refer to Flex Algo as 
IGP Flex Algo not SR Flex Algo throughout the draft as specified in the IGP 
Flex Algo draft.

I think it may or may not be the intention but I believe along with realizing 
an NRP using IGP Flex Algo mapping to L2 bundle member links, this draft also 
provides the context of realizing an NRP using Flex Algo and using the Flex 
Algo identifier as a way to reference or index the NRP per statement in section 
2.


If each VTN is associated with a unique Flex-Algo, the Flex-Algo identifier 
could be

reused as the identifier of the VTN in the control plane.

With the 1 to 1 mapping of Flex Algo to NRP you could also use the Flex Algo 
identifier to correlate the IETF Network slice NRP being instantiated by the 
NSC and possibly could use the Flex Algo identifier as the NRP ID.

Kind Regards

Gyan

On Tue, May 17, 2022 at 6:01 AM Dongjie (Jimmy) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Adrian,

Thanks a lot for your detailed review. All your comments and suggestions look 
good and we will produce a new revision to incorporate them.

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org<mailto:lsr@ietf.org>
> Cc: 
> draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org<mailto:draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org>
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
>
> Hi LSR and draft authors,
>
> I read this draft, and it seems to me that it provides a useful transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be 
> achieved
> with a very minor control plane extension.
>
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

>
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
>
> Best,
> Adrian
>
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
>
> ===
>
> As currently defined, I think this document needs to update RFC 8668. This is
> because that RFC says that

Re: [Lsr] A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04

[Dongjie (Jimmy)]

Hi Adrian, 

Thanks a lot for your detailed review. All your comments and suggestions look 
good and we will produce a new revision to incorporate them. 

And please see replies to some points inline:

Best regards,
Jie

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Monday, May 16, 2022 7:22 PM
> To: lsr@ietf.org
> Cc: draft-zhu-lsr-isis-sr-vtn-flexa...@ietf.org
> Subject: FW: A review of draft-zhu-lsr-isis-sr-vtn-flexalgo-04
> 
> Hi LSR and draft authors,
> 
> I read this draft, and it seems to me that it provides a useful transitional
> mechanism. It can obviously only support a relatively small number of VTNs
> (128 due to the limited number of Flex-Algos the network devices can
> support), but it looks to be a worthwhile first step because it can be 
> achieved
> with a very minor control plane extension.
> 
> Perhaps this document is a good first step while we work on a longer term
> and more scalable control plane solution. It would also give us the chance to
> determine the level of interest in VTNs.

Indeed, this is exactly the purpose of this document.

> 
> My comments, below, are mainly editorial, but there are a couple of issues
> around the use of the E flag.
> 
> Best,
> Adrian
> 
> (PS. For those of you saying "What's a VTN?" the "Virtual Transport
> Network"
> is a network construct described in the TEAS WG to support Enhanced VPNs
> (https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/) and network
> slicing
> (https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/)
> where it maps to a "Network Resource Partition".)
> 
> ===
> 
> As currently defined, I think this document needs to update RFC 8668. This is
> because that RFC says that other flags in the flag field of the Parent L3
> Neighbor Descriptor in the L2 Bundle Member Attributes TLV "MUST be
> ignored".
> 
> That's easy enough to handle:
> - You add the "updates 8668" element to the XML
> - You add a final paragraph to the Abstract to say
> This document updates RFC 8668 by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> - You add a final paragraph to the Introduction to say
> This document updates [RFC8668] by defining a new flag in the Parent
> L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV.
> [RFC8668] states that all bit fields not defined in that document
> "MUST be set to zero on transmission and ignored on receipt".
> Section 3 of this document defines a new flag and specifies both
> when it is set and how it should be processed.
> 
> However, a purist might point out that RFC 8668 should be fixed so that:
> 
> - The unused bits are defined as reserved for future use
> - The text should be updated to describe how the bits are set and handled
>   by implementations that don't understand them
> - There should be an IANA registry for the bits
> 
> You're not responsible for fixing RFC 8668, but you could if you want to.
> 
> Making this document an "update" is also important because of the absence
> of an IANA registry -- it is important to provide a way for people to track 
> the
> bits so that there is no collision when another bit is defined.
> 
> You could use definitely use this document to create the necessary IANA
> registry, even if you are not fixing the other parts of 8668.

Thanks for your suggestion, we will make this document an update of RFC 8668 to 
help track the new flag.


> 
> ---
> 
> Would be worth expanding "VTN" in the title to read...
>   Using Flex-Algo for Segment Routing based Virtual Transport Networks
> 
> ---
> 
> Abstract
> 
> The first mention of "Flex-Algo" needs to have some explanation of the
> concept. Not many words, but something like...
> 
> OLD
>The topological constraints of a VTN can be defined using Flex-Algo.
> NEW
>The topological constraints of a VTN can be defined using Flex-Algo,
>a mechanism to provide distributed constraint-path computation.
> END

We will add some description about Flex-Algo. 


> ---
> 
> Abstract
> 
> "SR" should be spelled out as "Segment Routing (SR)"
> 
> ---
> 
> Abstract
> 
> s/L2 bundle/L2 bundles/
> 
> ---
> 
> 1.
> 
> The word "traditional" has other meanings in American English and we are
> now asked to avoid using it.
> 
> OLD
>than that can be provided with traditional overlay VPNs.
> NEW
>than that could be provided with existing overlay VPNs techniques.
> END

OK, will make the change accordingly.

> 
> ---
> 
> 1.
> 
> s/resource-aware SIDs/resource-aware segment identifiers (SIDs)/ s/With
> segment routing/With a segment routing/ s/Segment Identifiers (SIDs) can
> be used/SIDs can be used/ s/using control plane/using the control plane/
> s/scalable Segment Routing (SR)/scalable SR/ s/a unique Flex-Algo/a unique
> Flex-Algo [I-D.ietf-lsr-flex-algo]/
> 
> ---
> 
> Section 1 has just one sentence on the purpose and content of this
> document.
> 
>This 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Dongjie (Jimmy)]

Hi Ketan, Peter,

I’ve just finished reading this thread, and think Ketan’s concerns make sense. 
Although the current Flex-Algo Definition is independent of the data plane 
encapsulation, I’m not sure if there is real benefit to use the same FAD with 
different data plane participation to cut out different topologies for path 
computation.

We used to have similar discussion on the list in December of 2020. At that 
time there was suggestion to simply use different Flex-Algo IDs with different 
data planes participation, or we may need to define per data plane Flex-Algo 
participation mechanisms for IPv4, IPv6, SR-MPLS and SRv6 respectively.

Per Flex-Algo SPF computation is straightforward for implementation and 
inter-operation, and also easy to manage and troubleshoot for operators. 
Actually a Flex-Algo ID can be seen as the identifier of the combination of the 
rules/constraints defined in FAD, and the set of nodes which participate in the 
Flex-Algo. But if one Flex-Algo can correspond to multiple topologies in the 
same network, we would need some additional identifiers for each of these 
topologies.

Thus my suggestion is also to make per Flex-Algo computation the default 
behavior. Per Flex-Algo per data plane computation could be optional.

Best regards,
Jie


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Wednesday, April 13, 2022 4:53 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org; 
draft-ietf-lsr-ip-flexa...@ietf.org;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi Peter,

I will not press this point further if I am the only one that finds this 
complexity without any benefit. :-)

Please check inline below for some clarifications with KT3.


On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak 
mailto:ppse...@cisco.com>> wrote:
Hi Ketan,


please see inline (##PP3):

On 13/04/2022 06:00, Ketan Talaulikar wrote:
> Hi Peter,
>
> Please check inline below with KT2. I am trimming everything other than
> the one point of continuing debate.
>
>  >  >
>  >  > 2) The relationship between the algo usage for IP FlexAlgo
> and other
>  >  > data planes (e.g. FlexAlgo with SR) is not very clear.
> There arise
>  >  > complications when the algo usage for IP FlexAlgo overlap
> with other
>  >  > (say SR) data planes since the FAD is shared but the node
>  > participation
>  >  > is not shared. While Sec 9 suggests that we can work
> through these
>  >  > complications, I question the need for such complexity.
> The FlexAlgo
>  >  > space is large enough to allow it to be shared between
> various data
>  >  > planes without overlap. My suggestion would be to neither
> carve out
>  >  > parallel algo spaces within IGPs for various types of
> FlexAlgo data
>  >  > planes nor allow the same algo to be used by both IP and
> SR data
>  > planes.
>  >  > So that we have a single topology computation in the IGP
> for a given
>  >  > algo based on its FAD and data plane participation and
> then when it
>  >  > comes to prefix calculation, the results could involve
>  > programming of
>  >  > entries in respective forwarding planes based on the
> signaling of
>  > the
>  >  > respective prefix reachabilities. The coverage of these
> aspects in a
>  >  > dedicated section upfront will help.
>  >
>  > ##PP
>  > I strongly disagree.
>  >
>  > FAD is data-pane/app independent. Participation is data-plane/app
>  > dependent. Base flex-algo specification is very clear about
> that. That
>  > has advantages and we do not want to modify that part.
>  >
>  >
>  > KT> No issue with this part.
>  >
>  >
>  > Topology calculation for algo/data-plane needs to take both
> FAD and
>  > participation into account. You need independent calculation
> for each
>  > data-plane/app in the same algo.
>  >
>  >
>  > KT> So, an implementation now needs to potentially support
> performing
>  > multiple topology computations for each algo. This is a
> complication for
>  > which I do not see the justification. Why not just pick different
>  > algorithms for different data planes for those (rare?)
> deployments where
>  > someone wants multiple data planes?
>
> ##PP2
> flex-algo architecture supports multiple apps/data-planes per algo,
> with
> unique participation per app/data-plane. That requires per-algo/per
> app/data-plane calculation. What is complicated on it?
>
>
> KT2> This specific and precise 

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Dongjie (Jimmy)]

Hi Robert,

How about call them different “data plane encapsulations”?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, April 14, 2022 9:51 PM
To: John E Drake 
Cc: lsr@ietf.org; Ketan Talaulikar ; 
draft-ietf-lsr-ip-flexa...@ietf.org; Peter Psenak 
; Acee Lindem (acee) 

Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi John,

In the IETF context I have always associated ‘data plane’ with packet 
forwarding,

No one disputes that.

But the fact that various sub-data-planes are built on top of base physical 
data planes needs to be clearly distinguished.

Kind regards,
R.


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

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Dongjie (Jimmy)]

Hi,

I've read this document and support its adoption.

My understanding of this document is that it aims to identify a link attached 
to an IGP node, while the link itself does not run IGP. Some attributes of such 
link may be used in determining the path to an external network via that link. 
This may apply both to the inter-AS cases and the data center cases as 
mentioned in the draft. It seems that define a generic mechanism for such case 
is a reasonable approach. 

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Tuesday, January 4, 2022 2:59 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org;
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
> 
> Please indicate your support or objections by January 18th, 2022.
> 
> Authors, please respond to the list indicating whether you are aware of any
> IPR that applies to these drafts.
> 
> Thanks,
> Chris.
> 
> ___
> 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] Generic metric: application-specific vs application-independent

[Dongjie (Jimmy)]

Hi, 

I share similar opinion with Gunter. 

ASLA provides the flexibility to define the set of applications which can use a 
specific type of link attribute, it also allows to customize the attribute 
value for each application.

As the generic metric mechanism will be used to define different types of new 
metrics, some of which may need the flexibility of indicating the set of 
applications it is used for, and may also need to generate application-specific 
metric values. In that case, it seems ASLA is the suitable approach for such 
metric advertisement.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Van De Velde, Gunter
> (Nokia - BE/Antwerp)
> Sent: Friday, July 30, 2021 5:06 PM
> To: Peter Psenak ; Shraddha Hegde
> ; Les Ginsberg (ginsberg)
> ; Tony Li 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs
> application-independent
> 
> A little late in the discussion... (PTO events do happen)
> 
> a quick opinion on the below discussion on whether Generic metric sub-tlv
> should be encoded on a ASLA or not.
> For me, it depends on how the metric for the corresponding metric-type is
> obtained and if it can be configured (static).
> It doesn’t make sense to have Application specific values if a particular 
> metric
> is obtained only dynamically, for eg, dynamically measured delay is going to
> be same for all applications.
> On the contrary, te-metric can be configured, and we can in principle 
> configure
> different values for different applications.
> 
> My opinion is that if any of the metric-types in the Generic metric sub-tlv 
> can
> be configured, it should be inside the ASLA.
> 
> G/
> 
> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Friday, July 30, 2021 9:42 AM
> To: Shraddha Hegde ; Les Ginsberg
> (ginsberg) ; Tony Li 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Generic metric: application-specific vs
> application-independent
> 
> Shraddha,
> 
> On 30/07/2021 06:53, Shraddha Hegde wrote:
> > Operators have built their networks with link attributes
> >
> > being configured and used by any application. For example
> >
> > igp-metric is used by ISIS, then came LDP that used same igp-metric,
> >
> > RSVP could also use igp-metric. Then came ISIS-SR and SR-TE
> >
> > and even flex-algo. All these applications could use the same igp-metric.
> >
> > The networks have evolved like this for 20-30 years.
> >
> > If an operator wants to design his network for this kind of
> >
> > network evolution with generic metric going forward, ASLA does not
> >
> > currently provide an effective solution.
> 
> please be more specific as to what exactly "ASLA does not currently provide an
> effective solution" for.
> 
> > ASLA currently has limitations
> >
> > that make it more complex than necessary for operators who want to
> >
> > evolve their networks this way.
> 
> above seems more like your opinion than the fact. I have not seen any
> evidence that would prove the above statement.
> 
> 
> >
> > I am working on a draft to propose improvements to ASLA to
> >
> > make this kind of evolution less complex. I'll post a draft
> >
> > soon that will describe limitations of ASLA in its current form
> >
> > along with proposed improvements.
> 
> 
> hard to comment on something that does not exist.
> 
> 
> >
> > I would still like to hear about use cases that require
> >
> > generic metric to be applications-specific and cannot be solved with
> >
> > application-independent generic metric.
> 
> it has been explained on the list multiple times.
> 
> 
> thanks,
> Peter
> 
> 
> >
> > Rgds
> >
> > Shraddha
> >
> > Juniper Business Use Only
> >
> > *From:* Les Ginsberg (ginsberg) 
> > *Sent:* Thursday, July 29, 2021 2:00 AM
> > *To:* Tony Li 
> > *Cc:* lsr@ietf.org; Shraddha Hegde 
> > *Subject:* RE: [Lsr] Generic metric: application-specific vs
> > application-independent
> >
> > *[External Email. Be cautious of content]*
> >
> > Tony –
> >
> > You ask very important questions – but – as Acee has answered in a
> > subsequent email – all of these questions were openly debated in the
> > WG during the work on what became RFC8919/8920. This debate was
> > contentious, took years, and the WG eventually reached consensus on
> > what became the two RFCs.
> >
> > If every time a new attribute is defined we reopen the original
> > debate, then we will never move forward and we will have great
> > difficulty in deploying interoperable implementations.
> >
> > I can respect that you might have preferred a different conclusion on
> > the part of the WG – but I hope you will also acknowledge that this is
> > now a resolved issue and we need to move forward following the
> > existing RFCs.
> >
> > Parenthetically, I do believe that answers to your questions can be
> > found in the RFCs. The answers may not satisfy you – but we did
> > attempt to include the context which drove the ASLA solution.
> >
> > Thanx.
> >
> >      

Re: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts

[Dongjie (Jimmy)]

I support the adoption of these two documents. 

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, July 22, 2021 6:48 PM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for SRv6 YANG drafts
> 
> 
> Hi Folks,
> 
> This begins a 3 week WG Adoption Call for the following related YANG drafts:
> 
> https://datatracker.ietf.org/doc/draft-hu-isis-srv6-yang/
> https://datatracker.ietf.org/doc/draft-hu-lsr-ospf-srv6-yang/
> 
> Please indicate your support or objections by August 12th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR
> that applies to these drafts.
> 
> Thanks,
> Chris.

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi Gyan,

Thanks for your reply. So we (and others) are on the same page about the 
resources related functionality introduced to Flex-Algo: it need to be 
discussed separately from this draft.

If the authors agree with this, can this be reflected in an update of this 
draft?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Friday, June 11, 2021 9:37 AM
To: Dongjie (Jimmy) 
Cc: lsr@ietf.org; Christian Hopps 
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


Hi Jimmy

Please see my comments in-line:

Thanks

Gyan
On Thu, Jun 10, 2021 at 4:20 AM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Gyan,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Gyan Mishra
Sent: Thursday, June 10, 2021 1:05 PM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

Also does it update the Flex Algo draft?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[Jie] I see this may be related to the resource-aware SID and its usage for 
enhanced VPN. While as mentioned in several mails in this thread, the use cases 
of associating Flex-Algos with different link resources/QoS policy/etc. require 
new functionality to Flex-Algo, which needs to be discussed separately from 
this document.
 Gyan> I agree as Les and others have mentioned any resources related 
functionality must first be reviewed and accepted by the WG as a separate 
document. I agree as others mentioned the main use case is for TI-LFA local 
protection of backup path so it can use other than default Algo 0.
Best regards,
Jie

Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

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

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi Gyan,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Thursday, June 10, 2021 1:05 PM
To: Christian Hopps 
Cc: lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency 
SID Advertisement"


I support WG adoption of this draft.

This draft fills the gap where multiple algorithm identifiers are associated 
with a link applied to prefix sid and to add parity as now this draft provides 
Algo association with the adjacency SID as well.  At the end of the 
introduction is stated that the algorithm identifier should be included as part 
of the adjacency SID advertisement for SR-MPLS.   What about SRv6?

Does this draft update the SR IGP extensions for
SR-MPLS RFC 8665 8666 8667.

Also does it update the Flex Algo draft?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16

In section 5 operations describes how flex Algo plane can now be differentiated 
on the same  adjacency link with the Algo identifier adjacency sid to Algo 
plane can now have QOS and link resources characteristics defined which maybe 
beneficial to TEAS network slicing application as well as used in conjunction 
with a resource sid for underlay resource provisioning for Enhanced VPN overlay.

[Jie] I see this may be related to the resource-aware SID and its usage for 
enhanced VPN. While as mentioned in several mails in this thread, the use cases 
of associating Flex-Algos with different link resources/QoS policy/etc. require 
new functionality to Flex-Algo, which needs to be discussed separately from 
this document.

Best regards,
Jie

Kind Regards

Gyan

On Wed, May 26, 2021 at 5:00 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid/

Please indicate your support or objections by June 9th, 2021

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Acee and Chris.

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

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi PSF, 

Please see inline:

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Monday, May 31, 2021 9:41 AM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jie,
> 
> Thanks.
> Again, in this document we describe local behavior per algorithm thanks to
> adj-sid per algo, but not describe any resource reservatoin extensions to
> flex-algo. the later can be discussed in another thread.

Then it is reasonable to remove the text about use case 1, 2 and the operations 
in section 5 which are related to per flex-algo resource reservation or traffic 
treatment over the same link, as you said they are local behaviors thus do not 
require  interoperability.

> IMO the local behavior can be any local policies, such as local repair path, 
> local
> queue, local priority for entry installation, etc. Adj-sid per algo provides 
> the
> basis for these local behavior. It is useful to describe how adj-sid per algo 
> can
> satisfy these usecases, also to facilitate readers to understand its use.

Local repair is different from the other cases you mentioned. Local repair 
results in the change of the path and the SID list, which is visible to the 
network. In addition, the computation of local repair path is based on the 
Flex-Algo constraints defined by the FAD. In contrast, the local queue or 
priority information is not reflected in the FAD. 

Before introducing the local queue and priority use cases to this draft, it is 
necessary to understand whether such local information need to be included in 
the FAD or not, and propose relevant Flex-Algo extensions for it, otherwise IMO 
they are local information and behaviors which are NOT related to Flex-Algo.

Best regards,
Jie

> You are very concerned about the extension of resource reservation. Although
> it is not related to this document and should be discussed in another thread, 
> I
> will try to answer it in your previous email.
> 
> Regards,
> PSF
> 
> 
> 
> 
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：彭少富10053815;
> 抄送人：cho...@chopps.org;lsr@ietf.org;
> 日 期 ：2021年05月28日 14:24
> 主 题 ：RE: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> IGP-Adjacency SID Advertisement"
> Hi PSF,
> Thanks for your pointer to another document which defines the encodings of
> per-Algo TE link attributes.
> But my comments are related to the text in section 3 and 5 of this document,
> which describes new use cases and operation of Flex-Algo with per Flex-Algo
> resource reservation or per Flex-Algo QoS policy on the same link. These 
> require
> extensions to the function of Flex-Algo, which IMO needs to be discussed and
> compared with other alternative mechanisms. And as you indicated, there are
> related encoding extensions proposed in other document, thus it may not be
> just a local behavior.
> So could you reply to the comments in my previous mail?
> Best regards,
> Jie
> > -Original Message-
> > From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> > Sent: Friday, May 28, 2021 12:00 PM
> > To: Dongjie (Jimmy) 
> > Cc: cho...@chopps.org; lsr@ietf.org
> > Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> > Hi Jie,
> >
> > Thanks for your comments.
> >
> > In this document, there are not any extensions to describe resource
> > reservation per algo. Are you aiming at another draft
> > (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please
> > find out what you are talking about first.
> > Adj-SID per algo can distinguish traffic behavior in local. You are
> > welcome to add more usecases based on section 3.
> >
> > Regards,
> > PSF
> >
> >
> > --原始邮件--
> > 发件人：Dongjie(Jimmy)
> > 收件人：Christian Hopps;lsr@ietf.org;
> > 日 期 ：2021年05月28日 11:40
> > 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> > Hi,
> > I don't support the adoption of this document.
> > It seems this document aims to introduce per Flex-Algo Adj-SID to
> > SR-MPLS, its typical use case is to provide protection path with
> > Flex-Algo constraints for Adj-SID of a particular Flex-Algo, which is 
> > described
> in the case 3 of section 3.
> > However, section 3 and section 5 shows that it also aims to introduce
> > further changes to the usage and operation of Flex-Algo, which is to
> > provide resource reservation based on Flex-Algo.

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi Peter,

Thanks for your reply. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, May 28, 2021 4:10 PM
> To: Dongjie (Jimmy) ; Christian Hopps
> ; lsr@ietf.org
> Subject: Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jimmy,
> 
> please see inline:
> 
> On 28/05/2021 05:39, Dongjie (Jimmy) wrote:
> > Hi,
> >
> > I don't support the adoption of this document.
> >
> > It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS,
> its typical use case is to provide protection path with Flex-Algo constraints 
> for
> Adj-SID of a particular Flex-Algo, which is described in the case 3 of 
> section 3.
> >
> > However, section 3 and section 5 shows that it also aims to introduce 
> > further
> changes to the usage and operation of Flex-Algo, which is to provide resource
> reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves
> further discussion and is not only related to the per Flex-Algo Adj-SID
> extension.
> 
> personally, I consider use case 3 (per algo protected Adj SID) the main reason
> we need this draft.

I share the similar opinion with you. 


> I don't care much about the other use cases to be honest, but I see no reason
> why an implementation can not associate local resources on a per algo basis.
> Sure, algo is not in the packet, but there are various indirect ways of doing 
> that.
> All local behavior.

If all of these are local behavior, IMO they do not need to be described in 
this draft. 

> > Here are some comments about this change to Flex-Algo:
> >
> > 1. Flex-Algo defines the constraints for path computation in a distributed
> manner, it is not for resource reservation.
> >
> > 2. Reserving resources for each Flex-Algo on a link does not make sense. The
> correlation between Flex-Algo and the network links is based on administrative
> groups (color), and the color of the link may or may not be included in the
> Flex-Algo definition. To follow the color based link correlation, a more 
> practical
> approach would be to use Flex-Algo with L2 bundle as defined in
> draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
> and
> the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo
> resource reservation.
> 
> "correlation between Flex-Algo and the network links is based on
> administrative groups" - that's one way of doing so. There are others.

OK, my point is Flex-Algo uses link constraints (color, SRLG, bandwidth 
constraint, etc.) in the FAD to associate it with a set of links, rather than 
configuring the Flex-Algo ID explicitly on the links. 


> >
> > 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE
> attributes are shared by all Flex-Algos which include the link according to 
> the
> FAD, and based on previous discussion, it seems there is no intention to
> introduce per Flex-Algo ID link attributes.
> 
> that's right, but I see no direct relationship with the above.

Thanks for confirming that there is no intention to introduce per Flex-Algo ID 
link attributes. Taking this and the above item into consideration, I assume 
the current Flex-Algo model does not support per Flex-Algo ID based queue and 
bandwidth configuration on a link.

> 
> Anyway, I'm not a big fun of IETF documents describing local behaviors
> which are not needed for interoperability, so keeping these things out
> of the draft would be fine with me.

Agreed, removing those use cases and operation text which are not related to 
Flex-Algo interoperability would make this document simpler. 

Best regards,
Jie

> 
> 
> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> >> Sent: Thursday, May 27, 2021 4:57 AM
> >> To: lsr@ietf.org
> >> Cc: cho...@chopps.org
> >> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID
> >> Advertisement"
> >>
> >>
> >> Hi Folks,
> >>
> >> This begins a 2 week WG Adoption Call for the following draft:
> >>
> >>
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-si
> d
> >> /
> >>
> >> Please indicate your support or objections by June 9th, 2021
> >>
> >> Authors, please respond to the list indicating whether you are aware of any
> IPR
> >> that applies to this draft.
> >>
> >> Thanks,
> >> Acee and Chris.
> >>
> >> ___
> >> 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
> >
> >

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

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi PSF,

Thanks for your pointer to another document which defines the encodings of 
per-Algo TE link attributes.

But my comments are related to the text in section 3 and 5 of this document, 
which describes new use cases and operation of Flex-Algo with per Flex-Algo 
resource reservation or per Flex-Algo QoS policy on the same link. These 
require extensions to the function of Flex-Algo, which IMO needs to be 
discussed and compared with other alternative mechanisms. And as you indicated, 
there are related encoding extensions proposed in other document, thus it may 
not be just a local behavior. 

So could you reply to the comments in my previous mail?

Best regards,
Jie

> -Original Message-
> From: peng.sha...@zte.com.cn [mailto:peng.sha...@zte.com.cn]
> Sent: Friday, May 28, 2021 12:00 PM
> To: Dongjie (Jimmy) 
> Cc: cho...@chopps.org; lsr@ietf.org
> Subject: Re:[Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> 
> Hi Jie,
> 
> Thanks for your comments.
> 
> In this document, there are not any extensions to describe resource 
> reservation
> per algo. Are you aiming at another draft
> (https://datatracker.ietf.org/doc/draft-cp-lsr-fa-aware-te/) ?  Please find 
> out
> what you are talking about first.
> Adj-SID per algo can distinguish traffic behavior in local. You are welcome to
> add more usecases based on section 3.
> 
> Regards,
> PSF
> 
> 
> --原始邮件--
> 发件人：Dongjie(Jimmy)
> 收件人：Christian Hopps;lsr@ietf.org;
> 日 期 ：2021年05月28日 11:40
> 主 题 ：Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency
> SID Advertisement"
> Hi,
> I don't support the adoption of this document.
> It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its
> typical use case is to provide protection path with Flex-Algo constraints for
> Adj-SID of a particular Flex-Algo, which is described in the case 3 of 
> section 3.
> However, section 3 and section 5 shows that it also aims to introduce further
> changes to the usage and operation of Flex-Algo, which is to provide resource
> reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves
> further discussion and is not only related to the per Flex-Algo Adj-SID 
> extension.
> Here are some comments about this change to Flex-Algo:
> 1. Flex-Algo defines the constraints for path computation in a distributed
> manner, it is not for resource reservation.
> 2. Reserving resources for each Flex-Algo on a link does not make sense. The
> correlation between Flex-Algo and the network links is based on administrative
> groups (color), and the color of the link may or may not be included in the
> Flex-Algo definition. To follow the color based link correlation, a more 
> practical
> approach would be to use Flex-Algo with L2 bundle as defined in
> draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
> and
> the L2 member link to a Flex-Algo, this avoids the extension for per-FlexAlgo
> resource reservation.
> 3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
> attributes
> are shared by all Flex-Algos which include the link according to the FAD, and
> based on previous discussion, it seems there is no intention to introduce per
> Flex-Algo ID link attributes.
> Best regards,
> Jie
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Thursday, May 27, 2021 4:57 AM
> > To: lsr@ietf.org
> > Cc: cho...@chopps.org
> > Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related
> > IGP-Adjacency SID Advertisement"
> >
> >
> > Hi Folks,
> >
> > This begins a 2 week WG Adoption Call for the following draft:
> >
> > https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adja
> > cency-sid
> > /
> >
> > Please indicate your support or objections by June 9th, 2021
> >
> > Authors, please respond to the list indicating whether you are aware
> > of any IPR that applies to this draft.
> >
> > Thanks,
> > Acee and Chris.
> >
> > ___
> > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID Advertisement"

[Dongjie (Jimmy)]

Hi,

I don't support the adoption of this document. 

It seems this document aims to introduce per Flex-Algo Adj-SID to SR-MPLS, its 
typical use case is to provide protection path with Flex-Algo constraints for 
Adj-SID of a particular Flex-Algo, which is described in the case 3 of section 
3. 

However, section 3 and section 5 shows that it also aims to introduce further 
changes to the usage and operation of Flex-Algo, which is to provide resource 
reservation based on Flex-Algo. IMO these changes to Flex-Algo deserves further 
discussion and is not only related to the per Flex-Algo Adj-SID extension.

Here are some comments about this change to Flex-Algo:

1. Flex-Algo defines the constraints for path computation in a distributed 
manner, it is not for resource reservation. 

2. Reserving resources for each Flex-Algo on a link does not make sense. The 
correlation between Flex-Algo and the network links is based on administrative 
groups (color), and the color of the link may or may not be included in the 
Flex-Algo definition. To follow the color based link correlation, a more 
practical approach would be to use Flex-Algo with L2 bundle as defined in 
draft-zhu-lsr-isis-sr-vtn-flexalgo, which uses color to correlate the L3 link 
and the L2 member link to a Flex-Algo, this avoids the extension for 
per-FlexAlgo resource reservation. 

3. The Flex-Algo link TE attributes are advertised using ASLA, the TE 
attributes are shared by all Flex-Algos which include the link according to the 
FAD, and based on previous discussion, it seems there is no intention to 
introduce per Flex-Algo ID link attributes.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, May 27, 2021 4:57 AM
> To: lsr@ietf.org
> Cc: cho...@chopps.org
> Subject: [Lsr] LSR WG Adoption Call for "Algorithm Related IGP-Adjacency SID
> Advertisement"
> 
> 
> Hi Folks,
> 
> This begins a 2 week WG Adoption Call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-peng-lsr-algorithm-related-adjacency-sid
> /
> 
> Please indicate your support or objections by June 9th, 2021
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR
> that applies to this draft.
> 
> Thanks,
> Acee and Chris.
> 
> ___
> 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] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

Hi Shraddha,

Thanks for your further explanation.

I agree if operators design it properly, it could provide the desired result of 
excluding links whose maximum bandwidth is lower than the specified constraint.

As you said it is not related to the bandwidth management or reservation, thus 
it is more like a mechanism of relative static network planning, without 
considering the dynamics of the link bandwidth utilization.

I don't have further questions.

Best regards,
Jie

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Wednesday, May 19, 2021 6:42 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02


>[Jie] I can understand how this works for a single Flex-Algo, while my 
>question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence 
>to the network?

Operators design and plan whether one flex-algo is suitable for their network 
or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This 
network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to 
ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high band

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

Hi Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Acee 
Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: RE: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

I've read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?
Yes. Any application can make use of generic metric including 
Flex-algo and SR-TE.
  Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.   The "Exclude Minimum Bandwidth" constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?
 The motivation for "Exclude Minimum Bandwidth" is to avoid low 
capacity links for the high bandwidth traffic. For example if the Flex-algo 128 
carries high bw traffic flows of bw greater than 10g, it makes sense to remove 
1g links from this flex-algo topology since these links if happen to carry 
traffic, it  will get congested and traffic will be dropped. The introduction 
section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question 
was if more than one Flex-Algo use bandwidth as constraint to exclude some 
links, what would be the consequence to the network?





Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?

 Many network operators assign link metric relative to bandwidth of 
the link and it is an existing practice. The draft is defining new attributes 
and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions 
that a centralized computation or distributed RSVP based solutions provide.



[Jie] OK it is clear that this mechanism will not replace the centralized 
bandwidth computation or distributed bandwidth reservation solutions.  While if 
the purpose is just to simplify and automate the metric configuration process, 
, it seems the gain is relatively limited?





3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidt

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? 
Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) ; lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, 
Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Hi authors,

I’ve read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?


2.   The “Exclude Minimum Bandwidth” constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: 
draft-hegde-lsr-flex-algo-bw-...@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-...@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee


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

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply, please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, May 14, 2021 5:12 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr@ietf.org
> Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
> Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth,
> Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
> 
> Hi Jie,
> 
> please see the response for one of your questions inline:
> 
> On 14/05/2021 09:52, Dongjie (Jimmy) wrote:
> > Hi authors,
> >
> > I’ve read the latest version of this document and have the following
> > comments:
> >
> > 1.Is the generic metric type applicable to applications other than
> > Flex-Algo? If so, it is better to make this clear in the document, or
> > perhaps it may be defined separately from the Flex-Algo specific extensions?
> >
> > 2.The “Exclude Minimum Bandwidth” constraint is compared with the
> > maximum link bandwidth to exclude the links from the computation, it
> > would be helpful if there is some analysis about how much this can
> > help in traffic engineering, such as to reduce the congestion or
> > improve the link utilization. One simple example is, if multiple
> > Flex-Algos use this constraint to exclude the same set of links, this
> > may increase the possibility of congestion on the rest of the links?
> >
> > Perhaps a more general question is, what would be the benefit of
> > introducing bandwidth attribute into Flex-Algo based distributed path
> > computation?  It is known that bandwidth can be used in centralized
> > computation for efficient path placement and resource management, can
> > distributed computation with bandwidth constraint achieve the same, or
> > is there some advantages compared with centralized computation?
> >
> > 3.With the automatic metric calculation, it could introduce per
> > Flex-Algo link metric value, while the existing Flex-Algo only refers
> > to the metric of the link via metric type. Is this the expected behavior?
> > Will it be further extended to make other link attributes flex-algo
> > specific?
> 
> we need to distinguish between:
> 
> a) flex-algo application specific metric (applies to all flex-algos)
> b) flex-algo X specific metric

Yes, here I mean flex-algo number specific metric.

> 
> (a) already exists in the form of the ASLA advertisement for delay and 
> TE-metric.
> Bandwidth metric will be no different.
> 
> (b) there has been no such thing as flex-algo X specific metric/attribute 
> defined
> so far. And we are not defining it in this draft either. The draft defines 
> sub-TLVs
> for automatic bandwidth metric calculation. It is the winning FAD for the
> Flex-Algorithm X that specifies whether the automatic bandwidth metric
> calculation is done or not and it would be rather complicated (certainly 
> possible)
> to have the parameters for such calculation being advertised outside of the
> FAD.
> 
> You are right these being part of the FAD may result in the calculated 
> bandwidth
> metric being different for each flex-algo on the same link.
> The intention was NOT to have the different per algo bandwidth metric value,
> rather it was the convenience of reusing the FAD that was the motivation for
> the existing encoding.

Understood. Perhaps some text to clarify this would be helpful, such as:

The reference bandwidth is considered a global parameter for the network, it is 
not expected to use different reference bandwidth for different flex-algos.

> 
> So to answer your question, we do NOT intend to make any link attributes per
> flex-algo number.

This answer is clear, thanks.

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> 
> 
> >
> > 4.In the reference bandwidth method, the draft says it simplifies the
> > management in case the reference bandwidth needs to be changed. Since
> > the reference bandwidth applies to the metric calculation of all the
> > links in the flex-algo with the same proportion, it seems the change
> > of the reference bandwidth will not impact the result of the path
> > computation in the flex-algo. In which case the reference bandwidth
> > need to be changed?
> >
> > Best regards,
> >
> > Jie
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
> > (acee)
> > *Sent:* Thursday, May 13, 2021 5:09 AM
> > *To:* lsr@ietf.org
> > *Cc:* draft-hegde-lsr-flex-algo-bw-...@ietf.org
> > *Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
> > Bandwidth, Delay, Metrics and Constrai

Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Dongjie (Jimmy)]

Hi authors,

I’ve read the latest version of this document and have the following comments:


1.   Is the generic metric type applicable to applications other than 
Flex-Algo? If so, it is better to make this clear in the document, or perhaps 
it may be defined separately from the Flex-Algo specific extensions?


2.   The “Exclude Minimum Bandwidth” constraint is compared with the 
maximum link bandwidth to exclude the links from the computation, it would be 
helpful if there is some analysis about how much this can help in traffic 
engineering, such as to reduce the congestion or improve the link utilization. 
One simple example is, if multiple Flex-Algos use this constraint to exclude 
the same set of links, this may increase the possibility of congestion on the 
rest of the links?



Perhaps a more general question is, what would be the benefit of introducing 
bandwidth attribute into Flex-Algo based distributed path computation?  It is 
known that bandwidth can be used in centralized computation for efficient path 
placement and resource management, can distributed computation with bandwidth 
constraint achieve the same, or is there some advantages compared with 
centralized computation?



3.   With the automatic metric calculation, it could introduce per 
Flex-Algo link metric value, while the existing Flex-Algo only refers to the 
metric of the link via metric type. Is this the expected behavior? Will it be 
further extended to make other link attributes flex-algo specific?



4.   In the reference bandwidth method, the draft says it simplifies the 
management in case the reference bandwidth needs to be changed. Since the 
reference bandwidth applies to the metric calculation of all the links in the 
flex-algo with the same proportion, it seems the change of the reference 
bandwidth will not impact the result of the path computation in the flex-algo. 
In which case the reference bandwidth need to be changed?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org
Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, 
Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

 https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and 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

[Dongjie (Jimmy)]

Hi Acee,

I agree with what Chongfeng said about VTN. It refers to a virtual underlay 
network with specific topology and resource attributes, and the topology of 
VTNs can be specified using multi-topology. It is important to understand the 
difference between a VTN and a logical network topology.

As for the deployment choice and scalability, 
draft-dong-teas-enhanced-vpn-vtn-scalability gives some detailed analysis. In 
summary, it says in different network scenarios and phases, the required number 
of VTNs could be different, thus several options may be provided to meet 
different requirements, with different cost and time to market.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Chongfeng Xie
Sent: Friday, March 26, 2021 2:14 PM
To: Acee Lindem (acee) ; 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

Hi，Acee，

Regarding to the issues put forward in your mail, I'd like to provide some 
comments as below,

Q1：I’d like to know of the WG members who supported it, would you really want 
to market it as a VTN solution?

[CF]：VTN is defined in draft-ietf-teas-enhanced-vpn, and also used in other 
documents. It is a technical term to refer to virtual underlay networks with 
specific topology and resource attributes. This document provides an MT based 
mechanism to build VTNs. If for marketing, perhaps it would be better called 
"network slicing":-)

Q2：Those of you who operate networks, would you actually consider deploying it?

[CF]：As an operator we will consider the scenarios and the requirements to pick 
the most suitable solution, IMO this is a good candidate for scenarios where 
the required number of VTN is not very large, and as it requires no new 
encodings, it could be ready for shipment soon. we plans to use this approach 
in some of our network deployment.

Q3：In any case, section 5 needs to be expanded on the scalability and where 
using MTs to support VTNs would make sense and where it wouldn’t.

[CF]：OK. The current section 5 already has some text to cover this, and it can 
be expanded further to clarify.

Best regards
Chongfeng


发件人： Acee Lindem \(acee\)
发送时间： 2021-03-26 02:20
收件人： 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
Speaking as WG chair:

There has been considerable support for this document. However, there has also 
been objections to the document. The objections are either that there is 
nothing to standardize given that all pieces exist and that the MT isn’t a 
viable option for VTNs since it isn’t scalable.

Since most of the draft’s support is from “friends and family”, I’d like to 
know of the WG members who supported it, would you really want to market it as 
a VTN solution? Those of you who operate networks, would you actually consider 
deploying it?

In any case, section 5 needs to be expanded on the scalability and where using 
MTs to support VTNs would make sense and where it wouldn’t.

Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Tuesday, March 2, 2021 at 6:28 PM
To: "lsr@ietf.org" mailto: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] draft-zhu-lsr-isis-sr-vtn-flexalgo

[Dongjie (Jimmy)]

Hi Peter,

Thanks for your comments. Please see some replies inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Tuesday, March 9, 2021 5:46 PM
> To: lsr@ietf.org
> Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
> 
> Dear authors,
> 
> here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:
> 
> 1. whether we want to flood VTN specific link data in IGPs or not is something
> that deserves its own discussion.

IGP as one option can be used to distribute the VTN specific link information 
among network nodes, and some of these nodes could further distribute this 
information to a network controller using BGP-LS. This is similar to the 
distribution and collection of the TE link attributes of the underlay network. 

> 2. Nevertheless, the proposed encoding does not seem to be a fortunate one:
> 
> a) it hijacks the L2 bundle member TLV for VTN data. I don't see the need for
> that.

It is considered as one option to advertise the VTN specific link information 
when Flex-Algo ID is re-used to identify a VTN, as there is no existing 
mechanism to advertise per-Flex-Algo link attributes (this is a difference 
between MT and Flex-Algo). And based on the L2 bundle mechanism, only minor 
extension is needed. 

> b) the proposed mechanism to associate the VTN specific link data with the VTN
> itself by the use of the link affinities is a very user unfriendly way of 
> doing it. If
> the VTN need only the low latency optimization, provisioning additional
> affinities seems like a unnecessary provisioning price that would need to be 
> paid
> by the user for the encoding deficiency. You want to flood the VTN specific 
> link
> data, put the VTN ID in it.

A VTN is associated with not only the metric types defined in the Flex-Algo, it 
is also associated with a subset of network resources. Thus different VTNs with 
low latency optimization may need to correlate with different set of resources 
for packet forwarding, hence different Admin Groups are needed to distinguish 
the different set of link attributes of a L3 link. Using Admin Group (link 
affinity) to correlate the link attributes with a Flex-Algo is the mechanism 
introduced in the Flex-Algo base document, this document tries to reuse the 
existing mechanisms when possible.

Introducing a VTN-ID is another option, which would require a little more 
extensions. That mechanism is described in draft-dong-lsr-sr-for-enhanced-vpn, 
which is targeted to provide a more scalable solution with the additional 
protocol extensions. 

Hope this provides some background about this design. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> 
> 
> ___
> 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

[Dongjie (Jimmy)]

Hi,

Since this discussion is not related to the adoption poll for 
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want 
to discuss other documents.

A brief reply:

In the current version or any previous version of 
draft-peng-teas-network-slicing, there is no scalability considerations, nor 
any mechanism to improve the scalability. While the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose 
one year ago. Thus I think your statement is totally wrong.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>
Sent: Tuesday, March 9, 2021 10:52 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>; 
rob...@raszuk.net<mailto:rob...@raszuk.net>; 
ts...@juniper.net<mailto:ts...@juniper.net>; 
chongfeng@foxmail.com<mailto:chongfeng@foxmail.com>; 
ginsberg=40cisco@dmarc.ietf.org<mailto:ginsberg=40cisco@dmarc.ietf.org>;
 lsr@ietf.org<mailto:lsr@ietf.org>; a...@cisco.com<mailto:a...@cisco.com>; 
tonysi...@gmail.com<mailto:tonysi...@gmail.com>
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




Hi Jie,



Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/



I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.



Regards,

PSF


原始邮件
发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;
日 期 ：2021年03月09日 00:31
主 题 ：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
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
Hi Tarek,

Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie
 
From: Tarek Saad [mailto:ts...@juniper.net]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:ginsberg=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

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 
addit

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 Tarek,

Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie

From: Tarek Saad [mailto:ts...@juniper.net]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) ; Gyan Mishra ; 
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

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] 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:ginsberg=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

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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

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] 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 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

___
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

[Dongjie (Jimmy)]

Hi Robert,

In my interpretation, you also think this document is useful to the operators.

This document does not introduce new encodings to IS-IS, while it provides 
information which was not covered explicitly in the specifications of the 
protocol encodings. For example, with the VTN mechanism, how traffic in 
different topologies are forwarded on a shared outgoing interface. There are 
also other points as mentioned in Chongfeng’s mail. Thus IMO it has its value 
as an informational LSR document.

A WG on IGP operation may be helpful. Before that happens, all the IGP stuff 
belongs to LSR:)

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Saturday, March 6, 2021 7:10 PM
To: Les Ginsberg (ginsberg) ; Chongfeng 
Xie 
Cc: lsr@ietf.org; Acee Lindem (acee) 
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


Hello,

I agree with Les that this draft may not be a fit for LSR WG.

Typically this type of effort (essentially describing use cases) is much better 
to be put in slides and present on various operators forums.

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.

Thx,
R.



On Thu, Mar 4, 2021 at 5:18 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Chongfeng –

Just to clarify my position…

IMO there is no substantive content in this draft that warrants it becoming an 
RFC – Informational track or otherwise. It is simply a set of pointers to other 
documents/registries.

If the authors find the content in some way helpful, I think the more suitable 
path for you is to publish a white paper and post it on whatever web site seems 
appropriate to you.
I just do not see any content in the draft that warrants a standards body like 
IETF producing a new document.

Thanx.

   Les


From: Chongfeng Xie 
mailto:chongfeng@foxmail.com>>
Sent: Thursday, March 04, 2021 5:04 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; 
lsr@ietf.org
Subject: Re: 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， Les,

Thanks for the review of this document.

As the current document type is informational, it does not introduce new TLV to 
IS-IS. While it describes the mechanisms of using existing TLVs to distribute 
the information of SR based VTNs, which can have customized topology and a set 
of dedicated network resources. It also describes the forwarding behaviors 
based on the SIDs and the resources allocated to each VTN.

IS-IS MT as defined in RFC 5120 provides the mechanisms to build multiple 
logical topologies and perform independent path computation for each topology. 
RFC 5120 mentions that the TE attributes TLVs can be inherited by the MT TLVs 
“if traffic engineering or some other applications are being applied per 
topology level later”. While it does not specify what the topology-specific TE 
attributes mean, and how traffic in different topologies are forwarded on a 
shared outgoing interface. These are described in section 3 and section 4 of 
this document.

RFC8667 and draft-ietf-lsr-isis-srv6-extensions defines the encoding of SR 
SIDs/SRv6 Locators in IS-IS, while the usage of the topology-specific SIDs and 
Locators are not specified, especially when the SIDs are associated with 
different set of network resources.

Section 5 gives the analysis about the scalability of this mechanism, and talks 
about a case where two VTNs have the same logical topology, but with different 
set of resources.

IMO the value of this document is that it provides an option to build SR VTNs 
with no IS-IS protocol extensions, which could be useful for some network 
scenarios.

Best regards,
Chongfeng


chongfeng@foxmail.com

发件人： Les Ginsberg \(ginsberg\)
发送时间： 2021-03-04 11:52
收件人： 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
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 

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

[Dongjie (Jimmy)]

Hi Robert,

I have similar question as yours: whether the proposed mechanism is based on 
static or dynamic bandwidth/latency metric?

If static, it is easy for Flex-Algo based distributed computation, while the 
result may not be that helpful, as Tony said, all traffic may be steered to the 
same link.

If dynamic, the changes in the metric will result in dynamic computation with 
Flex-Algo constraints, thus more need to be considered: measurement and 
advertisement of dynamic metrics, overhead in dynamic computation, loop 
prevention during dynamic computation and convergence, the possibility of an 
unacceptable result… And with all this overhead in mind, it is better to 
understand what would be the gains, can it help to reduce the congestion or 
packet drop? Or what possible problem it is targeted to solve?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, March 2, 2021 4:22 AM
To: Tony Li 
Cc: 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

Hi Tony,

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.

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.

Thx,
R.





On Mon, Mar 1, 2021 at 7:42 PM Tony Li 
mailto:tony...@tony.li>> wrote:

Hi William, Gyan, Robert, Tony, et. al.,

Please permit me to wax a bit philosophic here.

William is exactly correct that the goal is not to make FlexAlgo deal with 
reservations like RSVP does.  Without some kind of setup protocol or global 
computation, that’s simply not possible. Moreover that’s not the real problem 
that we’re out to solve.

Reservations are just a first order approximation to a traffic flow in any 
case. We characterize them as having a fixed constant bandwidth, but we all 
know that that is far from the truth. Each flow is diurnal and fractally 
bursty. Every user who ever clicks on a link creates bandwidth demand and while 
the Law of Large Numbers helps us out with some averages we all know that we 
have no good way of characterizing the traffic that we’re trying to carry. 
Claiming that it is a single 12Gbps LSP is truly a huge over simplification and 
a good step towards solving the real problem.

So what is the real problem that we’re trying to solve?

We are trying to not drop packets.

Dropping packets is bad because it forces retransmissions and impacts someone’s 
Internet experience. Dropping packets is our response to congestion events. If 
we could manage to have a network that never congested and always delivered 
packets without giant latency, all would be good.

To date, we have created traffic engineering mechanisms to help us steer 
traffic so that we could delivery traffic without congesting. It has been a 
means to an end. The mechanisms that we’ve created have a non-trivial overhead 
and approximate our goals, but they do NOT preclude, anticipate, or avoid 
congestion. They do not react when we have unexpected inputs. We do extensive 
pre-computation to deal with even single failures and have no serious 
mechanisms that handle multiple failures.

Right now, FlexAlgo does nothing to help with bandwidth management. Wiilliam 
et. al., are proposing some first steps, which are to be encouraged. Much more 
will be needed, not to recreate legacy mechanisms but because we should be 
striving for a more sophisticated, real-time approach to bandwidth management 
and congestion avoidance.

Regards,
Tony



On Mar 1, 2021, at 2:24 AM, William Britto A J 
mailto:bwilliam=40juniper@dmarc.ietf.org>>
 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 mailto:hayabusa...@gmail.com>>
Date: Saturday, 27 February 2021 at 9:40 PM
To: Robert Raszuk 

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Robert,

Please see inline:

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Friday, December 11, 2020 5:16 PM
To: Dongjie (Jimmy) 
Cc: Peter Psenak ; Acee Lindem (acee) 
; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hi Jie,

But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the 
destination address, when the packet arrives at E, it will be dropped, because 
node E does not have the forwarding entry for C's SRv6 SID in FA 128.

* How can E be on the SRv6 SID list if it did not advertise SRv6 participation 
in the first place ?

[Jie] In this case, there is no SID list in the packet, only node C’s SRv6 SID 
associated with FA 128 is carried in the destination IP field. While in node 
A’s (also D’s) FA computation, node E is on the lowest latency path to C.

* What do you mean by "SRv6 SID in FA 128" ? Aren't SIDs global and not per FA ?

[Jie] Yes the SRv6 SIDs are global. Node C will assign different SRv6 SIDs for 
each FA it participates in. here I mean node C’s SRv6 SID which is associated 
with FA 128.

Btw this is good discussion but how is this related to IP Flex Algo topic/draft 
?

[Jie] This is about the rules of defining new applications for Flex-Algo. As I 
mentioned in previous mails, it is not quite clear to me why IP and SR are 
defined as different applications, while SR-MPLS and SRv6 are defined as one 
application, and IPv4 and IPv6 are defined as one application. There may be 
other applications in future. As Zhibo said, it is better to have a clear and 
consistent rule in the beginning.

Last - I do share your concern on how topology computation can be data plane 
independent. Yes it works for IP Flex Algo when IPv4 and IPv6 are topologically 
congruent, but when you add running SR on subset of nodes to the mix it is no 
longer the case.

[Jie] Agreed.

Best regards,
Jie

Thx,
R.


___
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

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, December 10, 2020 9:22 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm)
> In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Hi Jimmy,
> 
> On 10/12/2020 13:02, Dongjie (Jimmy) wrote:
> > In Flex-Algo draft, it says:
> >
> > "Application-specific Flex-Algorithm participation advertisements MAY be
> topology specific or MAY be topology independent, depending on the
> application itself."
> >
> > The preassumption of current IP Flex-Algo participation is that one node
> always participate in a Flex-Algo for both IPv4 and IPv6, and for all the
> topologies it joins.
> >
> > I'm not saying this does not work, just want to understand the reason of 
> > this
> design, and whether some flexibility (e.g. AF specific or topology specific) 
> would
> be useful in some cases.
> >
> 
> this was the choice of authors, because there does not seem to be a string
> reason to do it per topology.
> 
> 
> > BTW, a similar case is about SR-MPLS and SRv6 being treated as a single
> application. Below is the discussion quoted from a previous mail on this list:
> >
> >[Jie] OK. While the meaning of "app" here maybe a little vague, are
> SR-MPLS and SRv6 considered the same or different apps?
> >
> >[Peter] These are considered as single app, and share the same
> participation signaling. Please note that SRv6 support is signaled 
> independently
> of FA participation.
> >
> > Does this imply that for Flex-Algo path computation with SRv6, in addition 
> > to
> the Flex-Algo participation information, the SRv6 support information of nodes
> also needs to be considered, so that nodes participate in this Flex-Algo but 
> do
> not support SRv6 will be pruned from the topology?
> 
> no.

Let me elaborate with an example:

  20   20
A--B---C  
 10 |  10 |/
||   /  10
D--E --*
  10

(The metrics on the links are delay metric)

- Flex-Algo 128 is defined to use delay metric for computation. This FAD is 
application independent, thus can be used by all applications. 

- All of the nodes (A, B, C, D, E) participate in FA 128.

- Node A, B, C, D support both SR-MPLS and SRv6.

- Node E support SR-MPLS only, it may support IPv6. 

Then node A computes the path to node C with FA 128. According to the 
computation rules of FA 128, the path would be A-D-E-C. This path can be used 
to send SR-MPLS packet to node C. 

But if node A sends SRv6 packets with node C's SRv6 SID in FA 128 as the 
destination address, when the packet arrives at E, it will be dropped, because 
node E does not have the forwarding entry for C's SRv6 SID in FA 128.

Do you think this is a problem?

IMO this problem is due to the FA calculation is based on the combination of 
the constraints in FA definition, and the nodes' FA participation (which is app 
specific), while since SR-MPLS and SRv6 are treated as one single application, 
the difference in supporting SR-MPLS or SRv6 is not considered in FA 
calculation. This is why I asked whether the SRv6 support information also need 
be considered in FA calculation.

To solve this problem, there are several options: 

Option 1: Define two different Flex-Algos for delay metric computation, one for 
SR-MPLS, the other one for SRv6. But this makes the FAD application dependent. 
Option 2: Include the SR-MPLS or SRv6 information in Flex-Algo participation, 
i.e. make SR-MPLS and SRv6 separate applications.
Option 3: Also consider the SRv6 (or SR-MPLS) capability information in FA 
calculation. 

Or do you have other options in mind?

Best regards,
Jie

> thanks,
> Peter
> 
> 
> > If so, IMO this needs to be specified in the Flex-Algo draft. If not, please
> clarify how to prune the nodes which participate in the same Flex-Algo for
> SR-MPLS only? Thanks.
> >
> > Best regards,
> > Jie

___
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

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, December 10, 2020 5:05 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
> (Flex-Algorithm)
> In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Hi Jimmy,
> 
> On 10/12/2020 09:06, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Wednesday, December 9, 2020 9:06 PM
> >> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> >> ; lsr 
> >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>
> >> Hi Jimmy,
> >>
> >> On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>>> -Original Message-
> >>>> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>>> Sent: Wednesday, December 9, 2020 6:45 PM
> >>>> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> >>>> ; lsr 
> >>>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>>>
> >>>> Jimmy,
> >>>>
> >>>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> >>>>> Hi authors,
> >>>>>
> >>>>> Here is one comment following the previous discussion on the mail
> >>>>> list and the IETF meeting.
> >>>>>
> >>>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> >>>>> participation information, there is no separate TLV for IPv4 or
> >>>>> IPv6 Flex-Algo participation.
> >>>>
> >>>> the draft clearly says:
> >>>>
> >>>>   "The IP Flex-Algorithm participation advertised in ISIS IP 
> >>>> Algorithm
> >>>>   Sub-TLV is topology independent."
> >>>
> >>> This does not answer my question.
> >>>
> >>> Section 7 gives the rules of IP Flex-Algo Path calculation:
> >>>
> >>> " IP Flex-Algorithm application only considers participating nodes
> >>> during
> >> the Flex-Algorithm calculation.  When computing paths for a given
> >> Flex-Algorithm, all nodes that do not advertise participation for IP
> >> Flex-Algorithm, as described in Section 5, MUST be pruned from the
> >> topology."
> >>>
> >>> >From IP Algorithm TLV, one cannot tell whether a node participates
> >>> >in
> >>>> Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
> >>>> described below: >
> >>> When one node uses IP Flex-Algo participation to compute a path for
> >>> an
> >> IPv6 address advertised with Flex-Algo 128, it will not prune the
> >> nodes which participate in Flex-Algo 128 for IPv4 only from the
> >> topology. Thus IPv6 packets following that path may get dropped on
> >> nodes which participates in Flex-Algo 128 for IPv4 only.
> >>
> >> FA calculation is done for every MT topology independently.
> >>
> >> For IPv4 it will take all routers participating in MT0 and run the FA
> >> calculation on top of MT0.
> >>
> >> For IPv6 it will take all routers participating in MT2 and run the FA
> >> calculation on top of MT2.
> >>
> >
> > Using different MTs for different data plane and run FA path computation
> within each MT may solve the problem in many cases.
> >
> > While the different rules related to FA definition, FA participation, and FA
> reachability advertisement still make me a little confused, and there may be
> some cases not covered by the above approach.
> >
> > - Flex-Algo definition is application independent and topology independent.
> >
> > - IP Flex-Algo participation is application specific and topology 
> > independent.
> >
> > - IPv4 and IPv6 are considered as one application, while may use different
> topologies.
> >
> > - IP Flex-Algo reachability advertisement is per AF, and may with different
> topologies.
> >
> > With the above rules, let's consider the case below:
> >
> > - A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).
> >

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, December 9, 2020 9:06 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; lsr 
> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> 
> Hi Jimmy,
> 
> On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Wednesday, December 9, 2020 6:45 PM
> >> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> >> ; lsr 
> >> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
> >> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
> >>
> >> Jimmy,
> >>
> >> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
> >>> Hi authors,
> >>>
> >>> Here is one comment following the previous discussion on the mail
> >>> list and the IETF meeting.
> >>>
> >>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
> >>> participation information, there is no separate TLV for IPv4 or IPv6
> >>> Flex-Algo participation.
> >>
> >> the draft clearly says:
> >>
> >>  "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
> >>  Sub-TLV is topology independent."
> >
> > This does not answer my question.
> >
> > Section 7 gives the rules of IP Flex-Algo Path calculation:
> >
> > " IP Flex-Algorithm application only considers participating nodes during
> the Flex-Algorithm calculation.  When computing paths for a given
> Flex-Algorithm, all nodes that do not advertise participation for IP
> Flex-Algorithm, as described in Section 5, MUST be pruned from the
> topology."
> >
> >>From IP Algorithm TLV, one cannot tell whether a node participates in
> >>Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem
> >>described below: >
> > When one node uses IP Flex-Algo participation to compute a path for an
> IPv6 address advertised with Flex-Algo 128, it will not prune the nodes which
> participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6
> packets following that path may get dropped on nodes which participates in
> Flex-Algo 128 for IPv4 only.
> 
> FA calculation is done for every MT topology independently.
> 
> For IPv4 it will take all routers participating in MT0 and run the FA
> calculation on top of MT0.
> 
> For IPv6 it will take all routers participating in MT2 and run the FA
> calculation on top of MT2.
> 

Using different MTs for different data plane and run FA path computation within 
each MT may solve the problem in many cases.

While the different rules related to FA definition, FA participation, and FA 
reachability advertisement still make me a little confused, and there may be 
some cases not covered by the above approach.

- Flex-Algo definition is application independent and topology independent.

- IP Flex-Algo participation is application specific and topology independent.

- IPv4 and IPv6 are considered as one application, while may use different 
topologies.

- IP Flex-Algo reachability advertisement is per AF, and may with different 
topologies.

With the above rules, let's consider the case below:

- A node participates in both MT 0 (for IPv4) and MT 2 (for IPv6).

- This node advertises its IP Flex-Algo participation of FA 128. 

- This node advertises IPv4 Flex-Algo reachability with MT=0/FA=128.

- This node does NOT advertise IPv6 Flex-Algo reachability for FA 128. It may 
advertise normal IPv6 reachability in MT 2. 

Thus this node is not reachable in MT 2 with FA 128. While it will be 
considered by other nodes for path computation in MT 2 with FA 128. 

The question is: will this node compute paths for other IPv6 prefixes 
advertised with MT=2/FA=128? 

If not, this node may drop packets whose destination is IPv6 prefixes with FA 
128. 

And do you think it is needed to provide approach to only consider this node 
for IPv4 path computation with FA 128, and prune it from IPv6 path computation 
with FA 128? For example, make the IP Flex-Algo participation per AF or per 
topology?

Best regards,
Jie

> >>
> >>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
> >>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
> >>> computed for IPv6 Flex-Algo will not use the nodes which only
> >>> participate in IPv4 Flex-Algo 128?
> >>
> >> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Fl

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Dongjie (Jimmy)]

Hi Parag,

Thanks for your reply. While perhaps I should make my comment clearer:

I agree a node which does not support a particular address family (e.g. IPv6) 
will not install route for that family. While according to the rules in section 
7, this node will be included in the topology for path computation of one 
Flex-Algo by another node, just because it advertises the participation to the 
same Flex-Algo for another address family (e.g. IPv4). In my understanding this 
would cause packet drop. Did I miss something?

Best regards,
Jie

From: Parag Kaneriya [mailto:pkane...@juniper.net]
Sent: Wednesday, December 9, 2020 6:46 PM
To: Dongjie (Jimmy) ; Acee Lindem (acee) 
; lsr 
Subject: RE: WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In 
IP Networks" - draft-bonica-lsr-ip-flexalgo-01

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

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


___
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

[Dongjie (Jimmy)]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

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


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

Re: [Lsr] IETF I09 LSR Meeting Minutes

[Dongjie (Jimmy)]

Hi Acee,

One small nit about the minutes for the first topic:

Peter: I commented earlier. The way the total constaints are being
   used. Basically a bundle must advertise the summary of all
   the included affinities of the individual members, can't
   use an exclude or combined exclude was included because
   that would break. So, if this is what the author had planned
   to do then the restriction should be clearly described
   in the draft.

I guess “can’t use an exclude or combined exclude was included” should be 
“can’t use an exclude or combined exclude with include”.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: lsr@ietf.org
Subject: [Lsr] IETF I09 LSR Meeting Minutes

I have uploaded the minutes for the meeting on Monday morning. Thanks much to 
Yingzhen Qu for taking them. Please send me any additions or corrections to me.

https://datatracker.ietf.org/doc/minutes-109-lsr/

Presenters and draft authors, please note that if more discussion is need on 
your draft then it is up to you to initiate such discussion.

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

Re: [Lsr] 回复: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt

[Dongjie (Jimmy)]

Hi Huanan,

Thanks a lot for your review and comments.

My understanding is as Flex-Algo is defined by operator, different Flex-Algos 
can be defined for different purpose and with different constraints. Thus it is 
possible to use different Flex-Algos for both the normal case and the VTN case 
in the same network.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of chenhu...@chinatelecom.cn
Sent: Sunday, October 25, 2020 8:05 AM
To: 朱永庆@chinatelecom ; lsr@ietf.org
Subject: Re: [Lsr] 回复: New Version Notification for 
draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt

Hi authors,

I’ve reviewed this document.  The draft provides a useful mechanism to enable 
VTNs based on minor extensions to Flex-Algo and L2 bundle.

One comment is: in one network, can some Flex-Algos be used for its traditional 
usage, and some other Flex-Algos be used for VTNs as described in this document?

BR.

HuaNan

发件人： zhu...@chinatelecom.cn<mailto:zhu...@chinatelecom.cn>
发送时间： 2020-09-16 14:13
收件人： lsr@ietf.org<mailto:lsr@ietf.org>
主题： [Lsr] 回复: New Version Notification for 
draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
Hi WG,

We just submitted a new revision of draft-zhu-lsr-isis-sr-vtn-flexalgo. This 
document specifies a mechanism to use Flex-Algo together with small extensions 
to IS-IS L2 bundle to distribute the topology and resource attribute of SR 
based VTN. Your review and comments are appreciated.
B.R.
Zhu Yongqing

-邮件原件-
发件人: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
发送时间: 2020年9月11日 17:11
收件人: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; 
Yongqing Zhu mailto:zhu...@chinatelecom.cn>>; Huzhibo 
mailto:huzh...@huawei.com>>
主题: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt


A new version of I-D, draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
has been successfully submitted by Jie Dong and posted to the IETF repository.

Name:   draft-zhu-lsr-isis-sr-vtn-flexalgo
Revision:   01
Title:  Using Flex-Algo for Segment Routing based VTN
Document date:  2020-09-11
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo
Htmlized:   
https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-zhu-lsr-isis-sr-vtn-flexalgo-01

Abstract:
   As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to
   provide enhanced VPN service to support the needs of enhanced
   isolation and stringent performance requirements.  VPN+ requires
   integration between the overlay VPN and the underlay network.  A
   Virtual Transport Network (VTN) is a virtual network which consists
   of a subset of network topology and network resources allocated from
   the underlay network.  A VTN could be used as the underlay for one or
   a group of VPN+ services.

   I-D.dong-lsr-sr-enhanced-vpn defines the IGP mechanisms with
   necessary extensions to build a set of Segment Routing (SR) based
   VTNs.  This document describes a simplified mechanism to build the SR
   based VTNs using SR Flex-Algo together with minor extensions to IGP
   L2 bundle.





Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Lsr mailing list
Lsr@ietf.org<mailto: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 draft-ietf-lsr-ospf-prefix-originator-06

[Dongjie (Jimmy)]

Hi Chris, 

I support the publication of this document, and as co-author I am not aware of 
any undisclosed IPR.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Thursday, October 15, 2020 2:15 PM
> To: lsr@ietf.org
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org;
> lsr-...@ietf.org; Christian Hopps 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
> 
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>   Please indicate to the list, your knowledge of any other IPR related to this
> work.
> 
> Thanks,
> Chris.

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

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Robert and Peter,

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Tuesday, October 13, 2020 7:55 PM
> To: Robert Raszuk 
> Cc: Dongjie (Jimmy) ; Gyan Mishra
> ; Ron Bonica ; lsr@ietf.org;
> Jeff Tantsura ; Yingzhen Qu
> 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Robert,
> 
> 
> On 13/10/2020 13:38, Robert Raszuk wrote:
> > Peter,
> >
> > If this is per app how are the constraints shared across apps ?
> 
> FAD constraints are only used for calculating the flex-algo path.

Agree that FAD just defines the constraints for path computation, and as 
discussed computation with Flex-Algo constraints needs to be done using nodes 
which bind the Flex-Algo to the same app/data plane.

> >
> > See we have single physical resources (for example links) and single
> > interface outbound queues. If I use per app flex-algo and do not have
> > central controller how is this going to work in practice for any
> > network which attempts to use more then one forwarding schema with
> > dynamic constraints ?
> 
> flex-algo defines the way to calculate constraint based paths in a distributed
> manner and guarantees the loop free forwarding over such path.
> 
> Possible per app and/or per algo resource allocation at each hop is not
> something that flex-algo spec attempts to solve. That does not mean it is not
> possible. I don't see anything in the flex-algo spec that would prevent one 
> to do
> that.

Yes for that purpose some extensions based on Flex-Algo would be needed.

For per-Algo resource allocation, please refer to 
draft-zhu-lsr-isis-sr-vtn-flexalgo-01. For per app resource allocation and 
identification , you may refer to draft-dong-lsr-sr-enhanced-vpn-04. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> >
> > Many thx,
> > R.
> >
> >
> >
> > On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak
> >  > <mailto:40cisco@dmarc.ietf.org>>
> > wrote:
> >
> > Hi Jimmy,
> >
> > On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> >  > Hi Peter,
> >  >
> >  > Thanks for your reply. Please see further inline:
> >  >
> >  >> -Original Message-
> >  >> From: Lsr [mailto:lsr-boun...@ietf.org
> > <mailto:lsr-boun...@ietf.org>] On Behalf Of Peter Psenak
> >  >> Sent: Monday, October 12, 2020 4:39 PM
> >  >> To: Dongjie (Jimmy)  > <mailto:jie.d...@huawei.com>>; Ron Bonica
> >  >> mailto:rbon...@juniper.net>>; Yingzhen Qu
> > mailto:yingzhen...@futurewei.com>>;
> Gyan
> >  >> Mishra  <mailto:hayabusa...@gmail.com>>
> >  >> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; Jeff Tantsura
> > mailto:jefftant.i...@gmail.com>>
> >  >> Subject: Re: [Lsr] FW: New Version Notification for
> >  >> draft-bonica-lsr-ip-flexalgo-00.txt
> >  >>
> >  >> Hi Jimmy,
> >  >>
> >  >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> >  >>> Hi Peter,
> >  >>>
> >  >>> Thanks for your reply. It aligns with my understanding of FAD,
> > which is just a
> >  >> set of constraints for path computation. Thus one Flex-Algo ID
> > could be used
> >  >> with multiple different data planes. Is this understanding correct?
> >  >>
> >  >> correct.
> >  >>
> >  >>>
> >  >>> If so, my question is about the scenario below:
> >  >>>
> >  >>> A group of nodes in a network support FA-128, a sub-group of
> > them bind
> >  >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP
> > address.
> >  >>
> >  >> just to use the correct terminology, we should use "participate"
> > instead of
> >  >> "support".
> >  >
> >  > Agree.
> >  >
> >  >>
> >  >>> When one node compute an SR path to a destination, can it
> > compute the path
> >  >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> >  >> nodes >which bind FA-128 to IP address? If so, how could this
> > node know the
> >  >> binding of FA to different data planes on other nodes?
> >  >>
> >  >> again, it i

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Peter, 

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Tuesday, October 13, 2020 4:53 PM
> To: Dongjie (Jimmy) ; Ron Bonica
> ; Yingzhen Qu ; Gyan
> Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> >>> When one node compute an SR path to a destination, can it compute
> >>> the path
> >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> >> nodes >which bind FA-128 to IP address? If so, how could this node
> >> know the binding of FA to different data planes on other nodes?
> >>
> >> again, it is the participation problem.
> >>
> >> Nodes that participate in the SR Flex-algo 128 will advertise the
> >> participation using the SR-Algorithm Sub-TLV. Only these nodes will
> >> be used during the SR flex-algo computation for algo 128.
> >>
> >> Nodes that participate in IP flex-algo 128 will advertise the
> >> participation using the IGP Algorithm Sub-TLV. Only these nodes will
> >> be used during the IP flex-algo computation for algo 128.
> >
> > Agree that if participation to Flex-Algo is advertised in a data plane 
> > specific
> manner, then path computation with Flex-Algo constraints could be done only
> using nodes which bind the Flex-Algo to the same data plane.
> 
> it's per app, not per data plane, but yes, that is what the base flex-algo 
> spec
> mandates.
>
> > As Robert asked and you confirmed, this implies each data plane needs to be
> treated as an independent application of Flex-Algo. We have SR-Algorithm
> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to
> be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo
> participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc.
> separately?
> 
> yes, it needs to be advertised per app. We have SR specific algo 
> participation,
> we need one for IP as proposed in Ron's draft.

OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 
considered the same or different apps? 

> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make the
> participation for IP flex-algo topology specific or topology independent, both
> could work.

If the participation is topology specific, do you mean IPv4 and IPv6 could be 
distinguished by advertising Flex-Algo participation with different Topology 
IDs (MT-ID)? This way, is the topology ID actually used as the address family 
distinguisher?

Best regards,
Jie

> Here's the text from the base flerx-algo draft:
> 
> 10.2.  Advertisement of Node Participation for Other Applications
> 
> This section describes considerations related to how other
> applications can advertise their participation in a specific Flex-
> Algorithm.
> 
> Application-specific Flex-Algorithm participation advertisements MAY
> be topology specific or MAY be topology independent, depending on the
> application itself.
> 
> Application-specific advertisement for Flex-Algorithm participation
> MUST be defined for each application and is outside of the scope of
> this document.
> 
> thanks,
> Peter
> 
> 
> >
> > Best regards,
> > Jie
> >
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>> -----Original Message-
> >>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >>>> Sent: Friday, October 9, 2020 11:58 PM
> >>>> To: Dongjie (Jimmy) ; Ron Bonica
> >>>> ; Yingzhen Qu
> >>>> ; Gyan Mishra 
> >>>> Cc: lsr@ietf.org; Jeff Tantsura 
> >>>> Subject: Re: [Lsr] FW: New Version Notification for
> >>>> draft-bonica-lsr-ip-flexalgo-00.txt
> >>>>
> >>>> Hi Jimmy,
> >>>>
> >>>>
> >>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> >>>>> Hi Ron,
> >>>>>
> >>>>> Thanks for explaining the difference between IP Flex-Algo and SR
> >>>>> Flex-algo. As
> >>>> you said, the major difference is the data plane.
> >>>>>
> >>>>> If my understanding is correct, for one Flex-Algo to be used
> >>>>> correctly, the set
> >>>> of nodes need to apply consistent constraints in computation, and
> >>>> bind the FAD to the same data plane.
&

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply. Please see further inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Monday, October 12, 2020 4:39 PM
> To: Dongjie (Jimmy) ; Ron Bonica
> ; Yingzhen Qu ; Gyan
> Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Jimmy,
> 
> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your reply. It aligns with my understanding of FAD, which is 
> > just a
> set of constraints for path computation. Thus one Flex-Algo ID could be used
> with multiple different data planes. Is this understanding correct?
> 
> correct.
> 
> >
> > If so, my question is about the scenario below:
> >
> > A group of nodes in a network support FA-128, a sub-group of them bind
> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address.
> 
> just to use the correct terminology, we should use "participate" instead of
> "support".

Agree.

> 
> >When one node compute an SR path to a destination, can it compute the path
> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the
> nodes >which bind FA-128 to IP address? If so, how could this node know the
> binding of FA to different data planes on other nodes?
> 
> again, it is the participation problem.
> 
> Nodes that participate in the SR Flex-algo 128 will advertise the 
> participation
> using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR
> flex-algo computation for algo 128.
> 
> Nodes that participate in IP flex-algo 128 will advertise the participation 
> using
> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP 
> flex-algo
> computation for algo 128.

Agree that if participation to Flex-Algo is advertised in a data plane specific 
manner, then path computation with Flex-Algo constraints could be done only 
using nodes which bind the Flex-Algo to the same data plane. 

As Robert asked and you confirmed, this implies each data plane needs to be 
treated as an independent application of Flex-Algo. We have SR-Algorithm 
sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to 
be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo 
participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. 
separately?

Best regards,
Jie

> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Friday, October 9, 2020 11:58 PM
> >> To: Dongjie (Jimmy) ; Ron Bonica
> >> ; Yingzhen Qu
> >> ; Gyan Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Jimmy,
> >>
> >>
> >>On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> >>> Hi Ron,
> >>>
> >>> Thanks for explaining the difference between IP Flex-Algo and SR
> >>> Flex-algo. As
> >> you said, the major difference is the data plane.
> >>>
> >>> If my understanding is correct, for one Flex-Algo to be used
> >>> correctly, the set
> >> of nodes need to apply consistent constraints in computation, and
> >> bind the FAD to the same data plane.
> >>>
> >>> Is it possible that different nodes may use the same Flex-Algo with
> >>> different
> >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with
> >> pure IP etc., or each Flex-Algo is always associated with only one
> >> data plane? In the former case, should the flex-algo definition also
> >> indicate the data plane(s) to be used with the flex-algo?
> >>
> >> let me respond to this query, as this is not specific to Ron's draft.
> >>
> >> FAD is data plane agnostic and is used by all of them.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>> -Original Message-
> >>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >>>> Sent: Sunday, October 4, 2020 4:34 AM
> >>>> To: Yingzhen Qu ; Peter Psenak
> >>>> ; Gyan Mishra 
> >>>> Cc: lsr@ietf.org; Jeff Tantsura 
> >>>> Subject: Re: [Lsr] FW: New Version Notification for
> >>>> draft-b

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Jeff,

Thanks for your explanation. I understand that for different data plane the 
SIDs or IP addresses have different scope, and will not conflict in normal 
cases.

My question is more about whether a computation node needs to know and check 
which data plane is used by the intermediate nodes to bind to the Flex-Algo? In 
another word, can an SR path computed using Flex-Algo 128 go through an 
intermediate node which bind Flex-Algo 128 to IP data plane?

Best regards,
Jie

> -Original Message-
> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
> Sent: Sunday, October 11, 2020 3:14 AM
> To: Ron Bonica 
> Cc: Dongjie (Jimmy) ; Peter Psenak
> ; Yingzhen Qu ; Gyan
> Mishra ; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Jie,
> 
> The scoop is different, for SR data plane entry uniqueness is in context of SR
> domain (SID = value + context), while for IP it is global to the routing 
> domain,
> FIB entry is a destination, nothing more.
> 
> Regards,
> Jeff
> 
> > On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
> >
> > Hi Jimmie,
> >
> > Inline.
> >
> >        Ron
> >
> >
> > Juniper Business Use Only
> >
> > -Original Message-
> > From: Dongjie (Jimmy) 
> > Sent: Friday, October 9, 2020 11:06 PM
> > To: Peter Psenak ; Ron Bonica
> > ; Yingzhen Qu ; Gyan
> > Mishra 
> > Cc: lsr@ietf.org; Jeff Tantsura 
> > Subject: RE: [Lsr] FW: New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi Peter,
> >
> > Thanks for your reply. It aligns with my understanding of FAD, which is 
> > just a
> set of constraints for path computation. Thus one Flex-Algo ID could be used
> with multiple different data planes. Is this understanding correct?
> >
> > [RB] I never thought about this. Is there a use-case? I think that it will 
> > work,
> but I would have to try it before saying for sure.
> >
> > If so, my question is about the scenario below:
> >
> > A group of nodes in a network support FA-128, a sub-group of them bind
> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When
> one node compute an SR path to a destination, can it compute the path to only
> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind
> FA-128 to IP address?
> >
> > [RB] I don't think so. However, you could achieve the same outcome using 
> > link
> colors.
> >
> > If so, how could this node know the binding of FA to different data planes 
> > on
> other nodes?
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Friday, October 9, 2020 11:58 PM
> >> To: Dongjie (Jimmy) ; Ron Bonica
> >> ; Yingzhen Qu
> >> ; Gyan Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Jimmy,
> >>
> >>
> >>>  On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> >>> Hi Ron,
> >>>
> >>> Thanks for explaining the difference between IP Flex-Algo and SR
> >>> Flex-algo. As
> >> you said, the major difference is the data plane.
> >>>
> >>> If my understanding is correct, for one Flex-Algo to be used
> >>> correctly, the set
> >> of nodes need to apply consistent constraints in computation, and
> >> bind the FAD to the same data plane.
> >>>
> >>> Is it possible that different nodes may use the same Flex-Algo with
> >>> different
> >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with
> >> pure IP etc., or each Flex-Algo is always associated with only one
> >> data plane? In the former case, should the flex-algo definition also
> >> indicate the data plane(s) to be used with the flex-algo?
> >>
> >> let me respond to this query, as this is not specific to Ron's draft.
> >>
> >> FAD is data plane agnostic and is used by all of them.
> >>
> >> thanks,
> >> Peter
> >>
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>> -Original Message-
> >>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >>>> Sent: Sunday, October

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Ron, 

Please see inline:

> -Original Message-
> From: Ron Bonica [mailto:rbon...@juniper.net]
> Sent: Saturday, October 10, 2020 8:48 PM
> To: Dongjie (Jimmy) ; Peter Psenak
> ; Yingzhen Qu ; Gyan
> Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: RE: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Jimmie,
> 
> Inline.
> 
> Ron
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Dongjie (Jimmy) 
> Sent: Friday, October 9, 2020 11:06 PM
> To: Peter Psenak ; Ron Bonica ;
> Yingzhen Qu ; Gyan Mishra
> 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: RE: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Peter,
> 
> Thanks for your reply. It aligns with my understanding of FAD, which is just 
> a set
> of constraints for path computation. Thus one Flex-Algo ID could be used with
> multiple different data planes. Is this understanding correct?
> 
> [RB] I never thought about this. Is there a use-case? I think that it will 
> work,
> but I would have to try it before saying for sure.

One possible case is to define one Flex-Algo (say FA-128) with delay metric and 
no admin-group (color) constraints. Then as Flex-Algo is data plane agnostic, 
FA-128 could be used to bind to prefix-SIDs, SRv6 locators or IP addresses.

> 
> If so, my question is about the scenario below:
> 
> A group of nodes in a network support FA-128, a sub-group of them bind FA-128
> to SR SIDs, another sub-group of them bind FA-128 to IP address. When one
> node compute an SR path to a destination, can it compute the path to only pass
> the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128
> to IP address?
> 
> [RB] I don't think so. However, you could achieve the same outcome using link
> colors.

Do you mean to use different link colors to identify links with different data 
plane enabled? I believe it would work, while actually this is using different 
Flex-Algos (with different color constraints) for different data plane. 

Best regards,
Jie

> If so, how could this node know the binding of FA to different data planes on
> other nodes?
> 
> Best regards,
> Jie
> 
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Friday, October 9, 2020 11:58 PM
> > To: Dongjie (Jimmy) ; Ron Bonica
> > ; Yingzhen Qu
> > ; Gyan Mishra 
> > Cc: lsr@ietf.org; Jeff Tantsura 
> > Subject: Re: [Lsr] FW: New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > Hi Jimmy,
> >
> >
> >   On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > > Hi Ron,
> > >
> > > Thanks for explaining the difference between IP Flex-Algo and SR
> > > Flex-algo. As
> > you said, the major difference is the data plane.
> > >
> > > If my understanding is correct, for one Flex-Algo to be used
> > > correctly, the set
> > of nodes need to apply consistent constraints in computation, and bind
> > the FAD to the same data plane.
> > >
> > > Is it possible that different nodes may use the same Flex-Algo with
> > > different
> > data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure
> > IP etc., or each Flex-Algo is always associated with only one data
> > plane? In the former case, should the flex-algo definition also
> > indicate the data plane(s) to be used with the flex-algo?
> >
> > let me respond to this query, as this is not specific to Ron's draft.
> >
> > FAD is data plane agnostic and is used by all of them.
> >
> > thanks,
> > Peter
> >
> > >
> > > Best regards,
> > > Jie
> > >
> > >> -Original Message-
> > >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> > >> Sent: Sunday, October 4, 2020 4:34 AM
> > >> To: Yingzhen Qu ; Peter Psenak
> > >> ; Gyan Mishra 
> > >> Cc: lsr@ietf.org; Jeff Tantsura 
> > >> Subject: Re: [Lsr] FW: New Version Notification for
> > >> draft-bonica-lsr-ip-flexalgo-00.txt
> > >>
> > >> Hi Yingzhen,
> > >>
> > >> IP Flexible Algorithms are like SR Flexible Algorithms in the
> > >> following
> > respects:
> > >>
> > >> - Links have IGP metrics, TE metrics, delay metrics and
> > >> administrative colors
> > >> - FADs define Flexible Algorithms
> > >>
>

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply. It aligns with my understanding of FAD, which is just a 
set of constraints for path computation. Thus one Flex-Algo ID could be used 
with multiple different data planes. Is this understanding correct?

If so, my question is about the scenario below: 

A group of nodes in a network support FA-128, a sub-group of them bind FA-128 
to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node 
compute an SR path to a destination, can it compute the path to only pass the 
nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP 
address? If so, how could this node know the binding of FA to different data 
planes on other nodes?

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Friday, October 9, 2020 11:58 PM
> To: Dongjie (Jimmy) ; Ron Bonica
> ; Yingzhen Qu
> ; Gyan Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Jimmy,
> 
> 
>   On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> > Hi Ron,
> >
> > Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. 
> > As
> you said, the major difference is the data plane.
> >
> > If my understanding is correct, for one Flex-Algo to be used correctly, the 
> > set
> of nodes need to apply consistent constraints in computation, and bind the FAD
> to the same data plane.
> >
> > Is it possible that different nodes may use the same Flex-Algo with 
> > different
> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP
> etc., or each Flex-Algo is always associated with only one data plane? In the
> former case, should the flex-algo definition also indicate the data plane(s) 
> to be
> used with the flex-algo?
> 
> let me respond to this query, as this is not specific to Ron's draft.
> 
> FAD is data plane agnostic and is used by all of them.
> 
> thanks,
> Peter
> 
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> >> Sent: Sunday, October 4, 2020 4:34 AM
> >> To: Yingzhen Qu ; Peter Psenak
> >> ; Gyan Mishra 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> Hi Yingzhen,
> >>
> >> IP Flexible Algorithms are like SR Flexible Algorithms in the following
> respects:
> >>
> >> - Links have IGP metrics, TE metrics, delay metrics and
> >> administrative colors
> >> - FADs define Flexible Algorithms
> >>
> >> More specifically, the FAD:
> >>
> >> - Indicates which metric type the Flexible Algorithm uses
> >> - Specifies constraints in terms of link colors that are included or
> >> excluded from the Flexible Algorithm.
> >>
> >> The significant difference between IP Flexible Algorithms and SR
> >> Flexible Algorithms is:
> >>
> >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
> >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
> >>
> >> So, IP Flexible Algorithms can be deployed in any IP network, even in
> >> the absence of SR.
> >>
> >>  Ron
> >>
> >>
> >> Juniper Business Use Only
> >>
> >> -Original Message-
> >> From: Yingzhen Qu 
> >> Sent: Saturday, October 3, 2020 2:08 PM
> >> To: Peter Psenak ; Gyan Mishra
> >> ; Ron Bonica 
> >> Cc: lsr@ietf.org; Jeff Tantsura 
> >> Subject: Re: [Lsr] FW: New Version Notification for
> >> draft-bonica-lsr-ip-flexalgo-00.txt
> >>
> >> [External Email. Be cautious of content]
> >>
> >>
> >> Hi Peter,
> >>
> >> Using flex-algo, a SRv6 locator can be associated with a single algo,
> >> which means an IPv6 or IPv4 address can also be associated with a
> >> single algo. So my understanding is Ron's proposal is making the
> configuration of flex-algo easier?
> >> Instead of using the exclude or include list you can configure a
> >> loopback address to a flex-algo directly?
> >>
> >> Thanks,
> >> Yingzhen
> >>
> >> On 10/3/20, 2:47 AM, "Peter Psenak"  wrote:
> >>
> >>  Hi Yingzhen,
> >>
> >>  On 02/10/2020 22:15, Yingzhen Qu wrote:

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi Ron, 

Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. As 
you said, the major difference is the data plane.

If my understanding is correct, for one Flex-Algo to be used correctly, the set 
of nodes need to apply consistent constraints in computation, and bind the FAD 
to the same data plane.

Is it possible that different nodes may use the same Flex-Algo with different 
data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP etc., 
or each Flex-Algo is always associated with only one data plane? In the former 
case, should the flex-algo definition also indicate the data plane(s) to be 
used with the flex-algo?

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Sunday, October 4, 2020 4:34 AM
> To: Yingzhen Qu ; Peter Psenak
> ; Gyan Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Yingzhen,
> 
> IP Flexible Algorithms are like SR Flexible Algorithms in the following 
> respects:
> 
> - Links have IGP metrics, TE metrics, delay metrics and administrative colors
> - FADs define Flexible Algorithms
> 
> More specifically, the FAD:
> 
> - Indicates which metric type the Flexible Algorithm uses
> - Specifies constraints in terms of link colors that are included or excluded 
> from
> the Flexible Algorithm.
> 
> The significant difference between IP Flexible Algorithms and SR Flexible
> Algorithms is:
> 
> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators
> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses.
> 
> So, IP Flexible Algorithms can be deployed in any IP network, even in the
> absence of SR.
> 
> Ron
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Yingzhen Qu 
> Sent: Saturday, October 3, 2020 2:08 PM
> To: Peter Psenak ; Gyan Mishra
> ; Ron Bonica 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Peter,
> 
> Using flex-algo, a SRv6 locator can be associated with a single algo, which
> means an IPv6 or IPv4 address can also be associated with a single algo. So my
> understanding is Ron's proposal is making the configuration of flex-algo 
> easier?
> Instead of using the exclude or include list you can configure a loopback
> address to a flex-algo directly?
> 
> Thanks,
> Yingzhen
> 
> On 10/3/20, 2:47 AM, "Peter Psenak"  wrote:
> 
> Hi Yingzhen,
> 
> On 02/10/2020 22:15, Yingzhen Qu wrote:
> > Hi Peter,
> >
> > My understanding of flex-algo is that for traffic destined to a prefix 
> on a
> particular algo, it can only be routed on routers belong to that algo, which 
> also
> means only routers in that algo calculates how to reach that prefix and 
> install
> it into the routing table. It seems to me that using flex-algo (section 12 of 
> the
> draft) it's possible to have a loopback address associated with only one algo,
> please correct me if I'm missing or misunderstood something.
> 
> you are right. That is exactly what is being done for flex-algo with
> SRv6 - locator is associated with a single algo only. The proposal uses
> the same concept.
> 
> thanks,
> Peter
> 
> >
> > Thanks,
> > Yingzhen
> >
> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"
> 
> wrote:
> >
> >  Gyan,
> >
> >  On 02/10/2020 18:30, Gyan Mishra wrote:
> >  > All,
> >  >
> >  > With SRv6 and IP based flex algo a generic question as it applies
> to
> >  > both. Is it possible to have within a single IGP domain different
> sets
> >  > of nodes or segments of the network running different
> algorithms.
> >
> >  absolutely.
> >
> >  > From
> >  > both drafts it sounds like all nodes have to agree on same
> algorithm
> >  > similar to concept of metric and reference bandwidth all have to
> have
> >  > the same style metric and play to the same sheet of music.
> >
> >  all participating nodes need to agree on the definition of the
> flex-algo
> >  and advertise the participation. That's it.
> >
> >  > If there was
> >  > a way to use multiple algorithms simultaneously based on SFC
> or services
> >  > and instantiation of specific algorithm based on service to be
> >  > rendered.  Doing so without causing a routing loop or sub
> optimal
> >  > routing.
> >
> >  you can certainly use multiple algorithms simultaneously and use
> algo
> >  specific paths to forward specific traffic over it. How that is 
> done
> >  from the forwarding perspective depends in which forwarding
> plane you
> >  use. Flex-algo control plane is 

Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

[Dongjie (Jimmy)]

Hi,

While it is possible to define algorithm-specific IP reachability TLVs to 
advertise IP Prefixes associated with different algorithms, this would 
introduce several new IS-IS top TLVs. One quick question is: can similar 
function be provided with extensions to existing IP reachability TLVs and MT IP 
reachability TLVs, instead of defining top TLVs for MT, Flex-Algo, and the 
combination of Flex-Algo and MT respectively?

And one nit in the encoding: the length of MT-ID in IS-IS should be 12 bits.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, September 30, 2020 3:28 PM
To: Huzhibo mailto:huzh...@huawei.com>>
Cc: lsr@ietf.org; Joel M. Halpern 
mailto:j...@joelhalpern.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

Hi,

> It uses the HBH option

Currently Ron's proposal seems to work well for both IPv4 and IPv6 addresses. I 
hope this discussion will not try to derail it to IPv6 only track.

I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.

I do however see some issues in deploying such technology as it will only work 
well if *all* nodes in the network support this new functionality. In contrast 
in SR world or control plane based TE I proposed or any encapsulation based 
proposal only anchor nodes need to support the new functionality while rest of 
the network does not need to be even aware about it.

Many thx,
R.


On Wed, Sep 30, 2020 at 6:10 AM Huzhibo 
mailto:huzh...@huawei.com>> wrote:
Hi Joel:

For details about the method defined in RFC 6550. It uses the HBH option to 
carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar.

Thanks

Zhibo

-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf 
Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt

I am missing something in this discussion of multiple algorithms.

My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you 
need to associated a forwarding label (e.g. MPLS label or IPv6
address) with a specific algorithm so that you can compute the next hope for 
the forwarding label using the proper algorithm.  Then when a packet arrives, 
it is simply forwarded according to the forwarding table (e.g.
FIB, LIB, ..)

If that is so, then I do not understand how a given prefix can be safely 
associated with more than one algorithm.  I could imagine doing several 
calculations according to different algorithms.  But how do you decide which 
one applies to the packet?  As far as I know, flex-algo does not look at the 
QoS/CoS/ToS bits.

Yours,
Joel

PS: I will admit that it took until  an operator described some "interesting" 
constraints before I understood why one would even do this.

On 9/29/2020 11:50 PM, Huzhibo wrote:
> Hi.
>
> Associating multiple algorithms with a given prefix is an interesting topic, 
> and I think this can simplify the complexity of FlexAlgo. I wonder if the 
> author would consider using cases with multiple algorithms with a given 
> prefix.
>
> Thanks
>
> ZHibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On 
> Behalf Of tony...@tony.li
> Sent: Tuesday, September 29, 2020 10:05 PM
> To: Ron Bonica 
> mailto:40juniper@dmarc.ietf.org>>
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
>
> Ron,
>
> This is nice. It makes it clear that constraint based path computation need 
> not have MPLS overhead for those that don’t want it.
>
> One thing that you don’t talk about is how this gets used, tho that may be 
> blindingly obvious: you’ll need all nodes placing their prefixes in the 
> RIB/FIB, where it will need to be selected over other path computation for 
> the same prefixes.  This somewhat precludes the possibility of a given prefix 
> being useful in multiple flex-algos.
>
> More text on application would be most welcome, just to ensure that we’re on 
> the same page.
>
> Tony
>
>
>> On Sep 29, 2020, at 6:37 AM, Ron Bonica 
>> mailto:40juniper@dmarc.ietf.org>> 
>> wrote:
>>
>>
>> Please review and comment
>>
>>Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org 
>>> mailto:internet-dra...@ietf.org>>
>>> Sent: Tuesday, September 29, 2020 9:36 AM
>>> To: Parag Kaneriya mailto:pkane...@juniper.net>>; 
>>> Shraddha Hegde
>>> mailto:shrad...@juniper.net>>; Ron Bonica 
>>> mailto:rbon...@juniper.net>>; Rajesh M
>>> mailto:mraj...@juniper.net>>; William Britto A J 
>>> mailto:bwill...@juniper.net>>
>>> Subject: New Version Notification for
>>> 

Re: [Lsr] 回复: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt

[Dongjie (Jimmy)]

Hi Peter,

Please see some replies inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Wednesday, September 16, 2020 6:18 PM
> To: Dongjie (Jimmy) ; zhu...@chinatelecom.cn;
> lsr@ietf.org
> Subject: Re: [Lsr] 回复: New Version Notification for
> draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> 
> Hi Jie,
> 
> On 16/09/2020 12:02, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for your comment. Please see some replies inline:
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Wednesday, September 16, 2020 4:46 PM
> >> To: zhu...@chinatelecom.cn; lsr@ietf.org
> >> Subject: Re: [Lsr] 回复: New Version Notification for
> >> draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> >>
> >> Yongqing,
> >>
> >> I have two basic comments:
> >>
> >> 1. Using L2 Bundle Member Attributes TLV for advertising attributes
> >> for VTNs seems like a hack.
> >
> > Yes, the combination of Flex-Algo and L2 bundle can provide the required
> functionality of VTN.
> 
> L2 Bundle Member Attributes TLV was defined to advertise L2 link bundle
> member data, not VTN data. I let others to comment, for me that is not the
> right way to encode VTN data.

Yes L2 bundle has its original usage, whether it can be extended for some 
broader case can be discussed in the WG. 

> 
> >
> >>
> >> 2.
> >>
> >> "In order to correlate the virtual or physical member links with the
> >>  corresponding VTNs, each member link SHOULD be assigned with a
> >>  dedicated Admin Group or Extended Admin Group, which is included
> in
> >>  the definition of the Flex-Algo of the corresponding VTN.  Note that
> >>  in this case the Admin Group or Extended Admin Group of the Layer
> 3
> >>  link SHOULD be set to the union of all the Admin Groups or Extended
> >>  Admin Groups of its virtual or physical member links.  This is to
> >>  ensure that the Layer 3 link is always included in the Flex-Algo
> >>  specific constraint path computation of the VTNs it participates in."
> >>
> >> Above proposal does not work. Here's the simple example:
> >>
> >> Flex-algo 128, FAD include RED
> >> Flex-algo 129, FAD exclude RED
> >>
> >> Now you have two VTNs, one for FA 128 (VT1) and one for 129 (VT2).
> >
> >> So your VT1 member link will have affinity RED and your VT2 will not
> >> have any affinity set (I presume).
> >
> > Maybe the text in draft is not clear enough. Take your example, it should 
> > be:
> >
> > Flex-Algo 128, FAD include RED
> > Flex-Algo 129, FAD include BLUE
> 
> you changed the exclude RED to include BLUE, but I had RED in both FAs, one
> include one exclude, that was a valid option with FAD.
> 
> If the VTN with FA means that FA can only be based on the single "affinity
> include' constraint per FA, please make that clear in the draft and state that
> other constraints MUST NOT be used for your solution to work.

Yes for VTN there needs to be some constraints about the affinity rules of FA, 
a simple case is to have dedicated affinity included for each FA, and the 
exclude rules in this case may not apply. This could be further clarified in 
next version.  

Best regards,
Jie

> >
> > On one L3 link (either a physical L2 bundle or not), the member link for
> VTN-1 will have affinity RED, the member link for VTN-2 will have affinity 
> BLUE,
> and the L3 link SHOULD be set with affinity RED and BLUE (i.e. the union of 
> its
> member links).
> >
> >> Your L3 will have affinity RED set based on your proposal. As a result the 
> >> L3
> link
> >> will be be excluded for FA 129, but that is not what you want, because your
> VTN2
> >> does not have affinity RED set.
> >
> > Based on the affinity of the L3 link (RED and BLUE), the L3 link will be 
> > used
> for path computation in both FA-128 and FA-129.
> >
> > Then in forwarding plane, a received packet with prefix-SID of FA-128 will 
> > be
> steered to use the member link for VTN-1, and a received packet with
> prefix-SID of FA-129 will be steered to use the member link for VTN-2. This is
> the expected behavior.
> >
> >>
> >> The fundamental problem is that FA works on L3 data only. You are trying to
> make
> >> it work for L2, but that is not going to work.
> >
> > The FA based path computation is still based on L3 link attribute, 

Re: [Lsr] 回复: New Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your comment. Please see some replies inline:

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, September 16, 2020 4:46 PM
> To: zhu...@chinatelecom.cn; lsr@ietf.org
> Subject: Re: [Lsr] 回复: New Version Notification for
> draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> 
> Yongqing,
> 
> I have two basic comments:
> 
> 1. Using L2 Bundle Member Attributes TLV for advertising attributes for VTNs
> seems like a hack.

Yes, the combination of Flex-Algo and L2 bundle can provide the required 
functionality of VTN.

>
> 2.
> 
>"In order to correlate the virtual or physical member links with the
> corresponding VTNs, each member link SHOULD be assigned with a
> dedicated Admin Group or Extended Admin Group, which is included in
> the definition of the Flex-Algo of the corresponding VTN.  Note that
> in this case the Admin Group or Extended Admin Group of the Layer 3
> link SHOULD be set to the union of all the Admin Groups or Extended
> Admin Groups of its virtual or physical member links.  This is to
> ensure that the Layer 3 link is always included in the Flex-Algo
> specific constraint path computation of the VTNs it participates in."
> 
> Above proposal does not work. Here's the simple example:
> 
> Flex-algo 128, FAD include RED
> Flex-algo 129, FAD exclude RED
> 
> Now you have two VTNs, one for FA 128 (VT1) and one for 129 (VT2).

> So your VT1 member link will have affinity RED and your VT2 will not have any
> affinity set (I presume).

Maybe the text in draft is not clear enough. Take your example, it should be:

Flex-Algo 128, FAD include RED
Flex-Algo 129, FAD include BLUE

On one L3 link (either a physical L2 bundle or not), the member link for VTN-1 
will have affinity RED, the member link for VTN-2 will have affinity BLUE, and 
the L3 link SHOULD be set with affinity RED and BLUE (i.e. the union of its 
member links).

> Your L3 will have affinity RED set based on your proposal. As a result the L3 
> link
> will be be excluded for FA 129, but that is not what you want, because your 
> VTN2
> does not have affinity RED set.

Based on the affinity of the L3 link (RED and BLUE), the L3 link will be used 
for path computation in both FA-128 and FA-129. 

Then in forwarding plane, a received packet with prefix-SID of FA-128 will be 
steered to use the member link for VTN-1, and a received packet with prefix-SID 
of FA-129 will be steered to use the member link for VTN-2. This is the 
expected behavior. 

> 
> The fundamental problem is that FA works on L3 data only. You are trying to 
> make
> it work for L2, but that is not going to work.

The FA based path computation is still based on L3 link attribute, the member 
link attribute is used to correlate a subset of link resource with a Flex-Algo, 
which can be used for forwarding packet which carries the FA-specific SIDs.

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> On 16/09/2020 08:13, zhu...@chinatelecom.cn wrote:
> > Hi WG,
> >
> > We just submitted a new revision of draft-zhu-lsr-isis-sr-vtn-flexalgo. This
> document specifies a mechanism to use Flex-Algo together with small extensions
> to IS-IS L2 bundle to distribute the topology and resource attribute of SR 
> based
> VTN. Your review and comments are appreciated.
> > B.R.
> > Zhu Yongqing
> >
> > -邮件原件-
> > 发件人: internet-dra...@ietf.org 
> > 发送时间: 2020年9月11日 17:11
> > 收件人: Dongjie (Jimmy) ; Yongqing Zhu
> > ; Huzhibo 
> > 主题: New Version Notification for
> > draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> >
> >
> > A new version of I-D, draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> > has been successfully submitted by Jie Dong and posted to the IETF 
> > repository.
> >
> > Name:   draft-zhu-lsr-isis-sr-vtn-flexalgo
> > Revision:   01
> > Title:  Using Flex-Algo for Segment Routing based VTN
> > Document date:  2020-09-11
> > Group:  Individual Submission
> > Pages:  8
> > URL:
> https://www.ietf.org/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo
> > Htmlized:
> https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-zhu-lsr-isis-sr-vtn-flexalgo-01
> >
> > Abstract:
> > As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to
> > provide enhanced VPN service to support the needs of enhanced
> >  

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Dongjie (Jimmy)]

I support the adoption of this document.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Les,

Please see my reply inline:

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Tuesday, March 31, 2020 12:17 AM
To: Dongjie (Jimmy) ; Peter Psenak 
; xie...@chinatelecom.cn; lsr 
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Jie -

Inline.

> -Original Message-
> From: Dongjie (Jimmy) 
> Sent: Monday, March 30, 2020 3:04 AM
> To: Les Ginsberg (ginsberg) ; Peter Psenak 
> ; xie...@chinatelecom.cn; lsr 
> 
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Hi Les,
> 
> Thanks for your review and comments.
> 
> Please see my replies inline with [Jie]:
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Monday, March 30, 2020 3:06 PM
> To: Dongjie (Jimmy) ; Peter Psenak 
> ; xie...@chinatelecom.cn; lsr 
> 
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Jie -
> 
> The format of the TE-attribute sub-TLVs is defined and does not change 
> based upon the TLV in which it is advertised. So I do not see that any 
> additional specification is required.
> 
> [Jie] I agree that the format of the TLVs could be reused. While some 
> explanation about the meaning of topology-specific attributes may need 
> to be added.
> 
> [Jie] For example, if one 10G link participates in 3 topologies, how 
> should the per-topology max-link-bandwidth be advertised? One option 
> is to advertise 10G for each topology, another option is to advertise 
> 2G, 3G, 5G for the three topologies respectively. Both options may be 
> allowed depending on the use cases. The consideration for other TE 
> attributes may be similar or different.
> 
[Les:] Well, this has nothing to do with the encoding. This has to do with use 
case - which is what you are defining.
So this is actually your responsibility to specify since you are proposing to 
advertise topology specific link attributes.

[Jie] I agree that the encoding could be reused, it seems you also agree that 
the usage of existing TLVs for topology-specific link attributes in specific 
use case needs to be specified.

Note that max-link bandwidth is actually one of the easier attributes to share.

[Jie] Yes, thus IMO the usage of TE attributes in MT related scenarios may need 
to be specified case by case.

Best regards,
Jie






   Les

> In rereading draft-dong-lsr-sr-enhanced-vpn, I am wondering what is 
> the scope you desire for link attributes?
> 
> You have defined that a given "L2 virtual link" can be associated with:
> 
> a)Multiple topologies
> b)Multiple VTNs
> c)Each VTN can be associated with a different Flex-algorithm
> 
> Is the scope of the link attribute advertisement per topology?
> Or per topology+(set of) VTNs?
> 
> [Jie] In draft-dong-lsr-sr-enhanced-vpn, as it introduces the VTN-ID 
> TLV, each
> "L2 virtual link" is associated with one or multiple VTNs using the 
> VTN-ID TLV, and MT-ID is not used for the virtual member link association.
> 
> In other words, it is clear that you want to advertise different link 
> attributes for the same link in different MTIDs.
> 
> [Jie] This is one of the objectives of draft-xie-lsr-sr-vtn-mt.
> 
> But do you also want to advertise different link attributes for the 
> same link/MTID in different VTNs?
> 
> [Jie] This is something we want to achieve with 
> draft-dong-lsr-sr-enhanced- vpn.
> 
> Best regards,
> Jie
> 
> 
>Les
> 
> > -Original Message-
> > From: Dongjie (Jimmy) 
> > Sent: Sunday, March 29, 2020 9:57 PM
> > To: Les Ginsberg (ginsberg) ; Peter Psenak 
> > ; xie...@chinatelecom.cn; lsr 
> > 
> > Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
> > Routing based Virtual Transport Network
> >
> > Hi Les,
> >
> > Many thanks for providing the history about this IANA registry. The 
> > approach in RFC 7370 is reasonable, while in general it would be 
> > more useful if a reference is also provided for each column, so as 
> > to indicate in which document the allowed combination of the 
> > sub-TLVs and each TLV is specified. As some sub-TLVs may be defined 
> > earlier than a relatively new TLV, the reference to a sub-TLV does 
> > not really cover their
> combination.
> >
> > I agree that the registry shows the TE attribute sub-TLVs are 
> > allowed in MT- ISN TLV 222, this is good. Then the question left is: 
> > is there a need to specify how to advertise topology-specific TE 
> > attributes, especially when one link participat

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

[Dongjie (Jimmy)]

Hi Robert,

Good question. In short you may need some mechanism in the forwarding plane to 
isolate the traffic in the default topology from the traffic in other 
topologies. Some of the candidate technologies are described in 
draft-ietf-teas-enhanced-vpn.

Best regards,
Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, March 30, 2020 6:21 PM
To: Dongjie (Jimmy) 
Cc: peng.sha...@zte.com.cn; Aijun Wang ; 
xie...@chinatelecom.cn; lsr@ietf.org
Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
basedVirtual Transport Network

Hi,

Out of pure curiosity here - how are you going to stop any other traffic (SR or 
non SR) to take as much as it likes of any link being part of the default 
topology ?

Thx,
R.

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

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Les,

Thanks for your review and comments.

Please see my replies inline with [Jie]:

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Monday, March 30, 2020 3:06 PM
To: Dongjie (Jimmy) ; Peter Psenak 
; xie...@chinatelecom.cn; lsr 
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Jie -

The format of the TE-attribute sub-TLVs is defined and does not change based 
upon the TLV in which it is advertised. So I do not see that any additional 
specification is required.

[Jie] I agree that the format of the TLVs could be reused. While some 
explanation about the meaning of topology-specific attributes may need to be 
added. 

[Jie] For example, if one 10G link participates in 3 topologies, how should the 
per-topology max-link-bandwidth be advertised? One option is to advertise 10G 
for each topology, another option is to advertise 2G, 3G, 5G for the three 
topologies respectively. Both options may be allowed depending on the use 
cases. The consideration for other TE attributes may be similar or different.

In rereading draft-dong-lsr-sr-enhanced-vpn, I am wondering what is the scope 
you desire for link attributes?

You have defined that a given "L2 virtual link" can be associated with:

a)Multiple topologies
b)Multiple VTNs
c)Each VTN can be associated with a different Flex-algorithm

Is the scope of the link attribute advertisement per topology?
Or per topology+(set of) VTNs?

[Jie] In draft-dong-lsr-sr-enhanced-vpn, as it introduces the VTN-ID TLV, each 
"L2 virtual link" is associated with one or multiple VTNs using the VTN-ID TLV, 
and MT-ID is not used for the virtual member link association.

In other words, it is clear that you want to advertise different link 
attributes for the same link in different MTIDs.

[Jie] This is one of the objectives of draft-xie-lsr-sr-vtn-mt.

But do you also want to advertise different link attributes for the same 
link/MTID in different VTNs?

[Jie] This is something we want to achieve with draft-dong-lsr-sr-enhanced-vpn.

Best regards,
Jie


   Les

> -Original Message-
> From: Dongjie (Jimmy) 
> Sent: Sunday, March 29, 2020 9:57 PM
> To: Les Ginsberg (ginsberg) ; Peter Psenak 
> ; xie...@chinatelecom.cn; lsr 
> 
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Hi Les,
> 
> Many thanks for providing the history about this IANA registry. The 
> approach in RFC 7370 is reasonable, while in general it would be more 
> useful if a reference is also provided for each column, so as to 
> indicate in which document the allowed combination of the sub-TLVs and 
> each TLV is specified. As some sub-TLVs may be defined earlier than a 
> relatively new TLV, the reference to a sub-TLV does not really cover their 
> combination.
> 
> I agree that the registry shows the TE attribute sub-TLVs are allowed 
> in MT- ISN TLV 222, this is good. Then the question left is: is there 
> a need to specify how to advertise topology-specific TE attributes, 
> especially when one link participates in multiple topologies? AFAIK 
> this is not described in RFC 5120, nor RFC 5305.
> 
> Best regards,
> Jie
> 
> 
> -Original Message-
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Saturday, March 28, 2020 1:12 AM
> To: Peter Psenak ; Dongjie (Jimmy) 
> ; xie...@chinatelecom.cn; lsr 
> Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Jie -
> 
> The registry clearly indicates the set of specifications - and does so 
> on a per sub-TLV basis - though not on a per column basis.
> The registry is authoritative.
> 
> There is a bit of history here.
> 
> Prior to RFC7370 there wasn't a single registry for all the related 
> TLVs. This became awkward to maintain, so RFC7370 combined the per TLV 
> registries into a single registry for the set of Neighbor/Link related 
> TLVs (22, 23, 25, 141, 222, and 223)) and similarly for the set of 
> Prefix related TLVs (135, 235, 236, and 237).
> It was because of RFC 7370 that the columns were introduced.
> 
> Now, are you claiming the registry is incorrect? If so, please explain why.
> Otherwise, it seems to me that you are simply making trouble for yourself.
> Clearly the registry allows TE attribute sub-TLVs to be encoded in MT 
> TLVs - and the text in RFC 5120 supports that. Whether there is a real 
> deployment case for that is another matter.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Peter Psenak
> > Sent: Friday, March 27, 2020 8:45 AM
> > To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; 
> > lsr 
> > Subject: Re: [Lsr] Usin

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Les, 

Many thanks for providing the history about this IANA registry. The approach in 
RFC 7370 is reasonable, while in general it would be more useful if a reference 
is also provided for each column, so as to indicate in which document the 
allowed combination of the sub-TLVs and each TLV is specified. As some sub-TLVs 
may be defined earlier than a relatively new TLV, the reference to a sub-TLV 
does not really cover their combination.

I agree that the registry shows the TE attribute sub-TLVs are allowed in MT-ISN 
TLV 222, this is good. Then the question left is: is there a need to specify 
how to advertise topology-specific TE attributes, especially when one link 
participates in multiple topologies? AFAIK this is not described in RFC 5120, 
nor RFC 5305. 

Best regards,
Jie


-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Saturday, March 28, 2020 1:12 AM
To: Peter Psenak ; Dongjie (Jimmy) 
; xie...@chinatelecom.cn; lsr 
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Jie -

The registry clearly indicates the set of specifications - and does so on a per 
sub-TLV basis - though not on a per column basis.
The registry is authoritative.

There is a bit of history here.

Prior to RFC7370 there wasn't a single registry for all the related TLVs. This 
became awkward to maintain, so RFC7370 combined the per TLV registries into a 
single registry for the set of Neighbor/Link related TLVs (22, 23, 25, 141, 
222, and 223)) and similarly for the set of Prefix related TLVs (135, 235, 236, 
and 237).
It was because of RFC 7370 that the columns were introduced.

Now, are you claiming the registry is incorrect? If so, please explain why.
Otherwise, it seems to me that you are simply making trouble for yourself. 
Clearly the registry allows TE attribute sub-TLVs to be encoded in MT TLVs - 
and the text in RFC 5120 supports that. Whether there is a real deployment case 
for that is another matter.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Friday, March 27, 2020 8:45 AM
> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr 
> 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Hi Dongjie,
> 
> On 27/03/2020 16:32, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > My question actually is: where does the TLV 222 column in the IANA
> registry come from? As it is not specified in the IANA section of RFC 
> 5120. It would be helpful if you or anyone else could share some more 
> information about this. If normative specification of using TE 
> attributes in TLV 222 could be found in an RFC, we would add a 
> reference to it and remove the editor's note in section 3.1 of this document.
> 
> I guess it came with RFC 5120.
> 
> please see more inline:
> 
> 
> >
> > And please see some further replies inline about the L2 bundle discussion.
> >
> > -Original Message-
> > From: Peter Psenak [mailto:ppse...@cisco.com]
> > Sent: Friday, March 27, 2020 4:11 PM
> > To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; 
> > lsr
> 
> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
> > Routing
> based Virtual Transport Network
> >
> > Hi Dongjie,
> >
> > On 27/03/2020 07:56, Dongjie (Jimmy) wrote:
> >> Hi Peter,
> >>
> >> You missed some of my comments in previous mail, could you also 
> >> reply
> to this?
> >>
> >>> Although the IANA registry shows that all the TE attributes could 
> >>> be used
> in TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm 
> aware of), could you help to provide the reference to such IANA 
> specification? In addition, it seems not all of the TE attributes are 
> suitable to be carried at per- topology level. Thus the IANA registry may 
> need to be updated.
> >
> > my reading of RFC 5120 and the existing IANA registry is that it is 
> > legal to
> advertise TE attributes in MT TLVs:
> >
> > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-
> codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223
> >
> > It says "y" for all TE attributes. What else do you need?
> >
> >>
> >> And please see further replies inline with [Jie]:
> >>
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, March 26, 2020 7:03 PM
> >> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn;
> lsr
> >> 
> >> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
> >> Routing based Virtual Transport Network
> >>
>

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply, please see inline with [Jie 3]:

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, March 27, 2020 11:45 PM
To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr 

Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

On 27/03/2020 16:32, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
> My question actually is: where does the TLV 222 column in the IANA registry 
> come from? As it is not specified in the IANA section of RFC 5120. It would 
> be helpful if you or anyone else could share some more information about 
> this. If normative specification of using TE attributes in TLV 222 could be 
> found in an RFC, we would add a reference to it and remove the editor's note 
> in section 3.1 of this document.

I guess it came with RFC 5120.

[Jie 3]: Thanks, I saw Les provides some background about this. I will reply to 
his mail about this part.

Some previous discussion are trimmed off...


>> [Jie] In this case, the L3 link is associated with the union of the MT-IDs 
>> associated with its L2 member links.
>>
>> For example, if a L3 link has three L2 member links, which are associated 
>> with MT-x, MT-y and MT-z respectively, then the L3 link is associated with 
>> MT-x, MT-y and MT-z.
> 
> I'm going to repeat myself here. You are misusing the MT-ID for something you 
> have defined. I don't think it is correct. L2  bundle link is NOT a 
> topological entity in ISIS, only the L3 link is. Associating L2 bundle link 
> with a MT is conceptually wrong.
> 
> If you wanted different bundle members to be part of different topologies the 
> obvious solution would be to enable L3 directly on the individual links 
> rather than combine them into one L3 Bundle interface.
> 
> [Jie2] I agree the usage of MT-ID is extended in this case. But if an L3 
> parent link participates in multiple topologies, this could help to further 
> identify the member link which is only used for traffic belonging to a 
> specific topology. A similar attribute is the admin-group.

no, I don't agree. You can only associate MT-ID with a L3 link, not with
L2 link.

[Jie 3]: The MT-IDs are still associated with the L3 link, the purpose here is 
to further associate each topology with a subset of resource of the L3 link. 
IGP L2bundle is something near to what we need, the bundle member link could be 
used to represent a subset of the resource of the L3 link. This may require 
some extension or generalization to L2bundle, which is described in 
draft-dong-lsr-sr-enhanced-vpn-03 and draft-zhu-lsr-sr-vtn-flexalgo.

 
> [Jie2] Enabling L3 on each individual link is another option, while it 
> introduces the overhead which the L2 bundle mechanism tries to avoid.

well, if you want to use L3 constructs like MT-ID, it comes with an overhead. I 
have expressed my concerns of the MT being used for what you are trying to use 
it for in the past - and overhead was the main issue.

[Jie 3]: Since multiple topologies can be enabled on the same L3 link, it is 
possible to reduce the overhead of multiple L3 connections. Following this, 
what we need IMO is to find a suitable approach to advertise topology-specific 
TE attributes for such a link.

Best regards,
Jie


thanks,
Peter

> 
> [Jie2] BTW, in the IANA section of the L2 bundle RFC 8668, it clearly 
> specifies which existing sub-TLVs are allowed in the newly defined TLV 25, 
> and in which existing TLVs the new sub-TLVs can be carried. Something similar 
> documented in an RFC for TLV 222 would be good enough to solve my question in 
> the beginning of this mail.
> 
> Best regards,
> Jie
> 

>>>>>
>>>>>> -Original Message-
>>>>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>>>>> Sent: Wednesday, March 25, 2020 10:09 PM
>>>>>> To: xie...@chinatelecom.cn; lsr 
>>>>>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
>>>>>> Routing based Virtual Transport Network
>>>>>>
>>>>>> Hi Chongfeng,
>>>>>>
>>>>>> what exactly is being standardized in this draft? I don't see anything.
>>>>>>
>>>>>> thanks,
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
>>>>>>>
>>>>>>> Hello, folks,
>>>>>>>
>>>>>>> we have submitted a new draft of
>>>>>>>   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
>>>>>>>
>>>>>>> It is about Using IS-IS Mu

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter,

My question actually is: where does the TLV 222 column in the IANA registry 
come from? As it is not specified in the IANA section of RFC 5120. It would be 
helpful if you or anyone else could share some more information about this. If 
normative specification of using TE attributes in TLV 222 could be found in an 
RFC, we would add a reference to it and remove the editor's note in section 3.1 
of this document.

And please see some further replies inline about the L2 bundle discussion.

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, March 27, 2020 4:11 PM
To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr 

Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Hi Dongjie,

On 27/03/2020 07:56, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
> You missed some of my comments in previous mail, could you also reply to this?
> 
>> Although the IANA registry shows that all the TE attributes could be used in 
>> TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware 
>> of), could you help to provide the reference to such IANA specification? In 
>> addition, it seems not all of the TE attributes are suitable to be carried 
>> at per-topology level. Thus the IANA registry may need to be updated.

my reading of RFC 5120 and the existing IANA registry is that it is legal to 
advertise TE attributes in MT TLVs:

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

It says "y" for all TE attributes. What else do you need?

> 
> And please see further replies inline with [Jie]:
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 26, 2020 7:03 PM
> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr 
> 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Hi Dongjie,
> 
> On 26/03/2020 11:57, Dongjie (Jimmy) wrote:
>> Hi Peter,
>>
>> Thanks for your comments.
>>
>>> -Original Message-
>>> From: Peter Psenak [mailto:ppse...@cisco.com]
>>> Sent: Thursday, March 26, 2020 5:23 PM
>>> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; 
>>> lsr 
>>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
>>> Routing based Virtual Transport Network
>>>
>>> Hi Dongjie,
>>>
>>> On 26/03/2020 07:40, Dongjie (Jimmy) wrote:
>>>> Hi Peter,
>>>>
>>>> As described in the abstract, the purpose of this draft is to 
>>>> define a simplified
>>> control plane mechanism to build SR based Virtual Transport Network 
>>> (VTN), it is based on the combination of IS-IS Multi-Topology with 
>>> other IS-IS extensions, e.g. the extensions for TE, SR and L2 bundle.
>>> In a word, it tries to reuse the existing TLVs as much as possible.
>>>
>>> reusing the TLVs is not something that needs a standardization.
>>>
>>>>
>>>> That said, this document introduces the mechanism of specifying
>>> per-topology TE attributes, which was not covered in the existing 
>>> IS-IS MT (RFC 5120).
>>>
>>> I can clearly see that TLVs defined in RFC5120 are listed in the 
>>> registry of sub-TLVs available for TLV 222/223
>>>
>>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo
>>> i
>>> nts.xhtm
>>> l#isis-tlv-codepoints-22-23-25-141-222-223
>>>
>>> So I'm not sure what you are adding.
>>
>> In RFC 5120 section 7, it says that
>>
>> “If traffic engineering or some other applications are being applied per 
>> topology level later, the new TLVs can automatically inherit the same 
>> attributes already defined for the "standard" topology without going through 
>> long standard process to redefine them per topology.”
>>
>> This indicates that per-topology TE attributes is not a feature specified in 
>> RFC5120, although the TLVs can be reused.
> 
> the text above clearly says there is no standardization required.
> 
> [Jie] My reading of the above text is that RFC 5120 leaves the specification 
> of per-topology TE or other applications to a later document. And it is also 
> related to my below comment which you missed.

my reading is different.

> 
>> Although the IANA registry shows that all the TE attributes could be used in 
>> TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware 
>> of), could you help to provide the reference to such IANA specification? In 

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Les, 

Thanks for your comments. 

Although this draft reuses existing TLVs, we found that some usage may not be 
fully specified in existing RFCs. Please see my recent reply to Peter about the 
per-topology TE attributes, and the use of MT-ID in L2 bundle. Currently my 
preference is standard track, while it is open for discussion with the WG.

I agree this draft is relevant to draft-dong-lsr-sr-enhanced-vpn, and their 
relationship is described in the abstract of this document:

"I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a set of 
Segment Routing (SR) based VTNs.  This document describes a simplified 
mechanism to build the SR based VTNs using IGP multi- topology together with 
other well-defined IS-IS extensions."

As this draft itself describes a stand-alone solution, maybe it is more 
appropriate to keep it as a separate document.

Bet regards,
Jie

-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Friday, March 27, 2020 12:05 AM
To: Dongjie (Jimmy) ; Peter Psenak 
; xie...@chinatelecom.cn; lsr 
Subject: RE: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Trying to avoid piling on...but Peter is certainly correct that there is 
nothing in this draft that is normative.

This may provide useful context for the protocol extensions defined in 
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/. As such the 
content would be better incorporated into that draft.
Whether the WG decides to take on enhanced VPN or not is still TBD, but there 
is no reason I can see for this draft to exist independently.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Dongjie (Jimmy)
> Sent: Wednesday, March 25, 2020 11:41 PM
> To: Peter Psenak ;
> xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing 
> based Virtual Transport Network
> 
> Hi Peter,
> 
> As described in the abstract, the purpose of this draft is to define a 
> simplified control plane mechanism to build SR based Virtual Transport 
> Network (VTN), it is based on the combination of IS-IS Multi-Topology 
> with other IS-IS extensions, e.g. the extensions for TE, SR and L2 
> bundle. In a word, it tries to reuse the existing TLVs as much as possible.
> 
> That said, this document introduces the mechanism of specifying per- 
> topology TE attributes, which was not covered in the existing IS-IS MT 
> (RFC 5120). Similarly, it also introduces the mechanism of associating 
> MT-IDs with a particular member link of L2 bundle, which was not 
> defined in IS-IS L2 Bundle (RFC 8668).
> 
> Thus we think it is appropriate to be standard track.
> 
> Best regards,
> Jie
> 
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> > Sent: Wednesday, March 25, 2020 10:09 PM
> > To: xie...@chinatelecom.cn; lsr 
> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
> > Routing
> based
> > Virtual Transport Network
> >
> > Hi Chongfeng,
> >
> > what exactly is being standardized in this draft? I don't see anything.
> >
> > thanks,
> > Peter
> >
> >
> > On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> > >
> > > Hello, folks,
> > >
> > > we have submitted a new draft of
> > >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> > >
> > > It is about Using IS-IS Multi-Topology (MT) for Segment Routing 
> > > based Virtual Transport Network. Enhanced VPN (VPN+) as defined in 
> > > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to 
> > > support some applications's needs of enhanced isolation and 
> > > stringent performance requirements.  VPN+ requries integration 
> > > between the overlay VPN and the underlay network.  A Virtual 
> > > Transport Network
> > > (VTN) is a virtual network which consists of a subset of the 
> > > network toplogy and network resources allocated from the underlay 
> > > network.  A VTN could be used as the underlay for one or a group of VPN+ 
> > > services.
> > > This document describes a simplified mechanism to build the SR 
> > > based VTNs using IGP
> > > multi- topology together with other well-defined IS-IS extensions.
> > >
> > > Comments and suggestions are highly appreciated.
> > >
> > > Chongfeng Xie
> > >
> > >
> >
> > ___
> > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

You missed some of my comments in previous mail, could you also reply to this?

> Although the IANA registry shows that all the TE attributes could be used in 
> TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware of), 
> could you help to provide the reference to such IANA specification? In 
> addition, it seems not all of the TE attributes are suitable to be carried at 
> per-topology level. Thus the IANA registry may need to be updated.

And please see further replies inline with [Jie]:

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Thursday, March 26, 2020 7:03 PM
To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr 

Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based 
Virtual Transport Network

Hi Dongjie,

On 26/03/2020 11:57, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
> Thanks for your comments.
> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Thursday, March 26, 2020 5:23 PM
>> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; 
>> lsr 
>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment 
>> Routing based Virtual Transport Network
>>
>> Hi Dongjie,
>>
>> On 26/03/2020 07:40, Dongjie (Jimmy) wrote:
>>> Hi Peter,
>>>
>>> As described in the abstract, the purpose of this draft is to define 
>>> a simplified
>> control plane mechanism to build SR based Virtual Transport Network 
>> (VTN), it is based on the combination of IS-IS Multi-Topology with 
>> other IS-IS extensions, e.g. the extensions for TE, SR and L2 bundle. 
>> In a word, it tries to reuse the existing TLVs as much as possible.
>>
>> reusing the TLVs is not something that needs a standardization.
>>
>>>
>>> That said, this document introduces the mechanism of specifying
>> per-topology TE attributes, which was not covered in the existing 
>> IS-IS MT (RFC 5120).
>>
>> I can clearly see that TLVs defined in RFC5120 are listed in the 
>> registry of sub-TLVs available for TLV 222/223
>>
>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoi
>> nts.xhtm
>> l#isis-tlv-codepoints-22-23-25-141-222-223
>>
>> So I'm not sure what you are adding.
> 
> In RFC 5120 section 7, it says that
> 
> “If traffic engineering or some other applications are being applied per 
> topology level later, the new TLVs can automatically inherit the same 
> attributes already defined for the "standard" topology without going through 
> long standard process to redefine them per topology.”
> 
> This indicates that per-topology TE attributes is not a feature specified in 
> RFC5120, although the TLVs can be reused.

the text above clearly says there is no standardization required.

[Jie] My reading of the above text is that RFC 5120 leaves the specification of 
per-topology TE or other applications to a later document. And it is also 
related to my below comment which you missed.

> Although the IANA registry shows that all the TE attributes could be used in 
> TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware of), 
> could you help to provide the reference to such IANA specification? In 
> addition, it seems not all of the TE attributes are suitable to be carried at 
> per-topology level. Thus the IANA registry may need to be updated.

[Jie] Maybe you could provide some information about the history of this IANA 
registry? It assumes all the TE attributes can be applied to both TLV 22 and 
TLV 222, which may not always be the case.

>>> Similarly, it also introduces the mechanism of associating MT-IDs 
>>> with a
>> particular member link of L2 bundle, which was not defined in IS-IS 
>> L2 Bundle (RFC 8668).
>>
>> carrying MT-ID in the L2 Bundle TLV is conceptually wrong.
>>
>> It is the parent L3 link which has the association with the 
>> particular topology ID, you can not change the topology per L2 link member.
>>
>> You are trying to overload the MT-ID with the VTN semantics, but you 
>> can not do it here. If you need a VTN ID for the L2 member link, 
>> which I'm not sure why, you need to define a a new attribute and not mix it 
>> with MT-ID.
> 
> In this document we try to reuse the existing IDs and TLVs to fulfil the 
> functionality required. Since several existing TLVs defined for L3 link have 
> been introduced for the L2 bundle member, we are considering the possibility 
> of also carrying MT-ID as another attribute of the member link. Could you 
> elaborate why it cannot be reused? Of course defining a new VTN-ID is another 
> option. We are open to discussion about 

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your comments.

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, March 26, 2020 5:23 PM
> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr
> 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> Hi Dongjie,
> 
> On 26/03/2020 07:40, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > As described in the abstract, the purpose of this draft is to define a 
> > simplified
> control plane mechanism to build SR based Virtual Transport Network (VTN), it
> is based on the combination of IS-IS Multi-Topology with other IS-IS 
> extensions,
> e.g. the extensions for TE, SR and L2 bundle. In a word, it tries to reuse the
> existing TLVs as much as possible.
> 
> reusing the TLVs is not something that needs a standardization.
> 
> >
> > That said, this document introduces the mechanism of specifying
> per-topology TE attributes, which was not covered in the existing IS-IS MT 
> (RFC
> 5120).
> 
> I can clearly see that TLVs defined in RFC5120 are listed in the registry of
> sub-TLVs available for TLV 222/223
> 
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtm
> l#isis-tlv-codepoints-22-23-25-141-222-223
> 
> So I'm not sure what you are adding.

In RFC 5120 section 7, it says that 

“If traffic engineering or some other applications are being applied per 
topology level later, the new TLVs can automatically inherit the same 
attributes already defined for the "standard" topology without going through 
long standard process to redefine them per topology.”

This indicates that per-topology TE attributes is not a feature specified in 
RFC5120, although the TLVs can be reused.

Although the IANA registry shows that all the TE attributes could be used in 
TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware of), 
could you help to provide the reference to such IANA specification? In 
addition, it seems not all of the TE attributes are suitable to be carried at 
per-topology level. Thus the IANA registry may need to be updated.

> >Similarly, it also introduces the mechanism of associating MT-IDs with a
> particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle
> (RFC 8668).
> 
> carrying MT-ID in the L2 Bundle TLV is conceptually wrong.
> 
> It is the parent L3 link which has the association with the particular 
> topology
> ID, you can not change the topology per L2 link member.
> 
> You are trying to overload the MT-ID with the VTN semantics, but you can not
> do it here. If you need a VTN ID for the L2 member link, which I'm not sure
> why, you need to define a a new attribute and not mix it with MT-ID.

In this document we try to reuse the existing IDs and TLVs to fulfil the 
functionality required. Since several existing TLVs defined for L3 link have 
been introduced for the L2 bundle member, we are considering the possibility of 
also carrying MT-ID as another attribute of the member link. Could you 
elaborate why it cannot be reused? Of course defining a new VTN-ID is another 
option. We are open to discussion about this.

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> >
> > Thus we think it is appropriate to be standard track.
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Wednesday, March 25, 2020 10:09 PM
> >> To: xie...@chinatelecom.cn; lsr 
> >> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment
> >> Routing based Virtual Transport Network
> >>
> >> Hi Chongfeng,
> >>
> >> what exactly is being standardized in this draft? I don't see anything.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >> On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> >>>
> >>> Hello, folks,
> >>>
> >>> we have submitted a new draft of
> >>>    https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> >>>
> >>> It is about Using IS-IS Multi-Topology (MT) for Segment Routing
> >>> based Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> >>> I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> >>> support some applications's needs of enhanced isolation and
> >>> stringent performance requirements.  VPN+ requries integration
> >>> between the overlay VPN and the underlay network.  A Virtual
> >>> Transport Network
> >>> (VTN) is a virtual network which consists of a subset of

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network

[Dongjie (Jimmy)]

Hi Peter, 

As described in the abstract, the purpose of this draft is to define a 
simplified control plane mechanism to build SR based Virtual Transport Network 
(VTN), it is based on the combination of IS-IS Multi-Topology with other IS-IS 
extensions, e.g. the extensions for TE, SR and L2 bundle. In a word, it tries 
to reuse the existing TLVs as much as possible.

That said, this document introduces the mechanism of specifying per-topology TE 
attributes, which was not covered in the existing IS-IS MT (RFC 5120). 
Similarly, it also introduces the mechanism of associating MT-IDs with a 
particular member link of L2 bundle, which was not defined in IS-IS L2 Bundle 
(RFC 8668).

Thus we think it is appropriate to be standard track.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, March 25, 2020 10:09 PM
> To: xie...@chinatelecom.cn; lsr 
> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based
> Virtual Transport Network
> 
> Hi Chongfeng,
> 
> what exactly is being standardized in this draft? I don't see anything.
> 
> thanks,
> Peter
> 
> 
> On 25/03/2020 14:44, xie...@chinatelecom.cn wrote:
> >
> > Hello, folks,
> >
> > we have submitted a new draft of
> >   https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-00 .
> >
> > It is about Using IS-IS Multi-Topology (MT) for Segment Routing based
> > Virtual Transport Network. Enhanced VPN (VPN+) as defined in
> > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to
> > support some applications's needs of enhanced isolation and stringent
> > performance requirements.  VPN+ requries integration between the
> > overlay VPN and the underlay network.  A Virtual Transport Network
> > (VTN) is a virtual network which consists of a subset of the network
> > toplogy and network resources allocated from the underlay network.  A
> > VTN could be used as the underlay for one or a group of VPN+ services.
> > This document describes a simplified mechanism to build the SR based
> > VTNs using IGP
> > multi- topology together with other well-defined IS-IS extensions.
> >
> > Comments and suggestions are highly appreciated.
> >
> > Chongfeng Xie
> >
> >
> 
> ___
> 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 draft-ietf-lsr-isis-srv6-extensions

[Dongjie (Jimmy)]

I support progressing this draft.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> Sent: Wednesday, January 22, 2020 8:15 AM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Acee Lindem
> (acee) 
> Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
> 
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for
> draft-ietf-lsr-isis-srv6-extensions
> 
>   https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> Authors please indicate if you aware of any other IPR beyond what is posted:
> 
>   https://datatracker.ietf.org/ipr/3796/
> 
> Thanks,
> Chris & Acee.
> ___
> 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 Call for draft-li-lsr-ospfv3-srv6-extensions

[Dongjie (Jimmy)]

Hi Peter, 

Thanks for your reply. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Monday, February 3, 2020 5:08 PM
> To: Dongjie (Jimmy) ; Acee Lindem (acee)
> ; Ketan Talaulikar (ketant) ;
> li_zhenqi...@hotmail.com; Christian Hopps ; lsr
> 
> Cc: lsr-ads ; draft-li-lsr-ospfv3-srv6-extensions
> 
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
> Hi Jie,
> 
> please see inline:
> 
> 
> On 01/02/2020 13:53, Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Please see some comments inline:
> >
> >> -Original Message-
> >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> >> Sent: Friday, January 31, 2020 1:24 AM
> >> To: Acee Lindem (acee) ; Ketan Talaulikar (ketant)
> >> ; li_zhenqi...@hotmail.com; Christian Hopps
> >> ; lsr 
> >> Cc: lsr-ads ; draft-li-lsr-ospfv3-srv6-extensions
> >> 
> >> Subject: Re: [Lsr] WG Adoption Call for
> >> draft-li-lsr-ospfv3-srv6-extensions
> >>
> >> Hi Acee,
> >>
> >> On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> >>> Hi Peter,
> >>>
> >>> On 1/30/20, 11:36 AM, "Peter Psenak"  wrote:
> >>>
> >>>   Hi Acee,
> >>>
> >>>   On 30/01/2020 17:11, Acee Lindem (acee) wrote:
> >>>   > Hi Ketan,
> >>>   >
> >>>   > In that case, it doesn’t make sense to include it in the End.X
> >>>   > advertisement since you need to look it up to check it
> >>> anyway. I
> >> don’t
> >>>   > see any benefit here.
> >>>   The benefit is to make sure that the END.X SID that was configured
> for
> >>>   the algo X is covered by the locator that has the same algo.
> >>>
> >>>   If you do not advertise the algo with END.X SID, you have no way
> of
> >>>   checking that on rcv side.
> >>>
> >>> Ok - so it is to verify that algorithm for the adjacency matches
> >>> that algorithm
> >> for the longest match locator - which may be advertised by a
> >> >different
> >> OSPFv3 router. Correct?
> >>
> >> yes.
> >
> > In what scenarios will the longest match locator of the END.X SID be
> advertised by a different router? Does this only happen due to bug or
> misconfiguration?
> 
> it's not the different OSPFv3 router, it's a different LSA/LSP.

This sounds more reasonable. But the above case mentioned by Acee is also 
possible, one example is during locator reconfiguration as you mentioned below. 

> >
> >>
> >>
> >>> I guess I don't see why the algorithm for the END.X SID just isn't
> >>> defined as
> >> the algorithm from the longest match locator. That way, everyone in
> >> >the area would use the same one and there would be less that could
> >> go wrong. What am I missing?
> >>
> >> locators may change over time. During the reconfiguration a END.X SID
> >> may wrongly be associated with the incorrect locator from a different algo.
> >
> > In this case just checking the algorithm may not be enough, if the algorithm
> happens to be the same, will the END.X SID be considered valid and be used by
> transit nodes to route towards the originator of the incorrect locator? Some
> mechanism needs to be considered to avoid using invalid END.X SIDs in such
> case.
> 
> if the algo is the same, then the locator is correct. What else do you want to
> check?

During the reconfiguration of a locator on one node, is it possible that the 
longest match locator of the END.X SID is from another node? And the algorithm 
may happen to be the same. In this case it is necessary to add that the END.X 
SID is considered invalid if its longest match locator is not from the 
originating router of this SID. After checking the draft I think this is 
already covered in the last paragraph of section 8, so it should be OK. 

BTW, I support the adoption of this document. 

Best regards,
Jie

> 
> thanks,
> Peter
> 
> 
> >
> > Best regards,
> > Jie
> >
> >> Also if for some reason the right locator is not advertised (due to a
> >> bug on the originator), END.X SID traffic may be sent using a wrong
> >> algo. We wanted to avoid it as that can be seen as a security issue.
> >>
> >> thanks,
> >> Peter
> >>
> >>
> >>
> >>>
> >>> Thanks

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Dongjie (Jimmy)]

Hi Ketan, 

I agree the text proposed by Acee is better. In the flex-algo draft, there is 
no description of "specific algorithm topologies". OTOH, Flex-algo can specify 
the constraints on particular topologies.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
> Sent: Friday, January 31, 2020 8:38 PM
> To: Acee Lindem (acee) ; Peter Psenak (ppsenak)
> ; li_zhenqi...@hotmail.com; Christian Hopps
> ; lsr 
> Cc: lsr-ads ; draft-li-lsr-ospfv3-srv6-extensions
> 
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
> Thanks Acee. Your proposed text looks much better.
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 31 January 2020 18:02
> To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak)
> ; li_zhenqi...@hotmail.com; Christian Hopps
> ; lsr 
> Cc: draft-li-lsr-ospfv3-srv6-extensions
> ; lsr-ads 
> Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions
> 
> Hey Ketan,
> 
> Looks good - but can we simplify/shorten the last sentence?
> 
> 
> On 1/31/20, 7:22 AM, "Ketan Talaulikar (ketant)"  wrote:
> 
> Hi Acee,
> 
> We'll update the text as follows in sec 8 to clarify this. Please let 
> know if
> this works.
> 
> 
>All End.X SIDs MUST be subsumed by the subnet of a Locator with the
>matching algorithm which is advertised by the same node in an SRv6
>Locator TLV.  End.X SIDs which do not meet this requirement MUST
> be
>ignored.
> 
> 
> 
>All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a
>Locator with the matching algorithm which is advertised by the same
>node in an SRv6 Locator TLV.  End.X SIDs which do not meet this
>requirement MUST be ignored. This ensures that the node
>advertising the End.X or LAN End.X SID is also advertising its
>corresponding Locator with matching algorithm that would be used
>for routing packets destined to that SID to its parent node
>consistently over the specific algorithm topology.
> 
> 
> How about  "... with the algorithm that will be used for computing paths
> destined to the SID."?
> 
> Do we refer to "specific algorithm topologies" in the flex algorithm draft? I
> haven't read it for a while...
> 
> Thanks,
> Acee
> 
> 
> Thanks,
> Ketan
> 
> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 30 January 2020 23:02
> To: Peter Psenak (ppsenak) ; Ketan Talaulikar
> (ketant) ; li_zhenqi...@hotmail.com; Christian Hopps
> ; lsr 
> Cc: draft-li-lsr-ospfv3-srv6-extensions
> ; lsr-ads 
> Subject: Re: [Lsr] WG Adoption Call for 
> draft-li-lsr-ospfv3-srv6-extensions
> 
> Hi Peter,
> 
> On 1/30/20, 12:25 PM, "Peter Psenak"  wrote:
> 
> Hi Acee,
> 
> On 30/01/2020 18:12, Acee Lindem (acee) wrote:
> > Hi Peter,
> >
> > On 1/30/20, 11:36 AM, "Peter Psenak" 
> wrote:
> >
> >  Hi Acee,
> >
> >  On 30/01/2020 17:11, Acee Lindem (acee) wrote:
> >  > Hi Ketan,
> >  >
> >  > In that case, it doesn’t make sense to include it in the
> End.X
> >  > advertisement since you need to look it up to check it
> anyway. I don’t
> >  > see any benefit here.
> >  The benefit is to make sure that the END.X SID that was
> configured for
> >  the algo X is covered by the locator that has the same algo.
> >
> >  If you do not advertise the algo with END.X SID, you have no
> way of
> >  checking that on rcv side.
> >
> > Ok - so it is to verify that algorithm for the adjacency matches 
> that
> algorithm for the longest match locator - which may be advertised by
> a >different OSPFv3 router. Correct?
> 
> yes.
> 
> 
> >I guess I don't see why the algorithm for the END.X SID just isn't
> defined as the algorithm from the longest match locator. That way, everyone
> in >the area would use the same one and there would be less that could go
> wrong. What am I missing?
> 
> locators may change over time. During the reconfiguration a END.X
> SID
> may wrongly be associated with the incorrect locator from a different
> algo.
> 
> Also if for some reason the right locator is not advertised (due to a
> bug on the originator), END.X SID traffic may be sent using a wrong
> algo. We wanted to avoid it as that can be seen as a security issue.
> 
> Ok - makes sense. It would be good to capture these reasons in the along
> with the test for ignoring END.X SIDs that have conflicting algorithms with
> their longest matching locator.
> 
> thanks,
> Peter
> 
> 
> 
> >
> > Thanks,
> > Acee
> >
> >
> >  thanks,
> >  Peter
> >

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Dongjie (Jimmy)]

Support the adoption of this draft.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 09, 2019 5:50 PM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

For your convenience, here is a URL for the draft:

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

Thanks,
Acee

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

[Lsr] 答复: Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Dongjie (Jimmy)]

Yes, I support the adoption.

Best regards,
Jie

发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2019年2月13日 21:26
收件人: lsr@ietf.org
主题: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix 
Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

This begins a two week adoption poll for the subject draft. Please send your 
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.

All authors have responded to the IPR poll and there is one  
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.

Thanks,
Acee

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

[Lsr] 答复: 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Dongjie (Jimmy)]

+1. 

Support to start the adoption poll on both drafts.

-Jie

> -邮件原件-
> 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Aijun Wang
> 发送时间: 2019年2月14日 10:38
> 收件人: 'Christian Hopps' ; lsr@ietf.org
> 抄送: lsr-cha...@ietf.org; lsr-...@ietf.org
> 主题: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
> poll.
> 
> Hi, Christian:
> 
> Supports for the adoption of two drafts at the same time, in which
> one(draft-li-lsr-dynamic-flooding-02) focuses on the centralized mode and
> the other(draft-cc-lsr-flooding-reduction-01) focuses on the distributed
> mode.
> 
> The centralized mode for is one straightforward way to realize the flooding
> reduction, and I admire Tony Li give his solution first. But from the
> consideration of solution robustness, the distributed mode may be more
> promising.
> My consideration for distributed mode is that it should not cover only the
> algorithm, more contents need to be standardized in future. Huaimo has one
> good start point for distributed mode, and he also gives abundant thoughts
> for the centralized mode that the current version of
> draft-li-lsr-dynamic-flooding-02 has not covered yet.
> 
> Proposal for the name of two drafts may be
> draft-ietf-lsr-flooding-reduction-centralized-mode and
> draft-ietf-lsr-flooding-reduction-distributed-mode.
> 
> 
> Best Regards.
> 
> Aijun Wang
> Network R and Operation Support Department China Telecom Corporation
> Limited Beijing Research Institute,Beijing, China.
> 
> -邮件原件-
> 发件人: Christian Hopps [mailto:cho...@chopps.org]
> 发送时间: 2019年2月11日 18:45
> 收件人: lsr@ietf.org
> 抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> 主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
> 
> 
> Hi Folks,
> 
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
> 
> The aim of this document is to describe the problem space and standardize a
> way to signal dynamic flooding information. It does not standardize any
> specific algorithm for flooding topology creation.
> 
> Authors please respond indicating if you are aware of any IPR related to
> this work.
> 
> We also have another draft (draft-cc-lsr-flooding-reduction-01) that started
> as a distributed flooding topology algorithm and morphed into that plus
> competing ideas on signaling of flooding topology information. The intent
> after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG
> can discuss adding any signaling ideas from this work to the adopted
> signaling draft (with proper attribution given as appropriate), and two, for
> the authors of draft-cc-lsr-flooding-reduction-01 to publish a new document
> without the signaling portion and instead focus on their flooding topology
> algorithm. This new focused document can be considered in parallel along
> with the other algorithm work that has been proposed.
> 
> Flooding topology creation is seen as a hard problem for which we don't
> expect a one-size-fits-all solution. Taking the steps outlined above will
> help us move forward on the solutions.
> 
> Thanks,
> Chris & Acee.
> LSR WG Chairs.
> 
> ___
> 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] IPR Poll on "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

[Dongjie (Jimmy)]

Hi Acee,

I'm not aware of any IPR other than the one referenced below.

Best regards,
Jie
发件人：Acee Lindem (acee) 
收件人：Aijun Wang 
;draft-wang-lsr-ospf-prefix-originator-...@ietf.org 

抄 送：lsr@ietf.org 
时间：2019-02-13 10:07:46
主 题：Re: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Speaking as a co-author,
This IPR referenced below is the only one I’m aware of as well.
Thanks,
Acee

From: Aijun Wang 
Date: Tuesday, February 12, 2019 at 8:48 PM
To: Acee Lindem , 
"draft-wang-lsr-ospf-prefix-originator-...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: 答复: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Hi, Acee:

Apart from the IPR declared in https://datatracker.ietf.org/ipr/3420/ , I am 
not aware of any other IPR.
Thanks for your efforts.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
发送时间: 2019年2月9日 1:01
收件人: draft-wang-lsr-ospf-prefix-originator-...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr] IPR Poll on "OSPF Extension for Prefix Originator" - 
draft-wang-lsr-ospf-prefix-originator-ext-01

Authors,

In preparation for a WG adoption call:

Are you aware of any IPR relating to 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-prefix-originator-ext? 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


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

Re: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]

[Dongjie (Jimmy)]

Support moving forward with the centralized and distributed solutions specified 
in separated drafts. As discussed in previous mails, the procedure and protocol 
extensions needed for the two modes could be different, and a particular 
network may only want to use one mode.

As for the centralized solution, maybe it could be refined with the advantage 
of the centralized part in both existing drafts.

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Lizhenbin
> Sent: Monday, February 04, 2019 5:36 PM
> To: Christian Hopps ; lsr@ietf.org
> Subject: [Lsr] 答复: Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> Hi Chris & Acee,
> 
> > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and
> drfat-li-dynamic-flooding-isis
> >   published centralized solution.
> >
> > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and
> draft-cc-ospf-flooding-reduction
> >   published distributed solution
> 
> Thanks for your summary we know the fact that at beginning there was not any
> confliction between the two drafts.
> 
> 
> > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors)
> >   - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*.
> >   - Does not specify distributed algorithm only how to indicate one in use,
> small change.
> 
> I do not think it is a small change. It is to introduced the totally new 
> solution which
> was already defined in the other existing draft. It is not an appropariate 
> behavior
> and the root cause of the potential confliction.
> 
> 
> I also think the distributed solution includes more than the algorithms 
> defined in
> the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  
> defined
> in the draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. Since 
> the
> co-authors could not merge the draft, though the existing suggestion proposed 
> is
> try to separate the two drafts, there is still overlap on the distributed 
> solution
> between the two drafts which may be the source of continuous confliction in 
> the
> future. In order to avoid the situation I would like to propose following
> suggestions:
> - move both the two drafts forward in parallel keeping 
> draft-li-dynamic-flooding
> focus on the centralized solution and draft-cc-lsr-flooding-reduction on the
> distributed solution.
> - draft-li-dynamic-flooding can keep on refining the centralized solution 
> without
> mentioning distibuted solutions.
> - draft-cc-lsr-flooding-reduction can keep on refining the distributed 
> solutions.
> For the sigalling which can be shared by the two modes, the draft can 
> indicate the
> distributed solutions reuse the signalling defined in 
> draft-li-dynamic-flooding
> without defining new signalling.
> - both drafts change the draft names to reflect different solutions without
> causing confusion.
> 
> 
> Thanks & Regards,
> Zhenbin (Robin)
> 
> 
> 
> 
> 
> 
> 发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org]
> 发送时间: 2019年2月1日 20:25
> 收件人: lsr@ietf.org
> 抄送: cho...@chopps.org
> 主题: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> 
> Summary of where we are at with dynamic flooding reduction:
> 
>  - We have a well written original work that came first and described the
> problems as well as a TLVs to allow for a centralized solution
> (draft-li-dyanmic-flooding). We do not need to standardize the centralized
> algorithm.
> 
>  - A small change to this work allowed for distributed algorithms and for 
> outside
> work on distributed algorithms to continue in parallel.
> 
>  - We have another original work that started primarily as a distributed 
> algorithm
>(draft-cc-ospf-flooding-reduction)
> 
>  - Finally we also have:
>- Cross-pollination of ideas.
>- Failed attempts at merging.
>- An authors list "Arms-Race".
> 
> Moving forward:
> 
> - During IETF 103 I proposed we have no conflict if we:
> 
>1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.
>2) have authors of draft-cc-lsr-flooding-reduction work on a distributed
> algorithm as they started with.
> 
> - Acee agreed during the meeting (as chair) that this was the best way 
> forward.
> We had some agreement form the floor as well.
> 
> - Any good ideas regarding the distribution of a centralized topology can be
> debated and added (with appropriate attribution) to the base document after
> we adopt one.
> 
> - This is what happens when we adopt a document as WG work, we work on it.
> 
> - The original authors of the distributed solution can continue to work on 
> their
> distributed algorithm in a separate document which would also need
> standardization.
> 
> Does anyone see a serious problem with this path forward?
> 
> Thanks,
> Chris & Acee.
> LSR Chairs.
> 
> Christian Hopps  writes:
> 
> > We've had the authors of the individual conflicting drafts take a shot at 
> > merging
> their work.
> >
> >This has 

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Dongjie (Jimmy)]

Hi Les,

Thanks for the summary and citations. 

To my understanding, although DSCP based steering could be used in 
multi-topology scenarios, such usage is not defined in IETF specifications. 
Actually there can be many ways of choosing which topology is used for the 
forwarding of a particular packet. Thus the relationship between DSCP and MT is 
not that tightly coupled. 

Best regards,
Jie

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Thursday, November 15, 2018 12:41 PM
> To: Toerless Eckert ; lsr@ietf.org
> Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q
> 
> Toerless -
> 
> It's pretty hard to understand the context for your email.
> 
> What leads you to believe that any of the MT specifications you mention say
> anything normative about DSCP and topologies??
> 
> RFC4915 does not mention DSCP at all - but does make the statement:
> 
> https://tools.ietf.org/html/rfc4915#section-3.8
> "It is outside of the scope of this document to specify how the
>information in various topology specific forwarding structures are
>used during packet forwarding or how incoming packets are associated
>with the corresponding topology."
> 
> RFC 5120 does mention DSCP, but only as an example of something that "could"
> be used to determine on what topology a packet should be forwarded.
> 
> RFC 7722 also mentions DSCP as an example, but there is a statement in Section
> 3:
> 
> "It is assumed, but
>outside the scope of this specification, that the network layer is
>able to choose which topology to use for each packet"
> 
> IGP WGs have never attempted to recommend (let alone normatively define)
> any relationship between DSCP and MT.
> 
> ???
> 
>Les
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Toerless Eckert
> > Sent: Wednesday, November 14, 2018 6:29 PM
> > To: lsr@ietf.org
> > Subject: [Lsr] LSR: Using DSCP for path/topology selection Q
> >
> > Whats the current best guidance on using DSCP for selection of path,
> > specifically for selection of topology with MTR (RFCs 4915, 5120, 7722) ?
> >
> > My understanding from history is that this looked like a good idea to
> > customers first, but when implementations became available, customers
> > really did not want to implement it because of the overloading of DSCP
> > between QoS and routing and the resulting management complexity.
> >
> > Has the idea of using DSCP for path selection been re-introduced in
> > any later work like flex-Algos ?
> >
> > If there could be rough consensus that this is in general a bad idea,
> > i wonder if it would be appropriate to have a short normative document
> > from LSR defining that the use of DSCP for topology selection is
> > historic and not recommended anymore and make this an update to above
> > three RFCs, maybe also pointing out that there are other methods to
> > select a topology and those remain viable:
> >
> > I specifically would not like to see the actual MTR RFCs to be changed
> > in status, because MTR actually does work quite well and is supported
> > in products and deployed with IP multicast, even with multiple
> > topologies for IP multicast in live-live scenarios.
> >
> > Thanks!
> > Toerless
> >
> > ___
> > 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

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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

[Dongjie (Jimmy)]

Agreed, DSCP was designed for DiffServ QoS marking to differentiate a limited 
number of service classes, it may not be suitable for non-Diffserv QoS 
scenarios.



Best regards,

Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, November 16, 2018 4:15 PM
To: Robert Raszuk 
Cc: t...@cs.fau.de; Les Ginsberg (ginsberg) ; r...@rob.sh; 
tony1ath...@gmail.com; lsr@ietf.org
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Robert,

match DSCP X
set context Y or plane Z doesn’t make it any different.
It has been used and abused in any possible way. If you want to write a BCP 
saying - use it for X/Y/Z but not for A/B/C because of - your business.

As to using it someplace else - I’d expect respective documents to cover the 
use, flex-algo drafts as to your example.

More fundamentally, (flex-algo is the best example) we have got context aware 
metadata in a form of: MPLS labels (SR SID), v6 EHs, plethora of overlay 
encaps, etc, with accompanying CP extensions that can be used to achieve 
exactly that.

Now tell me - why again DSCP?

P.S. in my previous life, working on 5G transport slicing (yes, i know :)) - i 
needed per slice identity over the common transport, we ended up looking at UDP 
port ranges, rather than DSCP - too few bits

Cheers,
Jeff
On Thu, Nov 15, 2018 at 23:37 Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Jeff,

> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...

That's pretty narrow view. I could say the worst possible example :)  You would 
have to either encapsulate or apply your sample config consistently on every 
hop. Br.

To me DSCP can be used to map packets to different routing context, different 
plane or can be used as a parameter in flex-algorithm.

Thx,
R.





On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
Tony,

What architecture?
PBR is a form of:
match DSCP X
set next-hop Y
needs no interoperability...
If someone wants to describe how they use a particular vendor feature to solve 
a particular problem in a BCP, sure, the more BCPs - the better.

Wrt using DSCP in routing decision process - it was a bad idea back then, 
hasn’t got any better now... besides - now we have got a toolbox that wasn’t 
available then.

Cheers,
Jeff
On Thu, Nov 15, 2018 at 22:56 Tony Li 
mailto:tony1ath...@gmail.com>> wrote:



On Nov 15, 2018, at 8:47 PM, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:

The question is really - what is here to standardize?


There’s a fine architectural BCP here: this is how we are solving problem XYZ.  
Please don’t break this.

Tony

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

Re: [Lsr] 答复: 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

[Dongjie (Jimmy)]

Hi Acee, Ketan and Aijun, 

I also agree that the introduction of source router ID could be a generic 
useful extension to OSPF, we already have this in IS-IS [RFC 7794]. 

As for the inter-area topology retrieval use case, I tend to agree that there 
can be multiple ways to achieve this, thus it would make sense to decouple this 
specific use case with the generic extension. 

Best regards,
Jie

> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Tuesday, July 24, 2018 10:37 PM
> To: Ketan Talaulikar (ketant) ; Peter Psenak (ppsenak)
> ; Aijun Wang ; 'Rob Shakir'
> 
> Cc: Dongjie (Jimmy) ; cho...@chopps.org; lsr@ietf.org
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area
> topology retrieval
> 
> Hi Ketan,
> 
> On 7/24/18, 7:44 AM, "Ketan Talaulikar (ketant)"  wrote:
> 
> Hi Aijun,
> 
> Your draft introduces the Source Router ID which is, by itself, an useful
> protocol extension.
> 
> I agree. What is the use case for advertisement in IS-IS? Perhaps this could 
> be
> used as the primary motivation.
> 
> 
>However, the use-case on inter-as topology retrieval has issues which has
> been shared by many of us at the mike, offline and on the list.
> 
> And this could be moved to an appendix or even completely.
> 
> Thanks,
> Acee
> 
> Could you consider de-coupling the two?
> 
> Also, if the proposal for learning inter-AS as described by you works for 
> your
> own specific network design (and you don't think any of the points made affect
> that decision), then please go ahead. However, I do not see the point of 
> trying to
> get that as an IETF document?
> 
> Thanks,
> Ketan
> 
> -----Original Message-
> From: Peter Psenak (ppsenak)
> Sent: 24 July 2018 04:22
> To: Aijun Wang ; 'Rob Shakir' 
> Cc: 'Dongjie (Jimmy)' ; cho...@chopps.org; Ketan
> Talaulikar (ketant) ; lsr@ietf.org; Acee Lindem (acee)
> 
> Subject: Re: 答复: [Lsr] 答复: 答复: Regarding OSPF extension for
> inter-area topology retrieval
> 
> Hi Aijun,
> 
> On 24/07/18 05:37 , Aijun Wang wrote:
> > _Hi, Peter:_
> >
> > For point-to-point interface, as described in  OSPFv2(RFC2328 12.4.1.1.
> Describing point-to-point interfaces)
> <https://tools.ietf.org/html/rfc2328#page-130>, the router LSA will include 
> two
> links description for each interface, within which the “type 3 link”(stub 
> network)
> will describe the subnet mask of the point-to-point interface.
> >
> > For broadcast/NBMA interface, the DR will be elected and it will
> > generate the network LSA which will include also the subnet mask of
> > the connected interface.
> >
> > For unnumbered and virtual link, if you consider we should include
> > them also for all possible scenarios even if we seldom use them in
> > large network, we can consider expand the summary LSA to cover it, as
> > done by this draft.
> 
> there is no way to address unnumbered p2p case your way, because there is
> no Summary LSA generated to other area in such case.
> 
> Anyway, reconstructing a topology of a remote area based on the prefix
> announcements that come from it is a broken concept. I have given you several
> examples where your proposal does not work.
> 
> thanks,
> Peter
> 
> >
> > For Anycast prefixes situation that you described(although we seldom
> > plan our network in such way), the PCE controller will not deduce the
> > wrong information from the reported information--Different router
> > advertise the same prefix, why can’t they be connected in logically?
> >
> > On summary, the ABR can know and report the originator of the
> > connected interface’s prefixes, and also the connected information for
> > the unnumbered/virtual link from the traditional router LSA/network
> > LSA message, thus can transfer them to the router that run BGP-LS,
> > then to the PCE controller to retrieval the topology.
> >
> > _To Rob: _
> >
> > BGP-LS is one prominent method to get the underlay network topology
> > and has more flexibility to control the topology export as described
> > in RFC
> > 7752 <https://tools.ietf.org/html/rfc7752#section-1>.
> >
> > Solution 1) that you proposed is possible, but we will not run two
> > different methods to get the topology.
> >
> > Solution 2) is also one possible deployment, but it eliminates the
> > advantage of the BGP-LS, in whic

[Lsr] FW: I-D Action: draft-dong-lsr-sr-enhanced-vpn-00.txt

[Dongjie (Jimmy)]

FYI we have submitted a draft on the IGP extensions for SR based enhanced VPN. 

Comments are welcome.

Best regards,
Jie

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Thursday, June 21, 2018 12:06 AM
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dong-lsr-sr-enhanced-vpn-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : IGP Extensions for Segment Routing based Enhanced VPN
Authors: Jie Dong
Stewart Bryant
Filename: draft-dong-lsr-sr-enhanced-vpn-00.txt
Pages   : 13
Date: 2018-06-20

Abstract:
   Enhanced VPN (VPN+) is an enhancement to VPN services to support the
   needs of new applications, particularly including the applications
   that are associated with 5G services.  These applications require
   better isolation and have more stringent performance requirements
   than that can be provided with traditional overlay VPNs.  An enhanced
   VPN may form the underpin of 5G transport network slicing, and will
   also be of use in its own right.  This document describes how Multi-
   Topology Routing (MTR) as described in RFC 5120 and RFC 4915, can be
   extended to signal the resources allocated in the underlay network to
   construct the virtual networks for enhanced VPN services, together
   with the Segment Routing Identifiers (SIDs) used to identify and
   access the network resources allocated for the virtual networks in
   the data plane.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-dong-lsr-sr-enhanced-vpn-00
https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-00


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Dongjie (Jimmy)]

Hi Les, 

Thanks for your comments and analysis. Please see my replies inline:

> -Original Message-
> From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
> Sent: Saturday, April 21, 2018 1:44 AM
> To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Dongjie (Jimmy)
> <jie.d...@huawei.com>; Acee Lindem (acee) <a...@cisco.com>; lsr@ietf.org
> Subject: RE: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Jie -
> 
> I strongly agree with Peter here.
> 
> It is "tempting" to think of algorithm/topology as interchangeable - but I 
> think it
> is wrong to do so.

I'm not saying algorithm and topology are interchangeable. Just want to clarify 
their relationship, especially the topology related part.

Currently the flex-algo represents the combination of several things：topology 
constraint, metric type and computation algorithm. Because topology can be 
defined in multiple ways, I'm wondering whether flex-algo should be topology 
independent, i.e. just cover the metric type and algorithm. 


> It is true that some things achievable via flex-algo could be achieved using a
> separate topology - but at a much higher deployment cost and with
> considerably less flexibility.

Some comparison of the two mechanisms would be needed before we can say 
flex-algo is more lightweight than multi-topology. 

With flex-algo, the topology is defined by excluding or including a set of 
affinities. Note that using affinity does not mean less configuration workload, 
as affinities also need to be configured on each link. Affinity was originally 
used to specify the constraints on a particular path, using affinity to specify 
a constraint topology is more complicated and would require more efforts in 
affinity planning and configuration. For example, if you want to define a 
particular topology which cannot be described with existing affinities, you 
need to introduce new affinities and configure them on each link you want to 
include/exclude. 

> The "right way" to think of flex-algo is as a constraint based SPF applied to 
> a
> given topology.
>
> Today, topologies are most commonly used to define a set of nodes/links which
> support a particular functionality (e.g., IPv4, IPv6, multicast).

Defining topologies with different functionalities is one of the use cases of 
multi-topology. One can also define multiple topologies of IPv4.

> To take a simple example, if a given flex-algorithm  is defined to prefer 
> "blue"
> links one could:
> 
> 1)Calculate shortest path using only blue links on a unicast topology. Result
> would be used to forward a certain class of unicast traffic.
> 
> 2)Calculate shortest path using only blue links on a multicast topology. 
> Result
> would be used to build an RPF tree for some subset of multicast traffic.
> 
> Could you do this purely with MT? Yes - but it would require introducing two
> new topologies (blue unicast, blue multicast), advertising additional topology
> specific support per adjacency, and configuring additional topology support 
> per
> link on every router in the network which participates in the new topologies.
> And if you wanted to prefer green links for another use case, you would then
> have to introduce two more topologies.

In this example, one topology which only includes the blue links needs to be 
defined. No matter you use it for unicast or multicast traffic, the topology 
would be the same. There is no additional topology needed with MT. 

With MTR, you need to enable MT-blue on each link you want to use. With 
affinity, you need to configure each link you want to include with blue color. 
Either the MT or the affinity information needs to be advertised in IGP. The 
deployment cost would be similar when you taking the affinity configuration and 
advertisement into account.

> Much much easier to simply advertise support for a given algorithm and use it
> on the topology(s) where you have a use case.

Advertising the support for a given algorithm is just a subset of the 
deployment cost of flex-algo. The affinity planning and configuration also 
needs to be considered.

> And this example is a very simple one. Flex-algo supports multiple constraints
> besides affinity - so the scalability of using a separate topology for each 
> set of
> constraints is extremely poor.

Agree that the metric type and computation algorithm as defined in flex-algo 
are useful constraints and complementary to MT, while the affinity based 
topology constraints can also be specified using MT. 

Maybe it is better to separate the "topological constraints" and the "algorithm 
constraints". The former can be done in multiple ways and requires distributed 
configuration, while the latter is more like a centralized definition.

Best regards,
Jie

> 
> HTH

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Dongjie (Jimmy)]

Hi Acee, 

Thanks for your comments. 

I guess you are referring to a particular usage of MTR, when multiple 
topologies have different routes to the same prefix, with IP forwarding some 
additional mechanism is needed to match the traffic to particular topology. 
This can be solved with SR forwarding (using per-topology SID).

Flex-algo also allows multiple routes to the same prefix, and uses different 
prefix-SIDs in the SR forwarding. 

Best regards,
Jie

> -Original Message-
> From: Acee Lindem (acee) [mailto:a...@cisco.com]
> Sent: Friday, April 20, 2018 6:58 PM
> To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Dongjie (Jimmy)
> <jie.d...@huawei.com>; lsr@ietf.org
> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Hi Jie, Peter,
> 
> Another difference with Multiple Topology Router (MTR) is that it implies the
> abstraction of a RIB per topology so you could have multiple routes to the 
> same
> prefix dependent on criteria other than longest prefix matching (e.g., ingress
> interface). The authors can correct me if I'm wrong, but I don't believe Flex
> Algorithm requires this abstraction.
> 
> Thanks,
> Acee
> 
> 
> On 4/20/18, 5:33 AM, "Peter Psenak (ppsenak)" <ppse...@cisco.com> wrote:
> 
> Dongjie,
> 
> On 20/04/18 11:00 , Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Please see inline:
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Friday, April 20, 2018 3:31 PM
> >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> >> <a...@cisco.com>; lsr@ietf.org
> >> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> Drafts
> >>
> >> Hi Dongjie,
> >>
> >> please see inline:
> >>
> >>
> >> On 20/04/18 05:04 , Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>> Thanks for the prompt response. Please see inline:
> >>>
> >>>> -Original Message-
> >>>> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>>> Sent: Thursday, April 19, 2018 4:28 PM
> >>>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> >>>> <a...@cisco.com>; lsr@ietf.org
> >>>> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> >>>> Drafts
> >>>>
> >>>> Hi Dongjie,
> >>>>
> >>>> please see inline:
> >>>>
> >>>> On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Here are some comments on the Flex Algo drafts.
> >>>>>
> >>>>> SR algorithm as defined in
> >>>>> draft-ietf-isis-segment-routing-extensions
> >>>>> is about the algorithm used for path calculation, such as SPF, 
> strict
> SPF, etc.
> >>>>>
> >>>>> In the Flex Algo drafts, the definition of algorithm is extended to
> >>>>> include topological constraints and the metric type used in
> >>>>> calculation, which makes its functionality analogous to
> >>>>> multi-topology routing
> >>>> (MTR).
> >>>>
> >>>> not really. MTR is defined on a per link basis and each MTR
> >>>> participation needs to be advertised on a per link basis. There is no
> such
> >> concept in flex-algo draft.
> >>>
> >>> Both mechanisms have the capability to define a specific sub-topology
> in the
> >> network, that's why I say they are analogous in functionality. 
> Flex-algo
> uses link
> >> affinity to describe the constraints of the corresponding topology,
> which is also
> >> a link attribute and needs to be configured on a per-link basis.
> >>>
> >>> The difference is in topology advertisement. In MTR a consistent
> topology is
> >> constructed by each node advertising its own adjacent links in the
> topology.
> >> While in flex-algo, the whole topology is advertised as part of the
> algorithm
> >> definition by each node, and priority based selection is used to reach 
> a
> >> consistent view by all nodes.
> >>>
> >>>

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Dongjie (Jimmy)]

Hi Peter, 

Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, April 20, 2018 5:34 PM
> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> <a...@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Dongjie,
> 
> On 20/04/18 11:00 , Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Please see inline:
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Friday, April 20, 2018 3:31 PM
> >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> >> <a...@cisco.com>; lsr@ietf.org
> >> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> >> Drafts
> >>
> >> Hi Dongjie,
> >>
> >> please see inline:
> >>
> >>
> >> On 20/04/18 05:04 , Dongjie (Jimmy) wrote:
> >>> Hi Peter,
> >>>
> >>> Thanks for the prompt response. Please see inline:
> >>>
> >>>> -Original Message-
> >>>> From: Peter Psenak [mailto:ppse...@cisco.com]
> >>>> Sent: Thursday, April 19, 2018 4:28 PM
> >>>> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> >>>> <a...@cisco.com>; lsr@ietf.org
> >>>> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex
> >>>> Algorithm Drafts
> >>>>
> >>>> Hi Dongjie,
> >>>>
> >>>> please see inline:
> >>>>
> >>>> On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Here are some comments on the Flex Algo drafts.
> >>>>>
> >>>>> SR algorithm as defined in
> >>>>> draft-ietf-isis-segment-routing-extensions
> >>>>> is about the algorithm used for path calculation, such as SPF, strict 
> >>>>> SPF,
> etc.
> >>>>>
> >>>>> In the Flex Algo drafts, the definition of algorithm is extended
> >>>>> to include topological constraints and the metric type used in
> >>>>> calculation, which makes its functionality analogous to
> >>>>> multi-topology routing
> >>>> (MTR).
> >>>>
> >>>> not really. MTR is defined on a per link basis and each MTR
> >>>> participation needs to be advertised on a per link basis. There is
> >>>> no such
> >> concept in flex-algo draft.
> >>>
> >>> Both mechanisms have the capability to define a specific
> >>> sub-topology in the
> >> network, that's why I say they are analogous in functionality.
> >> Flex-algo uses link affinity to describe the constraints of the
> >> corresponding topology, which is also a link attribute and needs to be
> configured on a per-link basis.
> >>>
> >>> The difference is in topology advertisement. In MTR a consistent
> >>> topology is
> >> constructed by each node advertising its own adjacent links in the 
> >> topology.
> >> While in flex-algo, the whole topology is advertised as part of the
> >> algorithm definition by each node, and priority based selection is
> >> used to reach a consistent view by all nodes.
> >>>
> >>>> Flex-algo works on top of existing IGP topologies.
> >>>
> >>> Do you mean flex-algo can work on top of the default IGP topology,
> >>> and can
> >> also work on top of multiple IGP topologies created with MTR?
> >>
> >> yes
> >>
> >>> In the latter case, it seems you would create sub-topologies on top
> >>> of a sub-topology (MTR) of the default topology,
> >>
> >> no. We don't create any topologies with flex-algo. We compute
> >> constrained based paths.
> >
> > MTR is also used to compute constrained based path:) The constraint is
> described as a sub-topology.
> 
> you are mixing two different things - topology and path computations, these
> are two different things.

As I mentioned in previous mail, there are two steps: 

1. Define a particular topology or topological constraints.
2. Perform path computation using specific metric type and computation 
algorithm (currently SPF).

IMO these two steps can be orthogonal to each other. The topology can be 
defined using either MTR or link affinities. IMO they provide the same 
functio

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Dongjie (Jimmy)]

Hi Peter, 

Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, April 20, 2018 3:31 PM
> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> <a...@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Hi Dongjie,
> 
> please see inline:
> 
> 
> On 20/04/18 05:04 , Dongjie (Jimmy) wrote:
> > Hi Peter,
> >
> > Thanks for the prompt response. Please see inline:
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Thursday, April 19, 2018 4:28 PM
> >> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> >> <a...@cisco.com>; lsr@ietf.org
> >> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> >> Drafts
> >>
> >> Hi Dongjie,
> >>
> >> please see inline:
> >>
> >> On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> >>> Hi,
> >>>
> >>> Here are some comments on the Flex Algo drafts.
> >>>
> >>> SR algorithm as defined in
> >>> draft-ietf-isis-segment-routing-extensions
> >>> is about the algorithm used for path calculation, such as SPF, strict 
> >>> SPF, etc.
> >>>
> >>> In the Flex Algo drafts, the definition of algorithm is extended to
> >>> include topological constraints and the metric type used in
> >>> calculation, which makes its functionality analogous to
> >>> multi-topology routing
> >> (MTR).
> >>
> >> not really. MTR is defined on a per link basis and each MTR
> >> participation needs to be advertised on a per link basis. There is no such
> concept in flex-algo draft.
> >
> > Both mechanisms have the capability to define a specific sub-topology in the
> network, that's why I say they are analogous in functionality. Flex-algo uses 
> link
> affinity to describe the constraints of the corresponding topology, which is 
> also
> a link attribute and needs to be configured on a per-link basis.
> >
> > The difference is in topology advertisement. In MTR a consistent topology is
> constructed by each node advertising its own adjacent links in the topology.
> While in flex-algo, the whole topology is advertised as part of the algorithm
> definition by each node, and priority based selection is used to reach a
> consistent view by all nodes.
> >
> >> Flex-algo works on top of existing IGP topologies.
> >
> > Do you mean flex-algo can work on top of the default IGP topology, and can
> also work on top of multiple IGP topologies created with MTR?
> 
> yes
> 
> > In the latter case, it seems you would create sub-topologies on top of
> > a sub-topology (MTR) of the default topology,
> 
> no. We don't create any topologies with flex-algo. We compute constrained
> based paths.

MTR is also used to compute constrained based path:) The constraint is 
described as a sub-topology.

With flex-algo, you need to define the algorithm first, then the constrained 
path can be computed according to the algorithm. 

According to your presentation in IETF101, a flex-algo specifies: 

  a) Set of constraints - e.g affinity exclude-any, include-any, include-all
  b) Metric type - IGP metric, Delay (RFC7810), TE metric (RFC5305), ...
  c) Algorithm type - SPF, ...

As I see a) defines a constrained topology, or a sub-topology. 

> > which sounds quite complicated. Maybe another way is to use MTR to create
> the sub-topology needed, and define the metric type and computation
> algorithm using a particular flex-algo?
> 
> what we propose is simple - compute multiple constrained based paths on top
> of a given topology.
> 
> What you propose is indeed complicated - create as many topologies as many
> constrained based paths you need. That solution does not scale.

Not exactly. Multiple constrained paths can be created in the same 
sub-topology. You don't need as many topologies as the number of paths. 

> >
> >>> Section 4.1 of the Flex Algo drafts says "Flex-Algorithm definition
> >>> is topology independent", while in some places Flex Algo is
> >>> described as a "light weight alternative" to MTR.
> >>
> >> there is no mention of MTR in the document.
> >
> > I was referring to another relevant draft:
> draft-wijnands-mpls-mldp-multi-topology-00. Sorry for the confusion caused. It
> seems that draft considered MTR and flex-algo as comparable candidates for
> creating sub-topology.
> 
> then please talk t

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Dongjie (Jimmy)]

Hi Peter,

Thanks for the prompt response. Please see inline:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Thursday, April 19, 2018 4:28 PM
> To: Dongjie (Jimmy) <jie.d...@huawei.com>; Acee Lindem (acee)
> <a...@cisco.com>; lsr@ietf.org
> Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
> 
> Hi Dongjie,
> 
> please see inline:
> 
> On 19/04/18 09:10 , Dongjie (Jimmy) wrote:
> > Hi,
> >
> > Here are some comments on the Flex Algo drafts.
> >
> > SR algorithm as defined in draft-ietf-isis-segment-routing-extensions
> > is about the algorithm used for path calculation, such as SPF, strict SPF, 
> > etc.
> >
> > In the Flex Algo drafts, the definition of algorithm is extended to
> > include topological constraints and the metric type used in
> > calculation, which makes its functionality analogous to multi-topology 
> > routing
> (MTR).
> 
> not really. MTR is defined on a per link basis and each MTR participation 
> needs
> to be advertised on a per link basis. There is no such concept in flex-algo 
> draft.

Both mechanisms have the capability to define a specific sub-topology in the 
network, that's why I say they are analogous in functionality. Flex-algo uses 
link affinity to describe the constraints of the corresponding topology, which 
is also a link attribute and needs to be configured on a per-link basis. 

The difference is in topology advertisement. In MTR a consistent topology is 
constructed by each node advertising its own adjacent links in the topology. 
While in flex-algo, the whole topology is advertised as part of the algorithm 
definition by each node, and priority based selection is used to reach a 
consistent view by all nodes. 

> Flex-algo works on top of existing IGP topologies.

Do you mean flex-algo can work on top of the default IGP topology, and can also 
work on top of multiple IGP topologies created with MTR? In the latter case, it 
seems you would create sub-topologies on top of a sub-topology (MTR) of the 
default topology, which sounds quite complicated. Maybe another way is to use 
MTR to create the sub-topology needed, and define the metric type and 
computation algorithm using a particular flex-algo? 

> > Section 4.1 of the Flex Algo drafts says "Flex-Algorithm definition is
> > topology independent", while in some places Flex Algo is described as
> > a "light weight alternative" to MTR.
> 
> there is no mention of MTR in the document.

I was referring to another relevant draft: 
draft-wijnands-mpls-mldp-multi-topology-00. Sorry for the confusion caused. It 
seems that draft considered MTR and flex-algo as comparable candidates for 
creating sub-topology.

> > It would be necessary if the relationship between Flex-Algo and MTR
> > can be further clarified. Whether the two mechanisms are complementary
> > to each other, or Flex-Algo will be used to replace MTR?
> 
> they are orthogonal.

If as you said they are orthogonal, it would be better to avoid overlapping 
functionalities in topology definition and creation. 

Best regards,
Jie


> thanks,
> Peter
> 
> >
> > And if it is claimed that Flex-Algo is light weight than MTR, it would
> > be helpful to give a thorough comparison of the two mechanisms somewhere.
> >
> > Best regards,
> >
> > Jie
> >
> > *From:*Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Acee Lindem
> > (acee)
> > *Sent:* Tuesday, April 17, 2018 10:44 PM
> > *To:* lsr@ietf.org
> > *Subject:* [Lsr] LSR Working Group Adoption Poll for Flex Algorithm
> > Drafts
> >
> > This begins a two-week adoption poll for the following Flex Algorithm
> > drafts:
> >
> > https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
> >
> > https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/
> >
> > The adoption poll will end at 12:00 AM EST on May 2^nd , 2018. Please
> > indicate your support of opposition of the drafts.
> >
> > Additionally, the authors are amenable to combining the drafts into a
> > single draft. If you have an opinion, please state that as well.
> >
> > Thanks,
> >
> > Acee
> >
> >
> >
> > ___
> > 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