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

[Linda Dunbar]

Tony,

I have always had high respect towards your opinion.
I am simply asking questions and concerns as an individual. Hope not getting 
into company A is better than company B debate.

Linda

From: Tony Li  On Behalf Of Tony Li
Sent: Friday, December 1, 2023 4:44 PM
To: Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)


Hi Linda,




  *   Suppose the information to be carried by the  Extended IS Reachability 
(type 22) (in Example 4.1) is larger than 255. Does it mean the recipient will 
receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the 
second TLV (Type =22) might overwrite  the first TLV.


Yes, a legacy implementation may well have bugs. The proposal is to fix that: 
expect MP-TLVs.

[Linda] Are you saying only the legacy implementation with bugs will be 
confused with two TLVs with the same Type  in in one LSA?


No. All implementations have bugs. This is reality.

Implementations that do not understand MP-TLV may be confused. Correct 
implementations of MP-TLV support will not be confused.



  *   Isn’t it more straightforward to have a new TYPE value for carrying the 
extra information beyond the 255 bytes? So, the legacy routers can ignore the 
TLVs with the unrecognized types.


You could do that, but code points are not free.  We certainly cannot afford 
another code point for each existing code point.  Using just one code point is 
less than helpful: it forces us to aggregate information that has no business 
being aggregated. Ignoring information is a non-starter because it makes 
partial deployments fatal: some of the domain operates with some information 
and some of the domain operates with different information.
[Linda] Why not consider having just one additional TYPE code with sub-types to 
indicate which original TLVs the value should be appended to?


We have considered it.  See all of Les’ emails for why it’s a bad idea.

If it helps simplify this debate: we know that you work for Futurewei/Huawei 
and that the discussion has polarized into your Big-TLV faction vs. everyone 
else. Repetition of previously made points add zero value to the discussion.

Tony

___
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)

[Linda Dunbar]

Tony,


Questions are inserted below:

Linda

From: Tony Li  On Behalf Of Tony Li
Sent: Friday, December 1, 2023 2:21 PM
To: Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)


Hi Linda,

I have the following concerns about the approach proposed by  this draft:


  *   Suppose the information to be carried by the  Extended IS Reachability 
(type 22) (in Example 4.1) is larger than 255. Does it mean the recipient will 
receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the 
second TLV (Type =22) might overwrite  the first TLV.


Yes, a legacy implementation may well have bugs. The proposal is to fix that: 
expect MP-TLVs.

[Linda] Are you saying only the legacy implementation with bugs will be 
confused with two TLVs with the same Type  in in one LSA?


  *   Isn’t it more straightforward to have a new TYPE value for carrying the 
extra information beyond the 255 bytes? So, the legacy routers can ignore the 
TLVs with the unrecognized types.


You could do that, but code points are not free.  We certainly cannot afford 
another code point for each existing code point.  Using just one code point is 
less than helpful: it forces us to aggregate information that has no business 
being aggregated. Ignoring information is a non-starter because it makes 
partial deployments fatal: some of the domain operates with some information 
and some of the domain operates with different information.
[Linda] Why not consider having just one additional TYPE code with sub-types to 
indicate which original TLVs the value should be appended to?

This would not be an improvement.

Tony


___
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)

[Linda Dunbar]

I have the following concerns about the approach proposed by  this draft:


  *   Suppose the information to be carried by the  Extended IS Reachability 
(type 22) (in Example 4.1) is larger than 255. Does it mean the recipient will 
receive 2 TLVs (both with the Type 22) in one LSA? For legacy routers, the 
second TLV (Type =22) might overwrite  the first TLV.
  *   Isn't it more straightforward to have a new TYPE value for carrying the 
extra information beyond the 255 bytes? So, the legacy routers can ignore the 
TLVs with the unrecognized types.

Therefore, I don't support the WG adoption, unless those issues are resolved.

Linda

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, November 17, 2023 11:24 AM
To: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org)

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

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

[Lsr] Opsdir telechat review of draft-ietf-lsr-flex-algo-25

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

The authors have addressed my comments on revision 23. I think the draft is
ready now.

cheers, Linda


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

Re: [Lsr] Opsdir last call review of draft-ietf-lsr-flex-algo-23

[Linda Dunbar]

Peter, 

Thank you! I've studied this draft in LSR WG multiple times. I had a difficult 
time thinking how a router computing the paths when receiving 100+ topologies 
for one IGP domain, until being told most deployments only having handful of 
topologies. 

Linda


-Original Message-
From: Peter Psenak  
Sent: Thursday, September 22, 2022 2:57 AM
To: Linda Dunbar ; ops-...@ietf.org
Cc: draft-ietf-lsr-flex-algo@ietf.org; last-c...@ietf.org; lsr@ietf.org
Subject: Re: Opsdir last call review of draft-ietf-lsr-flex-algo-23

Hi Linda,

On 22/09/2022 00:24, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's  
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the Ops area 
> directors.
> Document editors and WG chairs should treat these comments just like 
> any other last call comments.
> 
> This document specifies a set of extensions to IGP to enable multiple 
> topologies within one IGP domain, and each topology has its unique 
> constraint-based path computation metric.
> 
> It would be very helpful if Section 15 (Operational Consideration) 
> included some considerations on the number of topologies to be created 
> for exemplary deployments. Even though theoretically, 
> hundreds/thousands of topologies can be supported by the mechanisms 
> described in the draft, in practice, probably only a handful of (or 
> even fewer) Flex-Algorithms are needed per IGP domain. It would be so 
> much easier to follow the document if knowing only two or three 
> Flex-Algorithm are needed.

the maximum number of flex-algos is determined by the algorithm range that is 
(128-255), as specified in section 4 of the draft:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-23%23section-4data=05%7C01%7Clinda.dunbar%40futurewei.com%7C1f01cedc0b8b47ea277808da9c6fff8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637994302096955841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=tZyj49cl6PorH91QIoebPQ8PcTTWKGNJwDaCIel2GEE%3Dreserved=0


I can add a sentence in the draft saying that the expected deployment is to use 
only a subset of those.

thanks,
Peter

> 
> Thank you
> Linda Dunbar
> 
> 
> 

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

[Lsr] Opsdir last call review of draft-ietf-lsr-flex-algo-23

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Has Nits

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

This document specifies a set of extensions to IGP to enable multiple
topologies within one IGP domain, and each topology has its unique
constraint-based path computation metric.

It would be very helpful if Section 15 (Operational Consideration) included
some considerations on the number of topologies to be created for exemplary
deployments. Even though theoretically, hundreds/thousands of topologies can be
supported by the mechanisms described in the draft, in practice, probably only
a handful of (or even fewer) Flex-Algorithms are needed per IGP domain. It
would be so much easier to follow the document if knowing only two or three
Flex-Algorithm are needed.

Thank you
Linda Dunbar


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

[Lsr] Need volunteers to take notes for Computing Aware Networking (CAN) BoF at 10am Vienna Time on Tuesday March 22

[Linda Dunbar]

We greatly appreciate volunteers to take notes for CAN BoF for Tuesday.
Please let us know if you can.

Linda & Jeffrey

From: Linda Dunbar
Sent: Thursday, March 17, 2022 10:29 PM
To: dync...@ietf.org
Cc: i...@ietf.org; lsr@ietf.org; 6man WG 
Subject: Computing Aware Networking (CAN) BoF at 10am Vienna Time on Tuesday 
March 22

There is a Computing-Aware Networking (CAN) BOF in IETF 113:  at 10am Vienna 
Time on Tuesday March 22 at Grand Park Hall 1

The Computing-Aware Networking aims at computing and network resource 
optimization by steering traffic to appropriate computing resources considering 
not only routing metric but also computing resource metric and service 
affiliation (using original resources even after clients move).

The objective of this Non-WG forming BOF is to discuss the problem space, use 
cases, gap analysis, solutions using existing techniques, and solutions that 
might require protocol extension.

The CAN BoF proponents think that this problem space has moved from research 
into 'early engineering'. It is seen as a real problem by operators, and they 
want to start planning how to address this problem in their networks. The 
purpose of this BoF is to start to build a community of interested parties and 
begin to scope the problem and requirements so that we can start to select 
among the potential solutions.

Hope you all can join the session.

We need note takers. We really appreciate your kind help.

Thank you.

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

[Lsr] Computing Aware Networking (CAN) BoF at 10am Vienna Time on Tuesday March 22

[Linda Dunbar]

There is a Computing-Aware Networking (CAN) BOF in IETF 113:  at 10am Vienna 
Time on Tuesday March 22 at Grand Park Hall 1

The Computing-Aware Networking aims at computing and network resource 
optimization by steering traffic to appropriate computing resources considering 
not only routing metric but also computing resource metric and service 
affiliation (using original resources even after clients move).

The objective of this Non-WG forming BOF is to discuss the problem space, use 
cases, gap analysis, solutions using existing techniques, and solutions that 
might require protocol extension.

The CAN BoF proponents think that this problem space has moved from research 
into 'early engineering'. It is seen as a real problem by operators, and they 
want to start planning how to address this problem in their networks. The 
purpose of this BoF is to start to build a community of interested parties and 
begin to scope the problem and requirements so that we can start to select 
among the potential solutions.

Hope you all can join the session.

We need note takers. We really appreciate your kind help.

Thank you.

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Acee,

Thank you for the valid point.
The aggregated site cost is supposed to impact a specific topology with a small 
number of routers, e.g. routers near a cluster of cell towers X.

We will add some description to the draft to address your points.

Thank you.
Linda

From: Acee Lindem (acee) 
Sent: Wednesday, January 19, 2022 10:09 AM
To: Linda Dunbar ; Robert Raszuk 
; Aijun Wang ; 
muthu.a...@gmail.com
Cc: John E Drake ; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,

Thanks for explaining that “aggregated” doesn’t mean that all the previously 
described application metrics are aggregated but that components each of these 
metric in the path are aggregated. If the algorithm isn’t specified and not all 
routers in the IGP domain use the same algorithm, then you have the possibility 
of loops.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, January 19, 2022 at 10:37 AM
To: Acee Lindem mailto:a...@cisco.com>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>, 
"muthu.a...@gmail.com<mailto:muthu.a...@gmail.com>" 
mailto:muthu.a...@gmail.com>>
Cc: John E Drake mailto:jdr...@juniper.net>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, Gyan Mishra 
mailto:hayabusa...@gmail.com>>, lsr 
mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Acee,

I am sorry for missing answering your question.

Aggregated site cost for a specific prefix is different than the base IGP cost 
for the following reasons:

-  The aggregated site cost only applies to a specific topology. The 
policy is configured to the relevant nodes to take the aggregated site cost 
into consideration in computing the shortest path.

-  As Muthu’s email stated that “The metric can be split into 'n' parts 
all internal to the specific application”. The aggregated site cost can be one 
value or a set of values.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCost Attribute-1 to the Prefix  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~   ~
|AggCost Attribute-i to the Prefix  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Aggregated cost Advertisement in OSPF


Your suggestions and comments are greatly appreciated.

Linda Dunbar

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: John E Drake mailto:jdr...@juniper.net>>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,

You seem to be either missing or avoiding my question as to why the base IGP 
metric can’t be used now that the draft has a single aggregated cost?

Aijun replied with two alternatives for changing it to allow for complex 
selection algorithm based on multiple metrics. What is the actual requirement 
here?

Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Tuesday, January 18, 2022 at 10:52 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake 
mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" 
mailto:ginsb...@cisco.com>>, Gyan Mishra 
mailto:hayabusa...@gmail.com>>, lsr 
mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can 
be a value configured on the router to which the prefix is attached. The 
aggregated site cost can be computed based on an algorithm configured on router 
for specific prefixes. The detailed algorithm of computing the aggregated site 
cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval 
for Metrics Change Advertisement which is configured on the routers to avoid 
route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to 

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

Replies inserted below:


From: Robert Raszuk 
Sent: Wednesday, January 19, 2022 10:08 AM
To: Linda Dunbar 
Cc: Aijun Wang ; Acee Lindem (acee) 
; John E Drake 
; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Linda,

> When  R3 reduces the aggregated site cost for the prefix A to a specific 
> topology
+
> The aggregated site cost only applies to a specific topology.

As it has been confirmed with flex-algo authors for a given prefix you can not 
have different cost per topology. Each locator or prefix can only be associated 
only with a single topology. That restriction does not apply to SR-MPLS, but I 
don't think this is what we are discussing here.

[Linda] That is why Peter Psenak suggested to use a new Flag in the Flag Algo 
to indicate the specific topology that needs to consider the Aggregated Site 
Cost.

A New flag (P-flag) is added to indicate that the aggregated site cost needs to 
be considered for the SPF to the prefix for a specific topology.
Flags:
0 1 2 3 4 5 6 7...
+-+-+-+-+-+-+-+-+...
|M|P| | ...
+-+-+-+-+-+-+-+-+...

Linda


On Wed, Jan 19, 2022 at 4:59 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Reply to your comments are inserted below:

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, January 19, 2022 4:18 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; John E 
Drake 
mailto:40juniper@dmarc.ietf.org>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,

The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes.

[RR] What Les and myself have been trying to highlight here is that the above 
model does not effectively work well in the underlay layer.

The moment you adjust such cost will not really spread workload distribution, 
but shift it between servers - members of given anycast address.

[Linda] that is exactly what the draft is proposing to do: shifting traffic 
among members of one ANYCAST address. For example, one prefix A has 4 instances 
attached to 4 different routers (R1/R2/R3/R4). The distance to each of the 
routers is D1/D2/D3/D4. Routers in 5G Local Data Networks have preconfigured 
ECMP or (weighted ECMP) to distribute traffic towards A via 4 available paths 
through R1/R2/R3/R4.

When  R3 reduces the aggregated site cost for the prefix A to a specific 
topology (e.g. the specific Local Data Network around Cell tower Cluster X),  
the shortest path from routers in the Cell Tower Cluster X for the prefix A 
will be shorter via R3. There are other factors influencing the shortest path 
computation and ECMP among all paths towards the prefix A.

The forwarding decision will happen at the first common P core underlay node 
from the server side and not the ingress to the network - where is what you 
would really want.

[Linda] The draft is for the scenario where there are multiple common routers 
towards multiple instances of the same prefix.


Linda



On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can 
be a value configured on the router to which the prefix is attached. The 
aggregated site cost can be computed based on an algorithm configured on router 
for specific prefixes. The detailed algorithm of computing the aggregated site 
cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval 
for Metrics Change Advertisement which is configured on the routers to avoid 
route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes. The rate of change could be in weeks or days. On rare 
occasions, there might need rate changes in hours..”

Your comments and suggestions are greatly appreciated.

Linda

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Linda 
Dunbar mailto:linda.dun...@futurewei.com>>; John E 
Drake 
mailto:40juniper@dmarc.ietf.org>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the rev

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

Reply to your comments are inserted below:

From: Robert Raszuk 
Sent: Wednesday, January 19, 2022 4:18 AM
To: Linda Dunbar 
Cc: Aijun Wang ; Acee Lindem (acee) 
; John E Drake 
; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,

The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes.

[RR] What Les and myself have been trying to highlight here is that the above 
model does not effectively work well in the underlay layer.

The moment you adjust such cost will not really spread workload distribution, 
but shift it between servers - members of given anycast address.

[Linda] that is exactly what the draft is proposing to do: shifting traffic 
among members of one ANYCAST address. For example, one prefix A has 4 instances 
attached to 4 different routers (R1/R2/R3/R4). The distance to each of the 
routers is D1/D2/D3/D4. Routers in 5G Local Data Networks have preconfigured 
ECMP or (weighted ECMP) to distribute traffic towards A via 4 available paths 
through R1/R2/R3/R4.

When  R3 reduces the aggregated site cost for the prefix A to a specific 
topology (e.g. the specific Local Data Network around Cell tower Cluster X),  
the shortest path from routers in the Cell Tower Cluster X for the prefix A 
will be shorter via R3. There are other factors influencing the shortest path 
computation and ECMP among all paths towards the prefix A.

The forwarding decision will happen at the first common P core underlay node 
from the server side and not the ingress to the network - where is what you 
would really want.

[Linda] The draft is for the scenario where there are multiple common routers 
towards multiple instances of the same prefix.


Linda



On Wed, Jan 19, 2022 at 4:52 AM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can 
be a value configured on the router to which the prefix is attached. The 
aggregated site cost can be computed based on an algorithm configured on router 
for specific prefixes. The detailed algorithm of computing the aggregated site 
cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval 
for Metrics Change Advertisement which is configured on the routers to avoid 
route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes. The rate of change could be in weeks or days. On rare 
occasions, there might need rate changes in hours..”

Your comments and suggestions are greatly appreciated.

Linda

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Linda 
Dunbar mailto:linda.dun...@futurewei.com>>; John E 
Drake 
mailto:40juniper@dmarc.ietf.org>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Aijun,

Such metric will be same(because of the ANYCAST address be advertised 
simultaneously via R1/R2/R3 at the same time for one application server, for 
example, S1/aa08::4450).

That is not really correct.

On each router R1 or R2 or R3 when you for example redistribute or originate in 
any other way host route for example S1/aa08::4450 you can apply a different 
metric to it.

That is why I keep asking what is the mechanism in which routers will be 
informed what host routes to advertise and what metric to use for each IP 
address of the server or application on the server. The most precise answer 
received so far was "it is out of scope". And that is important irrespective if 
we are talking about using passive interfaces, stub interfaces or simply static 
routes.

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Acee,

I am sorry for missing answering your question.

Aggregated site cost for a specific prefix is different than the base IGP cost 
for the following reasons:

  *   The aggregated site cost only applies to a specific topology. The policy 
is configured to the relevant nodes to take the aggregated site cost into 
consideration in computing the shortest path.
  *   As Muthu’s email stated that “The metric can be split into 'n' parts all 
internal to the specific application”. The aggregated site cost can be one 
value or a set of values.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCost Attribute-1 to the Prefix  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~   ~
|AggCost Attribute-i to the Prefix  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Aggregated cost Advertisement in OSPF


Your suggestions and comments are greatly appreciated.

Linda Dunbar

From: Acee Lindem (acee) 
Sent: Wednesday, January 19, 2022 7:18 AM
To: Linda Dunbar ; Robert Raszuk 
; Aijun Wang 
Cc: John E Drake ; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,

You seem to be either missing or avoiding my question as to why the base IGP 
metric can’t be used now that the draft has a single aggregated cost?

Aijun replied with two alternatives for changing it to allow for complex 
selection algorithm based on multiple metrics. What is the actual requirement 
here?

Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Tuesday, January 18, 2022 at 10:52 PM
To: Robert Raszuk mailto:rob...@raszuk.net>>, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem mailto:a...@cisco.com>>, John E Drake 
mailto:jdr...@juniper.net>>, "Les Ginsberg (ginsberg)" 
mailto:ginsb...@cisco.com>>, Gyan Mishra 
mailto:hayabusa...@gmail.com>>, lsr 
mailto:lsr@ietf.org>>
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can 
be a value configured on the router to which the prefix is attached. The 
aggregated site cost can be computed based on an algorithm configured on router 
for specific prefixes. The detailed algorithm of computing the aggregated site 
cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval 
for Metrics Change Advertisement which is configured on the routers to avoid 
route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes. The rate of change could be in weeks or days. On rare 
occasions, there might need rate changes in hours..”

Your comments and suggestions are greatly appreciated.

Linda

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>;
 Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Aijun,

Such metric will be same(because of the ANYCAST address be advertised 
simultaneously via R1/R2/R3 at the same time for one application server, for 
example, S1/aa08::4450).

That is not really correct.

On each router R1 or R2 or R3 when you for example redistribute or originate in 
any other way host route for example S1/aa08::4450 you can apply a different 
metric to it.

That is why I keep asking what is the mechanism in which routers will be 
informed what host routes to advertise and what metric to use for each IP 
address of the server or application on the server. The most precise answer 
received so far was "it is out of scope". And that is important irrespective if 
we are talking about using passive interfaces, stub interfaces or simply static 
routes.

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

In the new version of the draft, we have:
“The aggregated site cost associated with a prefix (i.e., ANYCAST prefix) can 
be a value configured on the router to which the prefix is attached. The 
aggregated site cost can be computed based on an algorithm configured on router 
for specific prefixes. The detailed algorithm of computing the aggregated site 
cost is out of the scope of document.
As the cost change can impact the path computation, there is a Minimum Interval 
for Metrics Change Advertisement which is configured on the routers to avoid 
route oscillations. Default is 30s.
The aggregated site cost change rate is comparable with the rate of adding or 
removing application instances at locations to adapt to the workload 
distribution changes. The rate of change could be in weeks or days. On rare 
occasions, there might need rate changes in hours..”

Your comments and suggestions are greatly appreciated.

Linda

From: Robert Raszuk 
Sent: Monday, January 17, 2022 5:29 AM
To: Aijun Wang 
Cc: Acee Lindem (acee) ; Linda Dunbar 
; John E Drake 
; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr 
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Aijun,

Such metric will be same(because of the ANYCAST address be advertised 
simultaneously via R1/R2/R3 at the same time for one application server, for 
example, S1/aa08::4450).

That is not really correct.

On each router R1 or R2 or R3 when you for example redistribute or originate in 
any other way host route for example S1/aa08::4450 you can apply a different 
metric to it.

That is why I keep asking what is the mechanism in which routers will be 
informed what host routes to advertise and what metric to use for each IP 
address of the server or application on the server. The most precise answer 
received so far was "it is out of scope". And that is important irrespective if 
we are talking about using passive interfaces, stub interfaces or simply static 
routes.

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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Acee, John, Robert, and LSR experts:

We have updated the draft to reflect the comments and suggestions on the LSR 
mailing list.  
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In particular:


  *   This draft describes using additional site costs to influence the 
shortest path computation for a specific set of prefixes. As there are a small 
number of egress routers having those prefixes (or destinations) that need to 
incorporate site costs in SPF computation, Flexible Algorithms [LSR-FlexAlgo] 
is used to indicate the need for the site costs to be considered for the 
specific topologies.

Need a Flag in the Flexible Algorithm TLV to indicate that "site-cost" needs to 
be included for the constrained SPF to reach the Prefix.
Therefore, it is not informational draft.

The "Site Cost" associated with a prefix (i.e., ANYCAST prefix) can be a value 
configured on the router to which the prefix is attached. The actual mechanism 
of assigning "Site Cost" or the detailed algorithm is out of the scope of 
document
The "site cost" change rate is comparable with the rate that the application 
controller adds or removes the application instances at locations to adjust the 
workload distribution. Typically, the rate of change could be in days. On rare 
occasions, there might need rate changes in hours.

We have added a section to emphasize that  It is important that the "site cost" 
metric doesn't change too frequently to avoid route oscillation within the 
network.

Thank you.

Linda

From: Acee Lindem (acee) 
Sent: Saturday, January 15, 2022 5:30 AM
To: Aijun Wang ; John E Drake 

Cc: Les Ginsberg (ginsberg) ; Linda Dunbar 
; Gyan Mishra ; Robert 
Raszuk ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Aijun, Linda,

Independent of the ongoing debate on whether advertising the server metrics in 
the IGPs...

Now that the draft is simplified to use a single aggregated metric, why not 
make the draft informational and use the base IGP metrics? This avoid the 
burden of adding a new flex algorithm.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Friday, January 14, 2022 at 10:38 PM
To: John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
Cc: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
Linda Dunbar mailto:linda.dun...@futurewei.com>>, 
Gyan Mishra mailto:hayabusa...@gmail.com>>, Robert 
Raszuk mailto:rob...@raszuk.net>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

This draft is now proposing one aggregate cost of the application server.

The detailed factors can also be included if necessary. But the principle for 
advertising them should be controllable, as required by other dynamic metrics 
in IGP.
Aijun Wang
China Telecom

On Jan 15, 2022, at 08:37, John E Drake 
mailto:jdrake=40juniper@dmarc.ietf.org>>
 wrote:
This is similar to the issue with the Down/Up proposal.  A single metric tells 
an ingress node nothing about the performance of or load on the individual 
applications at a given site.

Yours Irrespectively,

John



Juniper Business Use Only
From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Friday, January 14, 2022 6:58 PM
To: John E Drake mailto:jdr...@juniper.net>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

[External Email. Be cautious of content]

Hi, John:
Here I would also like to hear your own opinions. If not, please see my 
responses for both you and Robert:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-bw-con-01__%3B!!NEt6yMaO-gk!Ruow7KbUPIX1YVq2nIggRiIumNPiEf58LStjoh_L_UpLze1a2LwUW21ecs19GHc%24=04%7C01%7Clinda.dunbar%40futurewei.com%7C5ed0b71fabcb42630bdf08d9d81a6858%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637778430231799294%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=TVa27j%2Br9AIn3eD6puZdGPnTSDSqmlEOQ0NQUO0%2FGfc%3D=0>
 has introduced the "delay metric" into the IGP. Such metric may be variant in 
every link within the IGP.
The proposal in draft-dunbar-lsr-5g-edge-compute is only for the 
stub-link's/prefixes characteristics, it is the aggregate cost to the server 
that measured from the router.

All the fa

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

Egress routers can be assigned with a site preference index for a specific set 
of prefixes attached.

Linda

From: Robert Raszuk 
Sent: Thursday, January 13, 2022 11:27 AM
To: Linda Dunbar 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Linda,

Let me ask again ... How does ISIS process on the egress router learns the load 
of the "attached" load balancer ?

As far as your comment on using or not using anycast addresses I disagree, but 
we will not be spamming LSR WG list to discuss this further.

Thx a lot,
R.

On Thu, Jan 13, 2022 at 6:18 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

The draft is about distributing the Site Index and preferences of the Egress 
routers to which the application load balancers (or instances) are attached.

Thanks, Linda

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, January 13, 2022 10:52 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> and I agree that using the IGP/Flex Algo as you are proposing is a viable 
> solution.

Except that IGP usually does not run between application server and load 
balancer ...


On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Linda -

Are you saying that the scenario you are trying to address is to have a given 
"transaction" go to the currently closest/most lightly loaded Application 
Server?
And there is no intent to support for long lived connections?

If so, then this isn't really a load balancing issue and I agree that using the 
IGP/Flex Algo as you are proposing is a viable solution.
The concern then becomes the rate of updates to the new Prefix Metric. If this 
changes too rapidly this will heavily consume network resources by triggering 
flooding, SPF, forwarding plane updates at a high rate.
Can you put some language in the draft that indicates the expected rate of 
updates to the metric and some guidelines on limiting the frequency?

Thanx.

   Les


From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Thursday, January 13, 2022 7:58 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Robert,

For your scenario of TCP flows lasting more than 8~18 hours,  multiple server 
instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address).  
Each of those instances should have one distinct IP address.

The draft is for different scenario where application are instantiated at 
multiple locations behind multiple App Layer Load Balancers. They have relative 
short flows that can go to any App Layer Load Balancers. Multiple Load 
Balancers  for those applications are assigned with the same IP address. In 
Kubernetes, multiple load balancers for one type of microservices are assigned 
with one single Virtual IP address, so that the network can forward as one 
single destination.

Linda
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, January 13, 2022 9:37 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> Flows among micro-services are very short.

While that can be true - there is nowhere in the document a restriction or even 
a warning that this solution is aiming for short lived flows only and that 
users should be well aware about drastic nature of proposed mechanism to their 
established flows.

In one of the companies I worked for average  TCP flow duration was anywhere 
from 8-18 hours and it was a very drastic event for the user to loose it in the 
middle of the day.  Various means where taken and applied to protect such 
sessions from any form of disconnects.

I think we are shooting here with the wrong weapon to the target.

Thx,
R.

On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Your link to Traefik  adds more reasons why "Site index and preference" should 
be distributed by IGP:

  *   Site index and preferences for a cluster of micro-service instances are 
rarely dynamically changed. Most of those values are configured. Therefore, the 
oscillation is minimal.
  *   Flows among micro-services are very short. Put less requirements to f

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

The draft is about distributing the Site Index and preferences of the Egress 
routers to which the application load balancers (or instances) are attached.

Thanks, Linda

From: Robert Raszuk 
Sent: Thursday, January 13, 2022 10:52 AM
To: Les Ginsberg (ginsberg) 
Cc: Linda Dunbar ; Gyan Mishra 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> and I agree that using the IGP/Flex Algo as you are proposing is a viable 
> solution.

Except that IGP usually does not run between application server and load 
balancer ...


On Thu, Jan 13, 2022 at 5:37 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Linda -

Are you saying that the scenario you are trying to address is to have a given 
"transaction" go to the currently closest/most lightly loaded Application 
Server?
And there is no intent to support for long lived connections?

If so, then this isn't really a load balancing issue and I agree that using the 
IGP/Flex Algo as you are proposing is a viable solution.
The concern then becomes the rate of updates to the new Prefix Metric. If this 
changes too rapidly this will heavily consume network resources by triggering 
flooding, SPF, forwarding plane updates at a high rate.
Can you put some language in the draft that indicates the expected rate of 
updates to the metric and some guidelines on limiting the frequency?

Thanx.

   Les


From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Thursday, January 13, 2022 7:58 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Robert,

For your scenario of TCP flows lasting more than 8~18 hours,  multiple server 
instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address).  
Each of those instances should have one distinct IP address.

The draft is for different scenario where application are instantiated at 
multiple locations behind multiple App Layer Load Balancers. They have relative 
short flows that can go to any App Layer Load Balancers. Multiple Load 
Balancers  for those applications are assigned with the same IP address. In 
Kubernetes, multiple load balancers for one type of microservices are assigned 
with one single Virtual IP address, so that the network can forward as one 
single destination.

Linda
From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, January 13, 2022 9:37 AM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> Flows among micro-services are very short.

While that can be true - there is nowhere in the document a restriction or even 
a warning that this solution is aiming for short lived flows only and that 
users should be well aware about drastic nature of proposed mechanism to their 
established flows.

In one of the companies I worked for average  TCP flow duration was anywhere 
from 8-18 hours and it was a very drastic event for the user to loose it in the 
middle of the day.  Various means where taken and applied to protect such 
sessions from any form of disconnects.

I think we are shooting here with the wrong weapon to the target.

Thx,
R.

On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Your link to Traefik  adds more reasons why "Site index and preference" should 
be distributed by IGP:

  *   Site index and preferences for a cluster of micro-service instances are 
rarely dynamically changed. Most of those values are configured. Therefore, the 
oscillation is minimal.
  *   Flows among micro-services are very short. Put less requirements to flow 
affinity.
  *

Linda


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, January 13, 2022 5:00 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


And just to provide a sound alternative to the objective of this work.

Please consider using Traefik - 
https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cfbe3a5ade67347b9110608d9d6b50687%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776895275516159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=M0zh%2FGcSbGbsMSTtLumrJwqHpaLEeN2BNrAC

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

For your scenario of TCP flows lasting more than 8~18 hours,  multiple server 
instances SHOULDN'T be assigned with the SAME IP address (ANYCAST address).  
Each of those instances should have one distinct IP address.

The draft is for different scenario where application are instantiated at 
multiple locations behind multiple App Layer Load Balancers. They have relative 
short flows that can go to any App Layer Load Balancers. Multiple Load 
Balancers  for those applications are assigned with the same IP address. In 
Kubernetes, multiple load balancers for one type of microservices are assigned 
with one single Virtual IP address, so that the network can forward as one 
single destination.

Linda
From: Robert Raszuk 
Sent: Thursday, January 13, 2022 9:37 AM
To: Linda Dunbar 
Cc: Gyan Mishra ; Les Ginsberg (ginsberg) 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> Flows among micro-services are very short.

While that can be true - there is nowhere in the document a restriction or even 
a warning that this solution is aiming for short lived flows only and that 
users should be well aware about drastic nature of proposed mechanism to their 
established flows.

In one of the companies I worked for average  TCP flow duration was anywhere 
from 8-18 hours and it was a very drastic event for the user to loose it in the 
middle of the day.  Various means where taken and applied to protect such 
sessions from any form of disconnects.

I think we are shooting here with the wrong weapon to the target.

Thx,
R.

On Thu, Jan 13, 2022 at 4:23 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Your link to Traefik  adds more reasons why "Site index and preference" should 
be distributed by IGP:

  *   Site index and preferences for a cluster of micro-service instances are 
rarely dynamically changed. Most of those values are configured. Therefore, the 
oscillation is minimal.
  *   Flows among micro-services are very short. Put less requirements to flow 
affinity.
  *

Linda


From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Thursday, January 13, 2022 5:00 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


And just to provide a sound alternative to the objective of this work.

Please consider using Traefik - 
https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C4361a0b36c614fbf8e7908d9d6aa8b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776850245075888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=P%2BItvofz3%2Bgg0KEMdfxe9MluMPkQ2v1jL8a1Q50rddo%3D=0>

Thx,
R.


On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Gyan,

I see what the draft is trying to do now. /* I did not even consider this for 
the reason described below. */

But what you wrote requires little correction:

"So now the server you are on gets overloaded and a site cost gets advertised 
in the IGP at which point the connection receives a TCP reset"

if you s/connection/all connections/ then you quickly realize that what is 
proposed here is a disaster.

Breaking all existing flows going to one LB to suddenly timeout and all go to 
the other LB(s) is never a technique any one would seriously deploy in a 
production network.

Leave alone that doing that has potential to immediately overload the other 
LB(s)/server(s) too.

For me the conclusion is that IGP transport level is not the proper layer to 
address the requirement.

Cheers,
Robert.


On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

Hi Les

Agreed.

My thoughts are that the context of the draft is based on an Anycast VIP 
address of a server which is proximity based load balancing and not necessarily 
ECMP/UCMP and only if the proximity is the same for multiple paths to the 
Anycast VIP would there be a ECMP/UCMP possibility.

Let's say if it's proximity based and one path is preferred, the flow will take 
that path.  So now the server you are on gets overloaded and a site cost gets 
advertised in the IGP at which point the connection receives a TCP reset and 
flow re-establishes on the alternate path based on the site cost and remains 
there until the server goes down or  gets overloaded or a better path comes 
along.

For ECMP case, ECMP has flow affinity so the flow will stay on the same path 
long lived until the connection terminates.

So now in ECMP case the flow hashed to a path and maintains its affinity to 
that path.  Now all of sudden the server gets overloaded and we get a better 
site cos

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

Your link to Traefik  adds more reasons why "Site index and preference" should 
be distributed by IGP:

  *   Site index and preferences for a cluster of micro-service instances are 
rarely dynamically changed. Most of those values are configured. Therefore, the 
oscillation is minimal.
  *   Flows among micro-services are very short. Put less requirements to flow 
affinity.
  *

Linda


From: Robert Raszuk 
Sent: Thursday, January 13, 2022 5:00 AM
To: Gyan Mishra 
Cc: Les Ginsberg (ginsberg) ; Linda Dunbar 
; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


And just to provide a sound alternative to the objective of this work.

Please consider using Traefik - 
https://traefik.io/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftraefik.io%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb7985d17f6cf4691516c08d9d683cb4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637776683827234342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=DTSgF4GOdBXmJmF18s%2BhPYpod1g2wul6z%2BY6Gi6a%2F14%3D=0>

Thx,
R.


On Thu, Jan 13, 2022 at 11:56 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Gyan,

I see what the draft is trying to do now. /* I did not even consider this for 
the reason described below. */

But what you wrote requires little correction:

"So now the server you are on gets overloaded and a site cost gets advertised 
in the IGP at which point the connection receives a TCP reset"

if you s/connection/all connections/ then you quickly realize that what is 
proposed here is a disaster.

Breaking all existing flows going to one LB to suddenly timeout and all go to 
the other LB(s) is never a technique any one would seriously deploy in a 
production network.

Leave alone that doing that has potential to immediately overload the other 
LB(s)/server(s) too.

For me the conclusion is that IGP transport level is not the proper layer to 
address the requirement.

Cheers,
Robert.


On Thu, Jan 13, 2022 at 7:05 AM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

Hi Les

Agreed.

My thoughts are that the context of the draft is based on an Anycast VIP 
address of a server which is proximity based load balancing and not necessarily 
ECMP/UCMP and only if the proximity is the same for multiple paths to the 
Anycast VIP would there be a ECMP/UCMP possibility.

Let's say if it's proximity based and one path is preferred, the flow will take 
that path.  So now the server you are on gets overloaded and a site cost gets 
advertised in the IGP at which point the connection receives a TCP reset and 
flow re-establishes on the alternate path based on the site cost and remains 
there until the server goes down or  gets overloaded or a better path comes 
along.

For ECMP case, ECMP has flow affinity so the flow will stay on the same path 
long lived until the connection terminates.

So now in ECMP case the flow hashed to a path and maintains its affinity to 
that path.  Now all of sudden the server gets overloaded and we get a better 
site cost advertised.  So now the session terminates on current path and 
establishes again on the Anycast VIP new path based on the site cost advertised.

The failover I believe results in the user refreshing their browser which is 
better than hanging.

As the VIP prefix is the only one that experiences reconvergence on new path 
based on site cost if there is any instability with the servers that will be 
reflected to the IGP Anycast prefix as well.

Is that a good or bad thing.  I think if you had to pick your poison as here 
the issue Linda is trying to solve is a server issue but leveraging the IGP to 
force re-convergence when the server is in a half baked state meaning it's busy 
and connections are being dropped or very slow QOE for end user.  If you did 
nothing and let it ride the the user would be stuck on a bad connection.

So this solution dynamically fixed the issue.

As far as oscillation that is not a big deal as you are in a much worse off 
state connected to a dying server on its last leg as far as memory and CPU.

This solution I can see can apply to any client / server connection and not 
just 5G and can be used by enterprises as well as SP for their customers to 
have an drastically improved QOE.

I saw some feedback on the TLV and I think once that is all worked out I am in 
favor of advancing this draft.

Kind Regards

Gyan


On Wed, Jan 12, 2022 at 10:16 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Gyan -

The difference between ECMP and UCMP is not significant in this discussion.
I don't want to speak for Robert, but for me his point was that IGPs can do 
"multipath" well - but this does not translate into managing flows.
Please see my other responses on this thread.

Thanx.

Les


From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Wednesday, January 12, 2022 

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Still use the Dijkstra shortest path algorithm. Just the cost to the 
destination includes more than the routing hops.

Linda

From: Robert Raszuk 
Sent: Wednesday, January 12, 2022 2:39 PM
To: Linda Dunbar 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute


> IGP cost typically is determined by comparing the preference, then the weight,
> then the metric, and finally the metric2 of the two resolving routes.

Are we sure we are on the same page here ?

Are you describing some new yet to be defined algorithm or Dijkstra ?

Thx,
R.

On Wed, Jan 12, 2022 at 9:36 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

IGP cost typically is determined by comparing the preference, then the weight, 
then the metric, and finally the metric2 of the two resolving routes.
The draft is to add another site-cost metric to the IGP computation.
Using MPLS is too heavy.

Linda

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, January 12, 2022 1:23 PM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Linda,

> IGP has been used for the Multi-path computation for a long time

IGP can and does ECMP well. Moreover, injecting metric of anycast server 
destination plays no role in it as all paths would inherit that external to the 
IGP cost.

Unequal cost load balancing or intelligent traffic spread has always been done 
at the application layer *for example MPLS*

Thx a lot,
R.

On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Please see inline in green:

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,


[LES:] It is my opinion that what you propose will not achieve your goals – in 
part because IGPs only influence forwarding on a per packet basis – not a per 
flow/connection basis.

[Linda] Most vendors do support flow based ECMP, with Shortest Path computed by 
attributes advertised by IGP.

I am with Les here. ECMP has nothing to do with his point.

[Linda] Les said that “IGP only influence forwarding on a per packet basis”.  I 
am saying that vendors supporting “forwarding per flow” with equal cost 
computed by IGP implies  that forwarding on modern routers are no longer purely 
per packet basis.


Draft says:

When those multiple server instances share one IP address (ANYCAST), the 
transient network and load conditions can be incorporated in selecting an 
optimal path among server instances for UEs.

So if we apply any new metric to indicate load of a single anycast address how 
is this going to help anything ?

[Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths 
with the same routing distance.


You would need a mechanism where the network is smart and say per src-dst tuple 
or more spreads the traffic. IGP does not play that game today I am afraid.
[Linda] There is one SRC and multiple paths to one DST. IGP has been used for 
the Multi-path computation for a long time.

Thank you, Linda

Thx a lot,
R.







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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

IGP cost typically is determined by comparing the preference, then the weight, 
then the metric, and finally the metric2 of the two resolving routes.
The draft is to add another site-cost metric to the IGP computation.
Using MPLS is too heavy.

Linda

From: Robert Raszuk 
Sent: Wednesday, January 12, 2022 1:23 PM
To: Linda Dunbar 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Linda,

> IGP has been used for the Multi-path computation for a long time

IGP can and does ECMP well. Moreover, injecting metric of anycast server 
destination plays no role in it as all paths would inherit that external to the 
IGP cost.

Unequal cost load balancing or intelligent traffic spread has always been done 
at the application layer *for example MPLS*

Thx a lot,
R.

On Wed, Jan 12, 2022 at 8:18 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Robert,

Please see inline in green:

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar mailto:linda.dun...@futurewei.com>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,


[LES:] It is my opinion that what you propose will not achieve your goals – in 
part because IGPs only influence forwarding on a per packet basis – not a per 
flow/connection basis.

[Linda] Most vendors do support flow based ECMP, with Shortest Path computed by 
attributes advertised by IGP.

I am with Les here. ECMP has nothing to do with his point.

[Linda] Les said that “IGP only influence forwarding on a per packet basis”.  I 
am saying that vendors supporting “forwarding per flow” with equal cost 
computed by IGP implies  that forwarding on modern routers are no longer purely 
per packet basis.


Draft says:

When those multiple server instances share one IP address (ANYCAST), the 
transient network and load conditions can be incorporated in selecting an 
optimal path among server instances for UEs.

So if we apply any new metric to indicate load of a single anycast address how 
is this going to help anything ?

[Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths 
with the same routing distance.


You would need a mechanism where the network is smart and say per src-dst tuple 
or more spreads the traffic. IGP does not play that game today I am afraid.
[Linda] There is one SRC and multiple paths to one DST. IGP has been used for 
the Multi-path computation for a long time.

Thank you, Linda

Thx a lot,
R.







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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Robert,

Please see inline in green:

From: Robert Raszuk 
Sent: Wednesday, January 12, 2022 1:00 PM
To: Linda Dunbar 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] Seeking feedback to the revised 
draft-dunbar-lsr-5g-edge-compute

Hi Linda,


[LES:] It is my opinion that what you propose will not achieve your goals – in 
part because IGPs only influence forwarding on a per packet basis – not a per 
flow/connection basis.

[Linda] Most vendors do support flow based ECMP, with Shortest Path computed by 
attributes advertised by IGP.

I am with Les here. ECMP has nothing to do with his point.

[Linda] Les said that “IGP only influence forwarding on a per packet basis”.  I 
am saying that vendors supporting “forwarding per flow” with equal cost 
computed by IGP implies  that forwarding on modern routers are no longer purely 
per packet basis.


Draft says:

When those multiple server instances share one IP address (ANYCAST), the 
transient network and load conditions can be incorporated in selecting an 
optimal path among server instances for UEs.

So if we apply any new metric to indicate load of a single anycast address how 
is this going to help anything ?

[Linda] The “Load” or “Aggregated Site Cost” is to differentiate multiple paths 
with the same routing distance.


You would need a mechanism where the network is smart and say per src-dst tuple 
or more spreads the traffic. IGP does not play that game today I am afraid.
[Linda] There is one SRC and multiple paths to one DST. IGP has been used for 
the Multi-path computation for a long time.

Thank you, Linda

Thx a lot,
R.







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

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Les,

Please see my questions to your suggestions inserted below:

Linda

From: Les Ginsberg (ginsberg) 
Sent: Wednesday, January 12, 2022 11:21 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

Please see inline.

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Wednesday, January 12, 2022 8:41 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

With regard to what You said about “needing to do load balancing at the 
Application Layer – not at Layer 3”:

Answer: Most deployments could have 10s, 100s, or even thousands of Application 
Layer load balancers. The proposed solution is to utilize network layer and 
resource capability information to balance the distribution of traffic among 
the Application Load balancers. The documents stated that the distribution 
behind the load balancers are out of the scope.


With regard to what you said about “oscillation”:

Answer: The rate of capability index changes is in terms of hours or days, more 
like the link failure that IGP is intended to distribute. Therefore, the 
oscillation is not the issue.



[LES:] It is my opinion that what you propose will not achieve your goals – in 
part because IGPs only influence forwarding on a per packet basis – not a per 
flow/connection basis.

[Linda] Most vendors do support flow based ECMP, with Shortest Path computed by 
attributes advertised by IGP.



I also don’t understand why you mention “link failure” when the discussion here 
is about load balancing across multiple Application Servers even when the 
underlying network is stable.

[Linda] I meant to say topology changes caused by “Link failure” or others.



With regard to what you said about “incorrect TLV”

Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; 
and TLV 135 is for Extended IP reachability.
Do you mean another TLV should be used instead of TLV 128/130/135?
[LES:] You cannot put sub-TLVs into TLVs 128/130. These TLVs are “old style” 
TLVs which do not support sub-TLVs of any kind.
The following TLVs would be relevant:
Extended IP reachability (135)
MT IP Reach (235)
IPv6 IP Reach (236)
MT IPv6 IP Reach (237)
[Linda] Thank you for the suggestion. Are Extended IP reachability (135) and MT 
IP Reachability (235) equally good?

Please see 
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability

Thank you.

Linda

For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to 
be consistent with OSPF:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  AggCost to the App Server|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Aggregated cost Advertisement in IS-IS


[LES:] Great – thanx.

   Les

Any other issues?

Linda

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, January 11, 2022 11:14 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda -

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances 
instantiated at multiple locations is like having multiple Egress routers 
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

[LES:] What I am saying is that you need to do load balancing at the 
Application Layer – not at Layer 3.
IGPs can provide you with paths to the set of Application servers that share 
the same anycast address – but dynamically manipulating the IGP metrics (even 
this new metric you propose) – will give you oscillation – not application 
server load 

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Les,

With regard to what You said about “needing to do load balancing at the 
Application Layer – not at Layer 3”:

Answer: Most deployments could have 10s, 100s, or even thousands of Application 
Layer load balancers. The proposed solution is to utilize network layer and 
resource capability information to balance the distribution of traffic among 
the Application Load balancers. The documents stated that the distribution 
behind the load balancers are out of the scope.


With regard to what you said about “oscillation”:

Answer: The rate of capability index changes is in terms of hours or days, more 
like the link failure that IGP is intended to distribute. Therefore, the 
oscillation is not the issue.



With regard to what you said about “incorrect TLV”

Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address; 
and TLV 135 is for Extended IP reachability.
Do you mean another TLV should be used instead of TLV 128/130/135?

For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to 
be consistent with OSPF:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  AggCost to the App Server|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Aggregated cost Advertisement in IS-IS



Any other issues?

Linda

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, January 11, 2022 11:14 PM
To: Linda Dunbar ; lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda -

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances 
instantiated at multiple locations is like having multiple Egress routers 
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

[LES:] What I am saying is that you need to do load balancing at the 
Application Layer – not at Layer 3.
IGPs can provide you with paths to the set of Application servers that share 
the same anycast address – but dynamically manipulating the IGP metrics (even 
this new metric you propose) – will give you oscillation – not application 
server load balancing.


Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the 
Egress router) is suggested by Peter Psenak (through the offline discussion 
prior to the IETF 112, see the attached email thread)

There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

Why do you say it is a “mess”?   I felt your words are more like personal 
attack than giving a constructive suggestion.

[LES:] Apologies if you were offended – I did put a smiley in to try give it a 
light touch – but I should know better than to be so flippant in this context.
My point is that in what is indeed a very small section there are multiple 
errors:


  *   The TLVs mentioned are not correct
  *   The diagram with the proposed sub-TLV encoding incorrectly includes the 
prefix. The prefix is already present in the parent TLV – it should not be 
present in the sub-TLV. You have this correct in Section 5 for OSPF.

But these points can be ignored because I believe using the IGPs isn’t the 
right solution and so we won’t need these new sub-TLVs anyway.

I don’t know what comment from Peter you are referring to – but if he mentioned 
TLVs 128/130 I will take that up with him – he knows better. 
I do recall that in an earlier version of the draft you were proposing to 
advertise the new metric as part of a link advertisement (TLV 22) – and he was 
quite correct in directing you to use Prefix Reachability advertisements (like 
TLV 135).

But please focus on looking at a non-IGP solution – that is what you need to do 
IMO.

   Les




Linda



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar 
mailto:linda.dun.

Re: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Les,

Starting with a clean slate:

Problem:
Most applications are instantiated at multiple locations to achieve optimal 
performance. Traditional shortest path to reach one single destination is 
making load balancers the bottleneck, or pushing the traffic management 
responsibility to DNS.

From Underlay IP network perspective, connecting applications with instances 
instantiated at multiple locations is like having multiple Egress routers 
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which 
corresponds to egress ER1, ER2, ER3 respectively,  the Shortest Path 
Computation need to include both routing distance and the resources attached to 
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should 
include both the routing distances and the resource cost.

Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the 
Egress router) is suggested by Peter Psenak (through the offline discussion 
prior to the IETF 112, see the attached email thread)

There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”

Why do you say it is a “mess”?   I felt your words are more like personal 
attack than giving a constructive suggestion.

Linda



From: Les Ginsberg (ginsberg) 
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

Linda –

I believe the most valuable feedback you received during your presentation at 
IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application 
server is likely a requirement which will not be achieved using an IGP based 
solution.
Also, the modification of IGP metrics will likely introduce unwanted 
oscillation in traffic flows.

I suggest you start with a clean slate – focus on defining what all the 
requirements are without regard to what mechanism/protocol might be used – and 
then think about defining a solution which meets these requirements.
I think you will end up NOT using routing protocols at all.

On a more mundane note, the section describing the new IS-IS advertisement 
(https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265066903950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ZJY0ugnVuhUmc6o%2Bje2FDhnAcSo2tvhxYn4c3YFxcFM%3D=0>
 ) is – to put it bluntly – a mess! 
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not 
be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV 
when it should not. The prefix has already been advertised in the parent TLV.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd99499e3006a4a3d4f5808d9d450a22a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637774265067060188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=GXrGqw4CNac27y1cIY9dC68j3%2FKx1x5kCzPtoPMCUUs%3D=0>

In a nutshell, the proposed solution

  *   advertises the “Site-Cost” via IP prefix reachability TLV associated with 
the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) 
server (i.e., ANYCAST prefix), computed based on the IP layer related metrics 
for the prefix, such as Load Measurement, the Capacity Index, the Preference 
Index, and other constraints by a consistent algorithm across all egress 
routers to which the EC servers are attached.


  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  “site-cost” 
needs to be included for the constrained SPF to reach the Prefix


Any feedbacks? Or suggestions?

Thank you very much
Linda
--- Begin Message ---
Linda,

On 09/11/2021 18:09, Linda Dunbar wrote:
> Peter,
> You suggested creating a new sub-TLV for E-Intra-Area-Prefix-LSA, 
> E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-Type-7-LSA [RFC8362].
> But if we use the original Intra/Inter-area

[Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

LSR experts,

We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments 
and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the proposed solution

  *   advertises the "Site-Cost" via IP prefix reachability TLV associated with 
the (anycast) prefix
The  Site-Cost is the aggregated cost associated with an Edge Compute (EC) 
server (i.e., ANYCAST prefix), computed based on the IP layer related metrics 
for the prefix, such as Load Measurement, the Capacity Index, the Preference 
Index, and other constraints by a consistent algorithm across all egress 
routers to which the EC servers are attached.


  *   Uses a Flag in the Flexible Algorithm TLV to indicate that  "site-cost" 
needs to be included for the constrained SPF to reach the Prefix


Any feedbacks? Or suggestions?

Thank you very much
Linda
___
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

[Linda Dunbar]

Hi Everyone,

I read the draft and support its adoption.

Best Regards,
Linda Dunbar


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Christian Hopps mailto:cho...@chopps.org>>
Sent: Tuesday, January 4, 2022 1:58 AM
To: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>; 
lsr-...@ietf.org<mailto:lsr-...@ietf.org> 
mailto:lsr-...@ietf.org>>; 
cho...@chopps.org<mailto:cho...@chopps.org> 
mailto:cho...@chopps.org>>; 
draft-wang-lsr-stub-link-attribu...@ietf.org<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org>
 
mailto: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=uJHx3Vve%2F39dWPFLWX2Yf0TpM05Y0ltWtZhcH3UrHno%3D=0>

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<mailto:Lsr@ietf.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3Dreserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ldoBe47FMYzIx4Nrti%2FnNpiL3ZoXSGC0yv7NsVVq4rI%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments about draft-dunbar-lsr-5g-edge-compute, -idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service

[Linda Dunbar]

Forget to mention:

The local DNS to schedule traffic from different ingress routers to different 
Load Balancers can become a bottleneck if network condition is not leveraged.


Linda

_
From: Linda Dunbar
Sent: Thursday, November 11, 2021 9:18 AM
To: Jeffrey (Zhaohui) Zhang ; lsr@ietf.org; 'IPv6 List' 
; 'idr@ietf. org' 
Subject: RE: Comments about draft-dunbar-lsr-5g-edge-compute, 
-idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service


Jeffrey,

You are not alone in thinking the problem is best solved at "app layer". My 
sister working for Cloud Operator's Layer4 & Layer 7 Load balancer division 
debated with me all the time.

 They can:
- deploy many load balancers, each managing traffic among many active servers.
- local DNS to schedule traffic from different ingress routers to different 
Load Balancers

As pointed in this NANOG presentation: 
https://pc.nanog.org/static/published/meetings/NANOG77/2082/20191030_Wang_An_Architecture_Of_v1.pdf

 << OLE Object: Picture (Device Independent Bitmap) >>
Leveraging the network condition to optimize traffic can solve those issues.

>From the forwarding perspective, it is same as introducing TE metrics into 
>Path computation. When TE metrics, bandwidth, etc. change, the path change 
>accordingly.

Linda Dunbar

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: Thursday, November 11, 2021 8:08 AM
To: Linda Dunbar ; lsr@ietf.org; 'IPv6 List' 
; 'idr@ietf. org' 
Subject: Comments about draft-dunbar-lsr-5g-edge-compute, 
-idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service

Hi,

I did not have time to comment during today's LSR session so I am bringing this 
to the list. I am also adding IDR and 6man lists because all these three drafts 
are about the same use case.

There were a long email discussion on the 6man draft here: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fipv6%2F4rw-pBcNZN7mzkArjUtVUzLcQJU%2Fdata=04%7C01%7Clinda.dunbar%40futurewei.com%7C36cfe5852ea24a8f730108d9a51ca3bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722364713687643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ILSLOrYcIROMHb%2FxCI2AqMHm%2FAHQA6BXGoJvArZaj30%3Dreserved=0
 back in March.

There are basically two problems here:

1. which server to pick
2. how to stick to the same server when a UE (mobile device) moves

The long discussion on the 6man list is mainly focused on #2. I don't know if 
we can say there was a conclusion, but some people (me included) believe that 
both problems are best solved at "app layer" instead of routing layer - just 
put a load balancer next to the 5G UPF.

Jeffrey

-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, March 25, 2021 3:46 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Kaippallimalil 
John 
mailto:john.kaippallima...@futurewei.com>>; 
IPv6 List mailto:i...@ietf.org>>; idr@ietf. org 
mailto:i...@ietf.org>>
Subject: questions about draft-dunbar-idr-5g-edge-compute-app-meta-data and 
draft-dunbar-6man-5g-edge-compute-sticky-service

Hi Linda, John,

I have the following questions.

The two related drafts listed the following three problems respectively:

  1.3. Problem#1: ANYCAST in 5G EC Environment.. 6
  1.4. Problem #2: Unbalanced Anycast Distribution due to UE 
Mobility.. 7
  1.5. Problem 3: Application Server Relocation. 7

  1.2. Problem #1: ANYCAST in 5G EC Environment.. 4
  1.3. Problem #2: sticking to original App Server... 5
  1.4. Problem #3: Application Server Relocation. 5

Why is problem #2 different in the two drafts? Is it true that none of the two 
drafts address problem #3?
The idr draft talk about "soft anchoring" problem and solution - how is that 
different from the "sticky service"?

Thanks.
Jeffrey

Juniper Business Use Only

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

Re: [Lsr] Comments about draft-dunbar-lsr-5g-edge-compute, -idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service

[Linda Dunbar]

Jeffrey,

You are not alone in thinking the problem is best solved at "app layer". My 
sister working for Cloud Operator's Layer4 & Layer 7 Load balancer division 
debated with me all the time.

 They can:
- deploy many load balancers, each managing traffic among many active servers.
- local DNS to schedule traffic from different ingress routers to different 
Load Balancers

As pointed in this NANOG presentation: 
https://pc.nanog.org/static/published/meetings/NANOG77/2082/20191030_Wang_An_Architecture_Of_v1.pdf


Leveraging the network condition to optimize traffic can solve those issues.

>From the forwarding perspective, it is same as introducing TE metrics into 
>Path computation. When TE metrics, bandwidth, etc. change, the path change 
>accordingly.

Linda Dunbar

-Original Message-
From: Jeffrey (Zhaohui) Zhang 
Sent: Thursday, November 11, 2021 8:08 AM
To: Linda Dunbar ; lsr@ietf.org; 'IPv6 List' 
; 'idr@ietf. org' 
Subject: Comments about draft-dunbar-lsr-5g-edge-compute, 
-idr-5g-edge-compute-app-meta-data and -6man-5g-edge-compute-sticky-service

Hi,

I did not have time to comment during today's LSR session so I am bringing this 
to the list. I am also adding IDR and 6man lists because all these three drafts 
are about the same use case.

There were a long email discussion on the 6man draft here: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fipv6%2F4rw-pBcNZN7mzkArjUtVUzLcQJU%2Fdata=04%7C01%7Clinda.dunbar%40futurewei.com%7C36cfe5852ea24a8f730108d9a51ca3bf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722364713687643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ILSLOrYcIROMHb%2FxCI2AqMHm%2FAHQA6BXGoJvArZaj30%3Dreserved=0
 back in March.

There are basically two problems here:

1. which server to pick
2. how to stick to the same server when a UE (mobile device) moves

The long discussion on the 6man list is mainly focused on #2. I don't know if 
we can say there was a conclusion, but some people (me included) believe that 
both problems are best solved at "app layer" instead of routing layer - just 
put a load balancer next to the 5G UPF.

Jeffrey

-Original Message-
From: Jeffrey (Zhaohui) Zhang
Sent: Thursday, March 25, 2021 3:46 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Kaippallimalil 
John 
mailto:john.kaippallima...@futurewei.com>>; 
IPv6 List mailto:i...@ietf.org>>; idr@ietf. org 
mailto:i...@ietf.org>>
Subject: questions about draft-dunbar-idr-5g-edge-compute-app-meta-data and 
draft-dunbar-6man-5g-edge-compute-sticky-service

Hi Linda, John,

I have the following questions.

The two related drafts listed the following three problems respectively:

  1.3. Problem#1: ANYCAST in 5G EC Environment.. 6
  1.4. Problem #2: Unbalanced Anycast Distribution due to UE 
Mobility.. 7
  1.5. Problem 3: Application Server Relocation. 7

  1.2. Problem #1: ANYCAST in 5G EC Environment.. 4
  1.3. Problem #2: sticking to original App Server... 5
  1.4. Problem #3: Application Server Relocation. 5

Why is problem #2 different in the two drafts? Is it true that none of the two 
drafts address problem #3?
The idr draft talk about "soft anchoring" problem and solution - how is that 
different from the "sticky service"?

Thanks.
Jeffrey

Juniper Business Use Only

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

[Lsr] Oscillation caused by the "site-cost" associated with a Prefix (ANYCAST) in draft-dunbar-lsr-5g-edge-compute

[Linda Dunbar]

Since we didn't have enough time at today's LSR session, I want to continue the 
discussion of draft-dunbar-lsr-5g-edge-compute on the mailing list:


  *   Shraddha pointed out that advertising the "site aggregated cost" of a 
Prefix (ANYCAST) might cause oscillation of traffic flow as other egress 
routers with the same prefix attached can advertise different metric to cause 
the change of the path computation.



OSPF-TE has the  same problem, does it? Link Bandwidth or condition changes 
advertisement can cause IGP path change?



>From each node's perspective, there has be a timer to adjust the IGP path 
>change with newly received "site-cost" metrics.

In addition, "Site-Cost" associated with the prefix is only considered in 
computing the IGP path when the Flag in the FlexAlgo TLV is set to indicate the 
need to include the "site-cost" metrics.



  *   draft-dunbar-lsr-5g-edge-compute is using 
E-intra-Area-Prefix-LSA[RFC7684]  and Prefix Reachability TLV to advertise the  
"Site-Cost" associated with the prefix.  At today's session, I heard that the 
"Stub Link" can be used as well. Want to hear WG opinion on which one is more 
suitable?

One more point, the "Site-Cost" associated with a prefix is not only intended 
as Tiebreaker. When the  Flag in the FlexAlgo TLV is set to indicate the need 
to include the "site-cost" metrics, the path computation will include the value 
in the SPF computation.


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

Re: [Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

Peter,

Is the following the correct summary of what you said?

  - the egress edge router (A-ER) with the EC Servers directly attached can 
advertise the "Site-Cost" via IP prefix reachability TLV associated with the 
(anycast) prefix
  -  using Flexible algorithms to advertise the desired constrained SPF 
computation methods, so that constrained IGP path can be computed as desired.


Thank you,

Linda
-Original Message-
From: Peter Psenak 
Sent: Friday, November 5, 2021 10:49 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: Re: Question about how topology is calculated ( was RE: [Lsr] Looking 
for feedback of using Flex Algo to advertise the 5G edge computing associated 
metrics

Linda,

On 05/11/2021 16:36, Linda Dunbar wrote:
> Peter,
> You said
> " The flex-algo is a combination of (a)-Calc-Type, (b)-Metric-Type,
> and (c)-constraint"
> Does it mean that "Flex-Algorithm" value of the Flex-Algo Definition
> Sub-TLV is to indicate the combination of (a), (b), (c)?

yes, each flex-algo number represents a specific combination of (a), (b), and 
(c), as defined by the user.

> Is the "(c) -constraint" carried in the sub-TLVs of the FAD TLV, such
> as the "FAD Flags Sub-TLV"  ?

yes (c) is advertised in FAD.

thanks,
Peter

> Thank you,
> Linda
> -Original Message-
> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Friday, November 5, 2021 4:43 AM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; 
> lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: Re: Question about how topology is calculated ( was RE: [Lsr]
> Looking for feedback of using Flex Algo to advertise the 5G edge
> computing associated metrics Linda, On 05/11/2021 00:20, Linda Dunbar
> wrote:
>> Peter,
>> You said:
>> /calculation type refers to how topology is calculated, / I thought
>> that the Flexible Algorithm Exclude/Include Admin Group Sub-TLV is to
>> indicate if a link belongs to a specific topology. Is my
>> understanding correct?
>> By indicating "Exclude/Include" bunch of links for a Calc-Type, does
>> it practically specify the topology?
> that's not how the flex-algorithm is defined.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-18%23section-
> 4data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cc14fae9bf42e4fc2a1
> 6408d9a073bf22%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6377172412
> 70768557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=naTIhgLANNDBD5BEgnjWQhG
> o8NcXDV8MISqoq99igFE%3Dreserved=0
> "To provide maximum flexibility, we want to provide a mechanism
> that
>  allows a router to (a) identify a particular calculation-type,
> (b)
>  metric-type, (c) describe a particular set of constraints, and
> (d)
>  assign a numeric identifier, referred to as Flex-Algorithm, to
> the
>  combination of that calculation-type, metric-type, and those
>  constraints.  We want the mapping between the Flex-Algorithm and
> its
>  meaning to be flexible and defined by the user.
> The flex-algo is a combination of (a), (b), and (c).
> You are trying to define (a) that would have (b) and (c) hardcoded.
> That does not follow the defined architecture.
> thanks,
> Peter
>> Thank you, Linda
>> -Original Message-
>> From: Peter Psenak > <mailto:ppse...@cisco.com<mailto:ppse...@cisco.com%20<mailto:ppse...@cisco.com>>>
>> Sent: Thursday, November 4, 2021 1:16 PM
>> To: Linda Dunbar > <mailto:linda.dun...@futurewei.com>>;
> lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org>
>> Subject: Re: Question about the FAD Flags Sub-TLV ( was RE: [Lsr]
>> Looking for feedback of using Flex Algo to advertise the 5G edge
>> computing associated metrics Linda, please see inline:
>> On 04/11/2021 18:17, Linda Dunbar wrote:
>>> Peter,
>>> Thank you very much for the valuable feedback.  We will move the
>>> content from Section 1, 2, 3 to an appendix per your suggestion.
>>> As for defining a new value in the Flexible Algorithm Definition
>>> Flags Sub-TLV, why can't we use the Metric-Type & Calc-Type to
>>> represent the information carried by the FAD Flags Sub-TLV?
>> because the Metric-Type in flex-algo is referring to link metrics,
>> not to prefix metrics. And Calc-Type you still wan to use SPF, don't you?
>>> draft-dunbar-lsr-5g-edge-compute-01 suggests to add a new value to
>>> the "Metric-Type" to indicate the Aggregated Cost AppMetaData
>>> Metrics included in computing the c

Re: [Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

Peter,

You said
  " The flex-algo is a combination of (a)-Calc-Type, (b)-Metric-Type, and 
(c)-constraint"

Does it mean that "Flex-Algorithm" value of the Flex-Algo Definition Sub-TLV is 
to indicate the combination of (a), (b), (c)?

Is the "(c) -constraint" carried in the sub-TLVs of the FAD TLV,  such as the 
"FAD Flags Sub-TLV"  ?

Thank you,

Linda

-Original Message-
From: Peter Psenak 
Sent: Friday, November 5, 2021 4:43 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: Re: Question about how topology is calculated ( was RE: [Lsr] Looking 
for feedback of using Flex Algo to advertise the 5G edge computing associated 
metrics

Linda,

On 05/11/2021 00:20, Linda Dunbar wrote:
> Peter,
> You said:
> /calculation type refers to how topology is calculated, / I thought
> that the Flexible Algorithm Exclude/Include Admin Group Sub-TLV is to
> indicate if a link belongs to a specific topology. Is my understanding
> correct?
> By indicating "Exclude/Include" bunch of links for a Calc-Type, does
> it practically specify the topology?

that's not how the flex-algorithm is defined.


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-flex-algo-18%23section-4data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cb88dcb6627dd45adf57a08d9a040a148%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637717021742366778%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LUCj3PAiP1EyWSdrHpDyBOelxKNrAvoknr6l2Wjw6Go%3Dreserved=0

   "To provide maximum flexibility, we want to provide a mechanism that
allows a router to (a) identify a particular calculation-type, (b)
metric-type, (c) describe a particular set of constraints, and (d)
assign a numeric identifier, referred to as Flex-Algorithm, to the
combination of that calculation-type, metric-type, and those
constraints.  We want the mapping between the Flex-Algorithm and its
meaning to be flexible and defined by the user.


The flex-algo is a combination of (a), (b), and (c).

You are trying to define (a) that would have (b) and (c) hardcoded. That does 
not follow the defined architecture.

thanks,
Peter

> Thank you, Linda
> -Original Message-
> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Thursday, November 4, 2021 1:16 PM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; 
> lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: Re: Question about the FAD Flags Sub-TLV ( was RE: [Lsr]
> Looking for feedback of using Flex Algo to advertise the 5G edge
> computing associated metrics Linda, please see inline:
> On 04/11/2021 18:17, Linda Dunbar wrote:
>> Peter,
>> Thank you very much for the valuable feedback.  We will move the
>> content from Section 1, 2, 3 to an appendix per your suggestion.
>> As for defining a new value in the Flexible Algorithm Definition
>> Flags Sub-TLV, why can't we use the Metric-Type & Calc-Type to
>> represent the information carried by the FAD Flags Sub-TLV?
> because the Metric-Type in flex-algo is referring to link metrics, not
> to prefix metrics. And Calc-Type you still wan to use SPF, don't you?
>> draft-dunbar-lsr-5g-edge-compute-01 suggests to add a new value to
>> the "Metric-Type" to indicate the Aggregated Cost AppMetaData Metrics
>> included in computing the constrained SPF.
>> Is it reasonable to use Calc-Type to indicate the options you mentioned?
> no, calculation type refers to how topology is calculated, not
> how/which prefix metrics is used.
> thanks,
> Peter
>> For example:
>>
>>   * Calc-Type-v1: replace the regular prefix metric,
>>   * Calc-Type-v2: the newly added metric is added on top,
>>   * Calc-Type-v3: only used as tiebreaker,
>>   * Calc-Type-v4: use the default prefix metric when the AppMetaData
>> Metrics is not present.  When AppMeteData metrics is not present,
>> the prefix is considered normal that doesn't need special
>>constraint
>> SPF computation.
>>   * Calc-Type-v5: no transit across areas/domains
>>   * Calc-Type-v6: transit across areas/domains.
>>
>> Thank you,
>> Linda
>> -Original Message-
>> From: Peter Psenak > <mailto:ppse...@cisco.com<mailto:ppse...@cisco.com%20<mailto:ppse...@cisco.com>>>
>> Sent: Wednesday, November 3, 2021 7:43 AM
>> To: Linda Dunbar > <mailto:linda.dun...@futurewei.com>>;
> lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org>
>> Subject: Re: [Lsr] Looking for feedback of using Flex Algo to
>> advertise the 5G edge computing associated metrics Hi Linda, I went
>> through your document and here are my commen

[Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

Peter,

You said:
  calculation type refers to how topology is calculated,

I thought that the Flexible Algorithm Exclude/Include Admin Group Sub-TLV is to 
indicate if a link belongs to a specific topology. Is my understanding correct?

By indicating "Exclude/Include" bunch of links for a Calc-Type, does it 
practically specify the topology?

Thank you, Linda


-Original Message-
From: Peter Psenak 
Sent: Thursday, November 4, 2021 1:16 PM
To: Linda Dunbar ; lsr@ietf.org
Subject: Re: Question about the FAD Flags Sub-TLV ( was RE: [Lsr] Looking for 
feedback of using Flex Algo to advertise the 5G edge computing associated 
metrics

Linda,

please see inline:


On 04/11/2021 18:17, Linda Dunbar wrote:
> Peter,
> Thank you very much for the valuable feedback.  We will move the
> content from Section 1, 2, 3 to an appendix per your suggestion.
> As for defining a new value in the Flexible Algorithm Definition Flags
> Sub-TLV, why can't we use the Metric-Type & Calc-Type to represent the
> information carried by the FAD Flags Sub-TLV?

because the Metric-Type in flex-algo is referring to link metrics, not to 
prefix metrics. And Calc-Type you still wan to use SPF, don't you?


> draft-dunbar-lsr-5g-edge-compute-01 suggests to add a new value to the
> "Metric-Type" to indicate the Aggregated Cost AppMetaData Metrics
> included in computing the constrained SPF.
> Is it reasonable to use Calc-Type to indicate the options you mentioned?

no, calculation type refers to how topology is calculated, not how/which
prefix metrics is used.

thanks,
Peter


> For example:
>
>   * Calc-Type-v1: replace the regular prefix metric,
>   * Calc-Type-v2: the newly added metric is added on top,
>   * Calc-Type-v3: only used as tiebreaker,
>   * Calc-Type-v4: use the default prefix metric when the AppMetaData
> Metrics is not present.  When AppMeteData metrics is not present,
> the prefix is considered normal that doesn't need special constraint
> SPF computation.
>   * Calc-Type-v5: no transit across areas/domains
>   * Calc-Type-v6: transit across areas/domains.
>
> Thank you,
> Linda
> -Original Message-
> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Wednesday, November 3, 2021 7:43 AM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; 
> lsr@ietf.org<mailto:lsr@ietf.org>
> Subject: Re: [Lsr] Looking for feedback of using Flex Algo to advertise
> the 5G edge computing associated metrics
> Hi Linda,
> I went through your document and here are my comments:
> 1. the section 1, 2, and 3 can probably be summarized in a single
> paragraph stating the problem you are trying to solve. The 5G details
> are redundant, you may just want to add reference to the parent document.
> 2. FAD is used to advertise how to compute the flex-algo paths, not to
> advertise metrics. What I believe you need to define for FAD is a new
> bit in the ISIS/OSPF Flexible Algorithm Definition Flags Sub-TLV to
> indicate that the calculation should use the new application prefix
> metric that you define and how exactly that metric will be used during
> calculation:
> a) does it replace the regular prefix metric, is added on top, only used
> as tiebreaker, etc,.
> b) what happens if the metric is not present with prefix advertisement,
> is the prefix considered unreachable for the flex-algo or do you
> fallback to regular prefix metric, etc,.
> c) how is the propagation of the new metric done between areas/domains
> 3. The new application metric should be advertised in the IP prefix
> reachability TLV associated with the (anycast) prefix.
> 4. How the application metric is calculated, using load, preference,
> etc, should be hidden from IGPs. I believe the application metric should
> be calculated at the egress router, associated with the
> prefix/Server-address and advertised in a form of the resulting value.
> If you need to consider Network Delay, you can combine the new app.
> metric (for prefixes) with the existing delay metric support (for links)
> in the flex-algo, no need to include network delay in the application
> metric itself. Advertising all the metadata and asking IGP at each node
> to derive the app metric seems sub-optimal, unless there is an
> unavoidable reason to do so.
> 5. I don't see any reason to define a new application in SABM as you do
> in section 7. The existing flex-algo app is sufficient.
> thanks,
> Peter
> On 14/10/2021 00:50, Linda Dunbar wrote:
>> LSR experts:
>>
>> We have updated the draft to reflect the suggestions from LSR WG to use
>> Flex Algo to advertise the metrics associated with the environment where
>> 5G edge computer servers are running.
>>
>> 

[Lsr] Question about the FAD Flags Sub-TLV ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

Peter,

Thank you very much for the valuable feedback.  We will move the content from 
Section 1, 2, 3 to an appendix per your suggestion.

As for defining a new value in the  Flexible Algorithm Definition Flags 
Sub-TLV, why can't we use the Metric-Type & Calc-Type to represent the 
information carried by the FAD Flags Sub-TLV?

draft-dunbar-lsr-5g-edge-compute-01 suggests to add a new value to the 
"Metric-Type" to indicate the Aggregated Cost AppMetaData Metrics included in 
computing the constrained SPF.

Is it reasonable to use Calc-Type to indicate the options you mentioned? For 
example:

-   Calc-Type-v1: replace the regular prefix metric,
-   Calc-Type-v2: the newly added metric is added on top,
-   Calc-Type-v3: only used as tiebreaker,
-   Calc-Type-v4: use the default prefix metric when the AppMetaData 
Metrics is not present.  When AppMeteData metrics is not present, the prefix is 
considered normal that doesn't need special constraint SPF computation.
-   Calc-Type-v5: no transit across areas/domains
-   Calc-Type-v6: transit across areas/domains.

Thank you,

Linda

-Original Message-
From: Peter Psenak 
Sent: Wednesday, November 3, 2021 7:43 AM
To: Linda Dunbar ; lsr@ietf.org
Subject: Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G 
edge computing associated metrics

Hi Linda,

I went through your document and here are my comments:

1. the section 1, 2, and 3 can probably be summarized in a single paragraph 
stating the problem you are trying to solve. The 5G details are redundant, you 
may just want to add reference to the parent document.

2. FAD is used to advertise how to compute the flex-algo paths, not to 
advertise metrics. What I believe you need to define for FAD is a new bit in 
the ISIS/OSPF Flexible Algorithm Definition Flags Sub-TLV to indicate that the 
calculation should use the new application prefix metric that you define and 
how exactly that metric will be used during
calculation:

a) does it replace the regular prefix metric, is added on top, only used as 
tiebreaker, etc,.
b) what happens if the metric is not present with prefix advertisement, is the 
prefix considered unreachable for the flex-algo or do you fallback to regular 
prefix metric, etc,.
c) how is the propagation of the new metric done between areas/domains


3. The new application metric should be advertised in the IP prefix 
reachability TLV associated with the (anycast) prefix.

4. How the application metric is calculated, using load, preference, etc, 
should be hidden from IGPs. I believe the application metric should be 
calculated at the egress router, associated with the prefix/Server-address and 
advertised in a form of the resulting value.
If you need to consider Network Delay, you can combine the new app.
metric (for prefixes) with the existing delay metric support (for links) in the 
flex-algo, no need to include network delay in the application metric itself. 
Advertising all the metadata and asking IGP at each node to derive the app 
metric seems sub-optimal, unless there is an unavoidable reason to do so.

5. I don't see any reason to define a new application in SABM as you do in 
section 7. The existing flex-algo app is sufficient.


thanks,
Peter




On 14/10/2021 00:50, Linda Dunbar wrote:
> LSR experts:
>
> We have updated the draft to reflect the suggestions from LSR WG to use
> Flex Algo to advertise the metrics associated with the environment where
> 5G edge computer servers are running.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2Fdata=04%7C01%7Clinda.dunbar%40futurewei.com%7C0a9f151594a34618078208d99ec77062%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637715401744226058%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=kS4yuH1YUVIYyTOdEH1U5XejgXRZJ3bMZ%2FaJeBGwLYw%3Dreserved=0
>
> In a nutshell, the draft proposes some new values in the Flex Algo
> Definition Sub-TLV
>
>   * A new Metric-Type is introduced to indicate the Aggregated Cost
> AppMetaData Metrics included in computing the constrained SPF.
>   * Additional subsub-TLVs to be included in the Flex Algo Definition
> Sub-TLV to carry the detailed metrics for the constrained SPF.
>
> We are looking for feedback of our revised approach.
>
> Thank you.
>
> Linda Dunbar
>


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

Re: [Lsr] LSR Presentation Slot Requests - IETF 112

[Linda Dunbar]

YingZhen and LSR Chairs:

Can we have 10 minutes to discuss using Flex Algo to advertise the metrics 
associated with the running environment of 5G Edge Compute servers?
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the draft proposes some new values in the Flex Algo Definition 
Sub-TLV

  *   A new Metric-Type is introduced to indicate the Aggregated Cost 
AppMetaData Metrics included in computing the constrained SPF.
  *   Additional subsub-TLVs to be included in the Flex Algo Definition Sub-TLV 
to carry the detailed metrics for the constrained SPF.


Thank you very much.

Linda Dunbar
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Monday, October 18, 2021 1:16 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: [Lsr] LSR Presentation Slot Requests - IETF 112

Hi all,

The IETF 112 Final Agenda is now available: 
https://datatracker.ietf.org/meeting/112/agenda.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F112%2Fagenda.html=04%7C01%7Clinda.dunbar%40futurewei.com%7C4b75cce04f1645403b0708d99263700b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701778095765178%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Oz7NqHV%2B%2FGMozsfUjhqwU%2BJ%2BU%2BjT8WU7FI9vQxlCKkw%3D=0>

We will have one LSR session:
Thursday, November 11, 2021
12:00-14:00 UTC
Thursday Session I


Please send slot requests to lsr-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>. 
Please include name of the presenter, pointer to the draft and time estimation 
including Q



Thanks,

Yingzhen

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

Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

Tony,

Thank you very much for the constructive feedback.
More questions to your suggestions are inserted below:

Linda
From: Tony Li  On Behalf Of Tony Li
Sent: Thursday, October 14, 2021 11:28 AM
To: Linda Dunbar 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G 
edge computing associated metrics


Hi Linda,

Thank you for your contribution.  I have several comments:


  1.  I think you could abstract this out from 5G and have a much stronger 
contribution. If I understand correctly, your goal is to route to optimal 
instances of anycast load balancers. There's nothing radio specific about that. 
 This would also great simplify the discussion.
[Linda] The reason of mentioning 5G is because the Local Data Network (LDN) 
supporting the 5G traffic has some unique characteristics, such as:

  1.  The routing distance to reach a different Edge Server in LDN is very 
small. Therefore,  there is the need to consider additional metrics for 
computing the shortest path.
  2.  When a UE anchors to a new UPF that directly connect to the IP Local Data 
Network ingress node as the result of anchoring to a new Cell Tower, the source 
IP address is usually not changed unless the new UPF belongs to a different 
network operator. The preferred shortest path should point to the Edge Server 
to which the UE was connected to before the re-anchoring.
In 4G, the IP network connected to the  4G's P-GW are far apart, making the 
routing distance be the major contributor for the Shortest Path.



  1.  The flow affinity that you request is not something that is normally 
implemented. The affinity that I'm familiar with is a hash function before 
indexing into a multi-path table that doesn't fluctuate frequently.  I don't 
think that you have that condition. I could envision some kind of forwarding 
cache, but that would deserve a careful discussion of cache timeouts, as they 
need to be consistent across the network. I also don't understand how this 
would work in the face of a handover.
[Linda] The handover in 5G doesn't change source IP addresses. Therefore, the 
hash method should work, i.e. the packets with the same header fields get 
indexing to the same egress port.


  1.  I'm not following how link metrics would interact with your site cost 
metrics. Do you even want them to?
[Linda] The Link Cost mentioned in Section 3.3 is loosely used to indicate the 
cost reach the attached server, as some servers might be more powerful than 
others. How about changing the wording to "The cost for the egress edge nodes 
to reach to their attached servers is embedded in the "capacity index"?

4) I don't think you really want to advertise your site-cost metrics in the 
FAD.  The point of the FAD is to define the constraints for the topology. Yes 
you will want to use a FAD to advertise that a given algorithm will be using 
your specific Calc-Type, but I'm not seeing any kind of global topology 
constraints here.  The metrics that you're advertising don't belong in the FAD 
and instead should probably be in a prefix reachability
TLV.

[Linda] Can FAD define a topology that excluding some edge servers based on 
source IP address? For example, when a UE anchors to a new UPF that connects to 
a new ingress router, the new topology for this specific source IP only 
includes the previous edge server?
while as other UEs (different source IP) to the ingress router has the old 
topology that include all the edge servers?

Regards,
Tony



On Oct 13, 2021, at 3:50 PM, Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:

LSR experts:

We have updated the draft to reflect the suggestions from LSR WG to use Flex 
Algo to advertise the metrics associated with the environment where 5G edge 
computer servers are running.

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca74ef00ce42c4db6ced808d98f2f8f9e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637698256727241840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=eeY4mIV49hS3KLcLzrcoNRVNXozKpRr1ioiLxIXjXVA%3D=0>

In a nutshell, the draft proposes some new values in the Flex Algo Definition 
Sub-TLV

  *   A new Metric-Type is introduced to indicate the Aggregated Cost 
AppMetaData Metrics included in computing the constrained SPF.
  *   Additional subsub-TLVs to be included in the Flex Algo Definition Sub-TLV 
to carry the detailed metrics for the constrained SPF.


We are looking for feedback of our revised approach.

Thank you.

Linda Dunbar

___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Fl

[Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

[Linda Dunbar]

LSR experts:

We have updated the draft to reflect the suggestions from LSR WG to use Flex 
Algo to advertise the metrics associated with the environment where 5G edge 
computer servers are running.

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

In a nutshell, the draft proposes some new values in the Flex Algo Definition 
Sub-TLV

  *   A new Metric-Type is introduced to indicate the Aggregated Cost 
AppMetaData Metrics included in computing the constrained SPF.
  *   Additional subsub-TLVs to be included in the Flex Algo Definition Sub-TLV 
to carry the detailed metrics for the constrained SPF.


We are looking for feedback of our revised approach.

Thank you.

Linda Dunbar

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

[Lsr] Is it necessary for OSPF and ISIS to have different FAD Constraint Sub-TLV in draft-ietf-lsr-flex-algo-bw-con-1?

[Linda Dunbar]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony:

draft-ietf-lsr-flex-algo-bw-con-1 has two different sub-TLVs for ISIS FAD 
Constraint and OSPF FAD constraint. But the only differences are:

  *   ISIS Exclude Minimum Bandwidth sub-TLV has one octet for Type and Length
  *   OSPF Exclude Minimum Bandwidth sub-TLV has two octets for Type and Length

Why can't just have one Exclude Minimum Bandwidth sub-TLV to be used for both 
ISIS and OSPF FlexAlgo?

Thank you very much,
Linda Dunbar
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[Linda Dunbar]

Shraddha,

Thank you very much for the suggestion.

Should the "Edge computing metric" be a value in Metric-Type of the FlexAlgo 
Sub-TLV?
Can multiple sub-sub-TLV carried by the  FlexAlgo SubTLV indicate different 
metric-types?  If YES, the individual metrics sub-subTLV has its own Metrics 
Type, which can be different from the Metric-Type of the FlexAlgo Sub-TLV.  Is 
it a problem?

I am still not clear the different purpose of "Flex-Algorithm" and "Calc-Type". 
Can someone give an example?

We will update the draft per Acee's and your suggestion to encode the 5G EC 
servers running environment metrics in the Flexalgo advertisement.

Thank you.

Linda

From: Shraddha Hegde 
Sent: Thursday, September 23, 2021 5:39 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; Tony Li ; Peter Psenak (ppsenak) 

Cc: lsr@ietf.org; bruno.decra...@orange.com; Acee Lindem (acee) 

Subject: RE: questions about draft-ietf-lsr-flex-algo-bw-con-01

Hi Linda,

I read your draft draft-dunbar-lsr-5g-edge-compute.
>From my understanding you are using various parameters such as capacity index, 
>preference,network delay etc
To derive a metric. You want to use this derived metric for SPF computation.

My suggestion would be to define new standard metric under generic metric called
"Edge computing metric". This metric would be similar to "bandwidth metric " 
defined in
draft-ietf-lsr-flex-algo-bw-con. This edge computing metric will be computed 
based on various advertised
parameters (similar to bandwidth metric which is computed based on 
link-bandwidth).
A flex-algo can then be used to compute using metric-type "Edge computing 
metric".

Rgds
Shraddha



Juniper Business Use Only
From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Linda Dunbar
Sent: Friday, September 17, 2021 12:58 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: [Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[External Email. Be cautious of content]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony,

Is it correct that the intent of the draft is to prevent some "elephant flows" 
from being placed over certain links?

Section 2.1 listed the TLV for the ISIS Generic Metric

Is the property of preventing some flows being placed on a link to be encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Tony Li 
mailto:tony...@tony.li>>; Peter Psenak (ppsenak) 
mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

Answers are inserted below:




From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo



On Sep 15, 2021, at 11:17 AM, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

So, if someone wants to define new constraints (e.g., Linda's 
server/application metrics), they would need to define the semantics and 
encodings similar to what is being done for bandwidth metrics in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-alg

[Lsr] questions about draft-ietf-lsr-flex-algo-bw-con-01

[Linda Dunbar]

Shraddha, Bill, Rajesh, Bruno, Peter, and Tony,

Is it correct that the intent of the draft is to prevent some "elephant flows" 
from being placed over certain links?

Section 2.1 listed the TLV for the ISIS Generic Metric

Is the property of preventing some flows being placed on a link to be encoded 
in the Value field of the ISIS Generic Metric  in Section 2.1?

Why not directly included in the value field of Flex Algo TLV?  Section 2.3 
says that using FAPM sub-TLV to indicate Flex Algo needs to use the Generic 
Metric. But this property of preventing some flows to be placed on certain 
links doesn't need to be generic, does it?

How does an IGP node know which link to advertise this property? Is it by 
configuration?

Linda Dunbar


From: Acee Lindem (acee) 
Sent: Wednesday, September 15, 2021 4:30 PM
To: Linda Dunbar ; Tony Li ; Peter 
Psenak (ppsenak) 
Cc: Acee Lindem (acee) ; 
bruno.decra...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, September 15, 2021 at 3:45 PM
To: Tony Li mailto:tony...@tony.li>>, "Peter Psenak (ppsenak)" 
mailto:ppse...@cisco.com>>
Cc: "Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>, Acee 
Lindem mailto:a...@cisco.com>>, Bruno Decraene 
mailto:bruno.decra...@orange.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] draft-ietf-lsr-flex-algo

Tony,

Answers are inserted below:




From: Tony Li mailto:tony1ath...@gmail.com>> On Behalf 
Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak mailto:ppse...@cisco.com>>
Cc: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) mailto:a...@cisco.com>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo



On Sep 15, 2021, at 11:17 AM, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

So, if someone wants to define new constraints (e.g., Linda's 
server/application metrics), they would need to define the semantics and 
encodings similar to what is being done for bandwidth metrics in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-flex-algo-bw-con%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C5b92535cbd7e4501dadd08d978900d0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637673382361243040%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=%2Bvy%2FOpJOrTO3zhdZ16p3iNo2yD%2F4LkrJWShiDoU3z7o%3D=0>
 . Then the flex algos could be defined using these metrics. Correct?

yes, they would need to define a new FAD constraint and/or metric only.


I agree that if the goal is a new metric, then that's sufficient.  [Plug for 
generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF 
algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could 
you please clarify?
[Linda] I don't think so. We want a constrained SPF algorithm that take into 
additional metrics. Just like TE being added into the SPF.

I was thinking that as well. These metrics would be defined to have precedence 
over the path cost - sort of like OSPF Type 2 external metrics do for OSPF AS 
External routes.

Thanks,
Acee

Linda Dunbar

Tony

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

Re: [Lsr] draft-ietf-lsr-flex-algo

[Linda Dunbar]

Tony,

Answers are inserted below:




From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, September 15, 2021 1:26 PM
To: Peter Psenak 
Cc: Acee Lindem (acee) ; Acee Lindem (acee) 
; Linda Dunbar ; 
bruno.decra...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo




On Sep 15, 2021, at 11:17 AM, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

So, if someone wants to define new constraints (e.g., Linda's 
server/application metrics), they would need to define the semantics and 
encodings similar to what is being done for bandwidth metrics in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-flex-algo-bw-con%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Ca8b0297f156e4079414008d978764920%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637673271737823035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=fm4E8mhhCeYA4ab7gvSDqBX9ZG6QjBJA62Br86l%2F1q0%3D=0>
 . Then the flex algos could be defined using these metrics. Correct?

yes, they would need to define a new FAD constraint and/or metric only.


I agree that if the goal is a new metric, then that's sufficient.  [Plug for 
generic metrics.]

It sounded a bit like Linda was wanting a fundamental change to the SPF 
algorithm.  If, so, I believe that would require a new Calc-Type. Linda, could 
you please clarify?
[Linda] I don't think so. We want a constrained SPF algorithm that take into 
additional metrics. Just like TE being added into the SPF.

Linda Dunbar

Tony

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

Re: [Lsr] draft-ietf-lsr-flex-algo

[Linda Dunbar]

Peter and Tony, 

Thank you very much for the explanation.

Is it necessary to register with IANA on individual Flex-Algo value (a value 
between 128-255)?
Say there are 5 properties associated with the Stub link, one Flex algo uses 
weighted values of 4 properties, another Flex Algo uses Weighted values of 5 
properties. Can operator use any value they want? As long as the value is 
consistent among all nodes in one IGP domain? 

How is Calc-Type used, especially combined with Flex-Algo? 

Does the Flex-Algo type already indicate how  Metric are to be included in the 
algorithm? Why need to explicit indicate the "Metric-Type" in the FAD Sub-TLV? 

 
Linda

-Original Message-
From: Peter Psenak  
Sent: Thursday, September 9, 2021 1:00 PM
To: Tony Li ; Linda Dunbar 
Cc: bruno.decra...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, Tony,


On 09/09/2021 19:37, Tony Li wrote:
> 
> 
> Hi Linda,
> 
> Algorithm types 128-255 are intended to be used with the constraints 
> that are advertised inside of a FlexAlgo definition.
> 
> I think what you're proposing is not captured there, so you would need 
> to have a defined algorithm from 2-127.

eventually, the usage of the "weighted value of a Stub Link property" 
can be added to the FAD and be used with flex-algo.

thanks,
Peter


> 
> Tony
> 
> 
>> On Sep 9, 2021, at 9:51 AM, Linda Dunbar > <mailto:linda.dun...@futurewei.com>> wrote:
>>
>> Peter,
>>
>> draft-ietf-lsr-flex-algo-17 currently has registered Algorithm Types
>> 128-255 with IANA.
>> If we need to add a new Algorithm Type, e.g. using a weighted value 
>> of a Stub Link property in calculating the shortest path, do we need 
>> to use one of the value within 128-255 or need to ask IANA to assign 
>> one of the values within 2-127 (currently shown unassigned on IANA page)?
>>
>> Linda Dunbar
>>
>> -Original Message-
>> From: Lsr mailto:lsr-boun...@ietf.org>> On 
>> Behalf Of Peter Psenak
>> Sent: Thursday, September 9, 2021 7:52 AM 
>> To:bruno.decra...@orange.com 
>> <mailto:bruno.decra...@orange.com>;lsr@ietf.org <mailto:lsr@ietf.org>
>> Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
>>
>> Hi Bruno,
>>
>> On 09/09/2021 14:43, bruno.decra...@orange.com 
>> <mailto:bruno.decra...@orange.com> wrote:
>>> Hi authors, all,
>>>
>>> I have a question related to the two-way connectivity check 
>>> performed on each link during the FlexAlgo SPF.
>>
>> flex-algo is defined as set of:
>>
>> (a) calculation-type
>> (b) metric-type,
>> (c) a set of constraints
>>
>> Two way connectivity check for any link in the MT topology is 
>> orthogonal to flex-algo and is done once only and used for all algorithms.
>>
>> Flex-algo calculation using (a), (b), and (c) is done on top of MT 
>> topology using only links for which the 2WCC has already been performed.
>>
>>
>>>
>>> Is this point documented in the document? I could not find it so far.
>>> If not, what is the (reverse connectivity) check that need to be 
>>> performed on the reverse link?
>>
>>
>> none.
>>
>> thanks,
>> Peter
>>
>>
>>>
>>> A priori I could see multiple options:
>>> a) link exist
>>> b) link exist with a standard IGP metric  (seem the option defined 
>>> in the ISO spec §7.2.8.2)
>>> c) link exist with the FlexAlgo metric used by FlexAlgo
>>> d) link exist with the FlexAlgo metric used by FlexAlgo and link 
>>> complies to FlexAlgo constraints.
>>>
>>> I think we'll agree that this point requires uniformity across nodes 
>>> hence standardization.
>>>
>>> Personally, I don't have significant preference, but the algo 
>>> defined in §13 "Calculation of Flexible Algorithm Paths" could be 
>>> read as defining option "d" (as links not following the constraints 
>>> are "pruned from the computation") but I'm not sure that this is 
>>> intended for the two-way connectivity check.
>>>
>>> Thanks,
>>> Regards,
>>> --Bruno
>>>
>>>
>>>
>>> 
>>> _
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations 
>>> confidentielles ou privilegiees et ne doivent donc pas etre 
>>> diffuses, exploites ou copies sans autorisatio

Re: [Lsr] draft-ietf-lsr-flex-algo

[Linda Dunbar]

Peter, 

draft-ietf-lsr-flex-algo-17 currently has registered Algorithm Types 128-255 
with IANA. 
If we need to add a new Algorithm Type, e.g. using a weighted value of a Stub 
Link property in calculating the shortest path, do we need to use one of the 
value within 128-255 or need to ask IANA to assign one of the values within 
2-127 (currently shown unassigned on IANA page)?

Linda Dunbar

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 9, 2021 7:52 AM
To: bruno.decra...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Bruno,

On 09/09/2021 14:43, bruno.decra...@orange.com wrote:
> Hi authors, all,
> 
> I have a question related to the two-way connectivity check performed on each 
> link during the FlexAlgo SPF.

flex-algo is defined as set of:

(a) calculation-type
(b) metric-type,
(c) a set of constraints

Two way connectivity check for any link in the MT topology is orthogonal to 
flex-algo and is done once only and used for all algorithms.

Flex-algo calculation using (a), (b), and (c) is done on top of MT topology 
using only links for which the 2WCC has already been performed.


> 
> Is this point documented in the document? I could not find it so far.
> If not, what is the (reverse connectivity) check that need to be performed on 
> the reverse link?


none.

thanks,
Peter


> 
> A priori I could see multiple options:
> a) link exist
> b) link exist with a standard IGP metric  (seem the option defined in the ISO 
> spec §7.2.8.2)
> c) link exist with the FlexAlgo metric used by FlexAlgo
> d) link exist with the FlexAlgo metric used by FlexAlgo and link complies to 
> FlexAlgo constraints.
> 
> I think we'll agree that this point requires uniformity across nodes hence 
> standardization.
> 
> Personally, I don't have significant preference, but the algo defined in §13 
> "Calculation of Flexible Algorithm Paths" could be read as defining option 
> "d" (as links not following the constraints are "pruned from the 
> computation") but I'm not sure that this is intended for the two-way 
> connectivity check.
> 
> Thanks,
> Regards,
> --Bruno
> 
> 
> 
> _
> 
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3Dreserved=0
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Clinda.dunbar%40futurewei.com%7C2504ea39e2e94976a95908d97390b485%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637667887645570581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=bHrwW7VJ2L1SXk6Jz%2BXZRW9%2FRUB9Z8BpqzLI6fXyeBA%3Dreserved=0

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

[Lsr] Using Flex Algo for IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

If Flex Algo is used, is it correct that the draft needs to describe the 
following?

  1.  add additional TYPEs to the IGP Metric-Type Registry on top of the 
existing types (0-IGP metric, 1-Link-delay, 2-TE Metric)

  1.  Capacity Index
  2.  Site preference index
  3.  Load index



  1.  add additional Calc-Type to indicate the formula to calculate the Load 
indexes & TE constraint SPF.

Question:
Draft-ietf-lsr-flex-algo currently has registered Algorithm Types 128-255 with 
IANA. Does the newly added Algorithm Type need to use one of the value within 
128-255 or need to ask IANA to assign one of the values within 2-127 (currently 
shown unassigned on IANA page)?

Thanks, Linda

From: Acee Lindem (acee) 
Sent: Wednesday, July 14, 2021 12:41 PM
To: Linda Dunbar ; Aijun Wang 
; Les Ginsberg (ginsberg) ; 
'Yingzhen Qu' ; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

OSPF and IS-IS calculate routes based on the current metrics and any change to 
this computation to use different metrics is not backward compatible. Like I 
said, conceivably this problem could be solved with Flex Algo.
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Wednesday, July 14, 2021 at 1:16 PM
To: Acee Lindem mailto:a...@cisco.com>>, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>, "Les Ginsberg 
(ginsberg)" mailto:ginsb...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

Can you be more specific on what cause "backward not compatible" by introducing 
the new Sub TLV to carry the additional metrics about the Edge Router?
 Especially the newly introduced sub-TLV is only carried by the LSA distributed 
among the routers in the special purposed routing domain (5G LDN).

Linda

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, July 14, 2021 12:08 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; Linda 
Dunbar mailto:linda.dun...@futurewei.com>>; 
'Yingzhen Qu' mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Aijun, Linda,
My objection is more fundamental than the encoding of the information. You 
can't just define new non-backward compatible metrics and say only a subset of 
routers in the IGP domain use them. This is just doesn't work... I hope we're 
done.
Acee

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Wednesday, July 14, 2021 at 4:37 AM
To: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
'Linda Dunbar' mailto:linda.dun...@futurewei.com>>, 
Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi, Les and Acee:

Actually, I think these metrics(aggregated or raw data) information should be 
associated with the link that connected to the App server, not the prefixes 
that identify the App server.
These sub-sub-TLVs can be put into Application-Specific Link Attribute sub-TLV, 
as that defined for OPPF(RFC8920) and ISIS(RFC8919),
and then in Stub-Link TLV that proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-08=04%7C01%7Clinda.dunbar%40futurewei.com%7C8dd58f0d75234f9309c608d946ee86c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618812557513063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=mjbzQcTc2BBHCEg1sTANZLfvgYrie43I5xRTyw7F79s%3D=0>.

Do you have other concerns for such solution?

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Acee Lindem 
(acee)

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

Can you be more specific on what cause "backward not compatible" by introducing 
the new Sub TLV to carry the additional metrics about the Edge Router?
 Especially the newly introduced sub-TLV is only carried by the LSA distributed 
among the routers in the special purposed routing domain (5G LDN).

Linda

From: Acee Lindem (acee) 
Sent: Wednesday, July 14, 2021 12:08 PM
To: Aijun Wang ; Les Ginsberg (ginsberg) 
; Linda Dunbar ; 'Yingzhen Qu' 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Aijun, Linda,
My objection is more fundamental than the encoding of the information. You 
can't just define new non-backward compatible metrics and say only a subset of 
routers in the IGP domain use them. This is just doesn't work... I hope we're 
done.
Acee

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Wednesday, July 14, 2021 at 4:37 AM
To: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>, 
'Linda Dunbar' mailto:linda.dun...@futurewei.com>>, 
Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi, Les and Acee:

Actually, I think these metrics(aggregated or raw data) information should be 
associated with the link that connected to the App server, not the prefixes 
that identify the App server.
These sub-sub-TLVs can be put into Application-Specific Link Attribute sub-TLV, 
as that defined for OPPF(RFC8920) and ISIS(RFC8919),
and then in Stub-Link TLV that proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-passive-interface-attribute-08=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce1a6bb1151174fcb3bc008d946ea1d31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618793596728139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=OoaZZGKRuWtDKeurkB6vjgbOk%2BoQncJ9U5VCatEDcnU%3D=0>.

Do you have other concerns for such solution?

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Acee Lindem 
(acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda -

I think Acee's objections (which I support) make progressing your draft 
unlikely - which makes resolution of your questions somewhat moot.

However, please find responses inline.

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Les,

Thank you for the comments.
Replies are inserted below:


From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Monday, July 12, 2021 8:32 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
Linda Dunbar mailto:linda.dun...@futurewei.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda -

Picking up on this comment from Acee:

"Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably. "
[Linda] Yes, the application is identified by their IP addresses.

As regards how to advertise the new metric, to the best of my understanding 
what you want to advertise is the cost to reach an anycast address - which 
argues for a prefix Reachability advertisement. And indeed, that is what you 
chose to use for OSPF. It therefore mak

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Joel, 

Thank you for the suggestion of Babel. 

Babel is a Distance vector protocol that  sends entire routing table to 
directly connected neighbors. Useful for some domains. 

IS-IS and OSFP,  Link state protocols send information about directly connected 
links to all the routers in the network, are useful for more domains. 

Why only for Distance Vector based? Not Link state based? 

Linda 

-Original Message-
From: Joel M. Halpern  
Sent: Wednesday, July 14, 2021 11:35 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; Yingzhen Qu ; lsr@ietf.org
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

If you want to experiment with unusual metrics, and minimize the degree to 
which you need consistency, maybe you should look at running a different 
routing protocol in this limited domain?  Rather than trying to make IS-IS and 
OSPF do something they are not designed for?  (While there are probably other 
alternatives, Babel comes to mind as a routing protocol designed with 
experimentaiton with metrics in mind.)

Yours,
Joel

On 7/14/2021 12:20 PM, Linda Dunbar wrote:
> Acee,
> 
> The "limited domain" per RFC8799  is a special purposed network that 
> have boundary, e.g. DetNet. For 5G EC, a Limited Domain network could 
> be built specifically for Unmanned Aerial Vehicles (UAV), as specified 
> by 3GPP 23.748.  This UAV Limited Domain network has routers and links 
> that connect the moving UAVs with the UAV control servers, the 
> analytics functions, and data storages; has boundary and  may not have 
> access to public internet.
> 
> Among those routers in the UAV Limited Domain, the routing distance 
> alone is no longer enough in computing the optimal Path. Therefore, 
> IGP is needed to distribute not only link bandwidth, but also the IP 
> layer Metrics specified by draft-dunbar-lsr-5g-edge-compute-ext, specifically:
> 
>   * Capacity Index:
> 
> Is used to differentiate the running environment of the attached 
> application server (analytics or data storages) that are identified by 
> their IP addresses.  At some sites, the IP address exposed to the 
> network is the App Layer Load balancer that have  many instances 
> attached.  At other sites,  the IP address exposed is the server 
> instance only.
> 
> "Capacity Index", which is a numeric number configured by the Domain 
> Controller on all A-ERs in the domain consistently , is used to 
> represent the capacity of the application server attached to an A-ER.
> 
>   * Site preference index: 
> 
> Is used to describe some sites are more preferred than others for some 
> flows that are identified by the IP header fields. "Site Preference 
> Index", which is a numeric number configured by the Domain Controller.
> 
>   * IP-Layer Metric for gauging the Load for the attached Prefix (i.e.,
> App Server):
> 
> The Load Measurement to an attached IP prefix (App Server) is a 
> weighted combination of the number of packets/bytes to the IP prefix 
> and the number of packets/bytes from the IP prefix which are collected 
> by the A-ER that has the App Server directly attached.
> 
> An A-ER only collects those measurement for the prefixes instructed by 
> the Domain Controller .
> 
> The work proposed is for the LSR Chartered Work Item "4) Extensions 
> for source-destination routing".
> 
> Is this description clear enough to move forward in the LSR WG?
> 
> Best regards, Linda Dunbar
> 
> *From:* Acee Lindem (acee) 
> *Sent:* Tuesday, July 13, 2021 2:46 PM
> *To:* Linda Dunbar ; Yingzhen Qu 
> ; lsr@ietf.org
> *Cc:* lsr-cha...@ietf.org
> *Subject:* Re: IP layer metrics collected by Edge routers - 
> draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot
> request)
> 
> We seem to be in a circular discussion - we're not standardizing 
> loosely-defined metrics that only work in limited domains for OSPF and 
> IS-IS. It is not a question of where.
> 
> Acee
> 
> *From: *Linda Dunbar  <mailto:linda.dun...@futurewei.com>>
> *Date: *Tuesday, July 13, 2021 at 3:42 PM
> *To: *Acee Lindem mailto:a...@cisco.com>>, Yingzhen 
> Qu mailto:yingzhen.i...@gmail.com>>,
> "lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Cc: *"lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>" 
> mailto:lsr-cha...@ietf.org>>
> *Subject: *RE: IP layer metrics collected by Edge routers - 
> draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot
> request)
> 
> Acee,
> 
> Limited domain also needs IS-IS and OSPF  routing protocol (among 
> routers in the limited domain). If not in LSR, where is the righ

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

The "limited domain" per RFC8799  is a special purposed network that have 
boundary, e.g. DetNet. For 5G EC, a Limited Domain network could be built 
specifically for Unmanned Aerial Vehicles (UAV), as specified by 3GPP 23.748.  
This UAV Limited Domain network has routers and links that connect the moving 
UAVs with the UAV control servers, the analytics functions, and data storages; 
has boundary and  may not have access to public internet.
Among those routers in the UAV Limited Domain, the routing distance alone is no 
longer enough in computing the optimal Path. Therefore, IGP is needed to 
distribute not only link bandwidth, but also the IP layer Metrics specified by 
draft-dunbar-lsr-5g-edge-compute-ext, specifically:

  *   Capacity Index:

Is used to differentiate the running environment of the attached application 
server (analytics or data storages) that are identified by their IP addresses.  
At some sites, the IP address exposed to the network is the App Layer Load 
balancer that have  many instances attached.  At other sites,  the IP address 
exposed is the server instance only.

"Capacity Index", which is a numeric number configured by the Domain Controller 
on all A-ERs in the domain consistently , is used to represent the capacity of 
the application server attached to an A-ER.

  *   Site preference index:
Is used to describe some sites are more preferred than others for some flows 
that are identified by the IP header fields. "Site Preference Index", which is 
a numeric number configured by the Domain Controller.


  *   IP-Layer Metric for gauging the Load for the attached Prefix (i.e., App 
Server):
The Load Measurement to an attached IP prefix (App Server) is a weighted 
combination of the number of packets/bytes to the IP prefix and the number of 
packets/bytes from the IP prefix which are collected by the A-ER that has the 
App Server directly attached.
An A-ER only collects those measurement for the prefixes instructed by the 
Domain Controller .


The work proposed is for the LSR Chartered Work Item "4) Extensions for 
source-destination routing".
Is this description clear enough to move forward in the LSR WG?

Best regards, Linda Dunbar

From: Acee Lindem (acee) 
Sent: Tuesday, July 13, 2021 2:46 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

We seem to be in a circular discussion - we're not standardizing 
loosely-defined metrics that only work in limited domains for OSPF and IS-IS. 
It is not a question of where.
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Tuesday, July 13, 2021 at 3:42 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

Limited domain also needs IS-IS and OSPF  routing protocol (among routers in 
the limited domain). If not in LSR, where is the right place?

Linda

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Tuesday, July 13, 2021 2:24 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda - we're not doing routing for limited domains in LSR. It doesn't make any 
sense to go any further until you fix the draft or abandon it.
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Tuesday, July 13, 2021 at 1:23 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The scope of the draft is for IGP in the  Limited Domains per RFC8799, i.e. the 
small number of routers in the 5G LDN domain. Not meant for public Internet.

Answers to your questions are inserted below:

Linda

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Monday, July 12, 2021 7:06 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Les,

Thank you for the comments.
Replies are inserted below:


From: Les Ginsberg (ginsberg) 
Sent: Monday, July 12, 2021 8:32 PM
To: Acee Lindem (acee) ; Linda Dunbar 
; Yingzhen Qu ; 
lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda -

Picking up on this comment from Acee:

"Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably. "
[Linda] Yes, the application is identified by their IP addresses.

As regards how to advertise the new metric, to the best of my understanding 
what you want to advertise is the cost to reach an anycast address - which 
argues for a prefix Reachability advertisement. And indeed, that is what you 
chose to use for OSPF. It therefore makes no sense to me why you would use a 
link attribute advertisement when advertising the same information in IS-IS.
[Linda]  Is it better to use the TLV 22 (Extended IS Reachability) to carry the 
Site-Cost subTLVs specified in the draft?  Or is TLV 23  (IS Neighbor Attribute 
) more appropriate?


I also think you are quite confused about the application part of "ASLA" as 
defined in RFC 8919/8920. The application identifies which applications are 
using the link attribute advertisements - it does not define the attribute 
itself - which potentially could be used by any application.
[Linda] since not every node will utilize the detailed IP Layer Metrics carried 
in the Site-COST,  the BIT MASK is to indicate if a Node should even process 
the detailed IP layer metrics. Is "ASLA"  intended to be?

If you need to advertise a new type of metric, the identification of that 
metric derives from the (sub-)TLV codepoint used - not from any of the 
applications bits. Your proposal to define a new application "C" therefore 
seems inappropriate.

+1 to Acee's other comments.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-  Aggregated Cost Advertisement

-  IP Layer App-Metrics Advertisements by OSPF

"Aggregated Cost" is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

So, why would these "capable" nodes have a consistent algorithm for using this 
complex set of metrics but the A-ERs would not have a consistent algorithm for 
aggregating the cost?

Since only a subset of routers within an IGP domain need to know those detailed 
metrics, the draft used your suggested  OSPFv2 Extended Prefix Opaque LSA for 
IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV to carry the detailed 
sub-TLVs.  For routers that don't care about those metrics, they can ignore 
them very easily.

This just doesn't work. All routers in an IGP domain must use the same 
algorithm. You can't just draw a picture with an LDN directly connected to a 
couple A-ERs say that the LDNs can use your metrics to route application 
specific traffic. The problem could possibly be solved with flex algorithm but 
it would require a lot more specification. I guess with your simple topology 
different LDNs could use the metrics differently as well? This would explain 
why you are not concerned with "consistency"...

It worth noting that not all hosts (prefix) attached to an A-ER are ANYCAST 
servers that need network optimization. An A-ER only needs to advertise the 
App-Metrics for the ANYCAST addresses that match with the configured ACLs.

Note that routes are based on IP p

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

Limited domain also needs IS-IS and OSPF  routing protocol (among routers in 
the limited domain). If not in LSR, where is the right place?

Linda

From: Acee Lindem (acee) 
Sent: Tuesday, July 13, 2021 2:24 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda - we're not doing routing for limited domains in LSR. It doesn't make any 
sense to go any further until you fix the draft or abandon it.
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Tuesday, July 13, 2021 at 1:23 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The scope of the draft is for IGP in the  Limited Domains per RFC8799, i.e. the 
small number of routers in the 5G LDN domain. Not meant for public Internet.

Answers to your questions are inserted below:

Linda

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Monday, July 12, 2021 7:06 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-  Aggregated Cost Advertisement

-  IP Layer App-Metrics Advertisements by OSPF

"Aggregated Cost" is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

So, why would these "capable" nodes have a consistent algorithm for using this 
complex set of metrics but the A-ERs would not have a consistent algorithm for 
aggregating the cost?
[Linda] Example of the nodes that need the metrics: analytic function (residing 
on one of the nodes in the LDN);  a small number of UPF functions that need the 
metrics.


Since only a subset of routers within an IGP domain need to know those detailed 
metrics, the draft used your suggested  OSPFv2 Extended Prefix Opaque LSA for 
IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV to carry the detailed 
sub-TLVs.  For routers that don't care about those metrics, they can ignore 
them very easily.

This just doesn't work. All routers in an IGP domain must use the same 
algorithm. You can't just draw a picture with an LDN directly connected to a 
couple A-ERs say that the LDNs can use your metrics to route application 
specific traffic. The problem could possibly be solved with flex algorithm but 
it would require a lot more specification. I guess with your simple topology 
different LDNs could use the metrics differently as well? This would explain 
why you are not concerned with "consistency"...  \
[Linda] The 5G LDN domain  is a limited domain per RFC 8799, and forms its own 
IGP domain. The "consistency is only for the limited nodes that are configured 
to utilize the IP layer metrics". The IP Layer metrics is for nodes in this 
limited domain to supplement the forwarding path computation.

It worth noting that not all hosts (prefix) attached to an A-ER are ANYCAST 
servers that need network optimization. An A-ER only needs to advertise the 
App-Metrics for the ANYCAST addresses that match with the configured ACLs.

Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably.
[Linda] the Applications that need special consideration are identified by its 
IP address.

Thanks,
Acee


Any other concerns?

Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

The scope of the draft is for IGP in the  Limited Domains per RFC8799, i.e. the 
small number of routers in the 5G LDN domain. Not meant for public Internet.

Answers to your questions are inserted below:

Linda

From: Acee Lindem (acee) 
Sent: Monday, July 12, 2021 7:06 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: IP layer metrics collected by Edge routers - 
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

-  Aggregated Cost Advertisement

-  IP Layer App-Metrics Advertisements by OSPF

"Aggregated Cost" is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

So, why would these "capable" nodes have a consistent algorithm for using this 
complex set of metrics but the A-ERs would not have a consistent algorithm for 
aggregating the cost?
[Linda] Example of the nodes that need the metrics: analytic function (residing 
on one of the nodes in the LDN);  a small number of UPF functions that need the 
metrics.


Since only a subset of routers within an IGP domain need to know those detailed 
metrics, the draft used your suggested  OSPFv2 Extended Prefix Opaque LSA for 
IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV to carry the detailed 
sub-TLVs.  For routers that don't care about those metrics, they can ignore 
them very easily.

This just doesn't work. All routers in an IGP domain must use the same 
algorithm. You can't just draw a picture with an LDN directly connected to a 
couple A-ERs say that the LDNs can use your metrics to route application 
specific traffic. The problem could possibly be solved with flex algorithm but 
it would require a lot more specification. I guess with your simple topology 
different LDNs could use the metrics differently as well? This would explain 
why you are not concerned with "consistency"...  \
[Linda] The 5G LDN domain  is a limited domain per RFC 8799, and forms its own 
IGP domain. The "consistency is only for the limited nodes that are configured 
to utilize the IP layer metrics". The IP Layer metrics is for nodes in this 
limited domain to supplement the forwarding path computation.

It worth noting that not all hosts (prefix) attached to an A-ER are ANYCAST 
servers that need network optimization. An A-ER only needs to advertise the 
App-Metrics for the ANYCAST addresses that match with the configured ACLs.

Note that routes are based on IP prefixes and not applications while the draft 
uses these two interchangeably.
[Linda] the Applications that need special consideration are identified by its 
IP address.

Thanks,
Acee


Any other concerns?

Thank you
Linda Dunbar

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] LSR Presentation Slot Requests - IETF111

Speaking as WG member:

Hi Linda,
Even if you've added some IS-IS encodings, the draft still suffers from the 
fundamental problem of the previous draft. If you can't rely on the A-ERs to 
consistently calculate an aggregated metric, how can you rely on all the 
routers in the IGP routing domain to use complex set of metrics to reach the 
least-loaded app server? Do we really want to talk about this again?
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem ma

[Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

[Linda Dunbar]

Acee,

The draft-dunbar-lsr-5g-edge-compute-ospf-ext has two parts:

  *   Aggregated Cost Advertisement
  *   IP Layer App-Metrics Advertisements by OSPF

"Aggregated Cost" is only applicable to scenario where all the A-ER can have a 
consistent algorithm to compute the Aggregated cost.

When it is not possible for all the egress edge routers to have a consistent 
algorithm to compute the aggregated cost or some routers need all the detailed 
IP Layer metrics for the App Servers for other purposes, the raw IP layer 
metrics collected A-ER will be distributed. Only the nodes that are capable of 
utilizing the metrics will process the sub-TLV.

Since only a subset of routers within an IGP domain need to know those detailed 
metrics, the draft used your suggested  OSPFv2 Extended Prefix Opaque LSA for 
IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV to carry the detailed 
sub-TLVs.  For routers that don't care about those metrics, they can ignore 
them very easily.

It worth noting that not all hosts (prefix) attached to an A-ER are ANYCAST 
servers that need network optimization. An A-ER only needs to advertise the 
App-Metrics for the ANYCAST addresses that match with the configured ACLs.

Any other concerns?

Thank you
Linda Dunbar

From: Acee Lindem (acee) 
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: Re: [Lsr] LSR Presentation Slot Requests - IETF111

Speaking as WG member:

Hi Linda,
Even if you've added some IS-IS encodings, the draft still suffers from the 
fundamental problem of the previous draft. If you can't rely on the A-ERs to 
consistently calculate an aggregated metric, how can you rely on all the 
routers in the IGP routing domain to use complex set of metrics to reach the 
least-loaded app server? Do we really want to talk about this again?
Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Cc: "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>
Resent-Date: Monday, July 12, 2021 at 4:27 PM

Yingzhen and LSR Chairs,

We need a 10 minutes slot at IETF111 to present 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C66caea5e0b7243b0d4ce08d94578939b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617206455265464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=VB%2BWjb2Zd%2Fe0iSE8K%2BMCpL%2FbiZYqhS5T2602e2z2cPc%3D=0>
Speaker: Linda Dunbar.

This draft adds the IS-IS extension to the 
draft-dunbar-lsr-5g-edge-compute-ospf-ext-04.

Thank you
Linda Dunbar


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Yingzhen Qu
Sent: Wednesday, June 30, 2021 4:00 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: [Lsr] LSR Presentation Slot Requests - IETF111

Hi all,

The draft agenda for IETF111 has been posted: 
https://datatracker.ietf.org/meeting/111/agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fagenda=04%7C01%7Clinda.dunbar%40futurewei.com%7C66caea5e0b7243b0d4ce08d94578939b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617206455275420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=uhIFfvuGreFkey%2BMO6fmTK52Y%2FmAc7C7Qlrj8FhzvIw%3D=0>.

LSR will have one meeting session: Friday, July 30, 2021 16:00-18:00  Session 
III PDT

Please send slot requests to lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>. 
Please include name of the presenter, pointer to the draft and time estimation 
including Q

Thanks,
Yingzhen

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

Re: [Lsr] LSR Presentation Slot Requests - IETF111

[Linda Dunbar]

Yingzhen and LSR Chairs,

We need a 10 minutes slot at IETF111 to present 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/
Speaker: Linda Dunbar.

This draft adds the IS-IS extension to the 
draft-dunbar-lsr-5g-edge-compute-ospf-ext-04.

Thank you
Linda Dunbar


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Wednesday, June 30, 2021 4:00 PM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org
Subject: [Lsr] LSR Presentation Slot Requests - IETF111

Hi all,

The draft agenda for IETF111 has been posted: 
https://datatracker.ietf.org/meeting/111/agenda<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fagenda=04%7C01%7Clinda.dunbar%40futurewei.com%7C55f2419941004b1a3a5f08d93c0a0ffc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637606836180599918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dZwcpVThpKY1HMdOiEvLi%2FkVpvB8hU%2FbpwoMHoFjBzY%3D=0>.

LSR will have one meeting session: Friday, July 30, 2021 16:00-18:00  Session 
III PDT

Please send slot requests to lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>. 
Please include name of the presenter, pointer to the draft and time estimation 
including Q

Thanks,
Yingzhen

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

[Lsr] Solicit feedback of extending the Application Specific Link Attribute (RFC8919) for distributing Site-Cost for 5G Edge Computing Servers

[Linda Dunbar]

LSR WG,

We added IS-IS extension to draft-dunbar-lsr-5g-edge-compute-ospf-ext-04, 
therefore changed the draft name to draft-dunbar-lsr-5g-edge-compute-ext-00.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/

We would like to get feedback on our proposed IS-IS extension:

The Application-Specific Link Attribute sub-TLV described in [RFC8919] can be 
used to carry the "Site-Cost" for the App server directly attached to the 
router.
When carrying the "Site-Cost" sub-sub TLVs, the App specific Link Attribute 
sub-TLV can be included in TLV 22 (extended IS reachability), 23 (IS Neighbor 
Attribute), or 25(L2 bundle Member Attribute).
The Site-Cost bit is added to the Standard Applications Bit Mask (SABM).
0 1 2 3 4 5 6 7 ...
+-+-+-+-+-+-+-+-+...
|R|S|F|C| ...
+-+-+-+-+-+-+-+-+...

C-bit: set to specify the Site Cost related sub-sub TLVs  are included in the 
App-Specific Sub-TLV.

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

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Gyan,

You said:
 Gyan>  The Anycast environments that I have worked with architecture have been 
server clusters in data centers geographically diverse that sit behind a load 
balancer that uses a concept called HRI host route injection that if the 
service is up the VIP is BGP advertised for the cluster to DC core and then 
services VIP host route are advertised into the core all BGP attributes equal 
so lowest IGP metric tie breaker picks best path shortest path across the core  
as best path and of iBGP multipath is used that services VIPs are 
geographically load balanced flow based if metric is a tie and if IPv6 is used 
in the core then 5-tuple per flow load balanced optimized.
The "cluster of servers" in your paragraph  is considered as ONE (address) in 
In draft-dunbar-lsr-5g-edge-compute-ospf-ext. Only the ADDRESS (or the VIP) of 
the cluster is visible to the network. How the App Load Balancer distribute the 
traffic to individual servers is not visit to network.

You said:
Gyan>  With Anycast routing as I mentioned you don't have a single point of 
failure and really have optimal redundancy which is why for any services such 
as DNS, NTP and many others Anycast is the best most redundancy and optimal as 
proximity routing is used.
[Linda] Are you saying using VIP to achieve the "Anycast routing" ?
Using a  VIP for multiple  clusters of servers requiring all those clusters of 
servers to be attached to a common device, such as a NAT or a GW router.  The 
"single point failure and bottleneck" is referring to the NAT or the GW router.
5G EC needs the multiple clusters of servers to be placed in different mini 
Edge-DCs.  And desire to use the same IP address for those clusters of servers 
attached to different egress routers.
Gyan>  If your closest lowest IGP metric iBGP load balanced path goes down 
let's say multiple DC outages you still have your next closest in the BGP path 
list pecking order to reach the service thus optimized redundancy as every DC 
would have to be down for service VIP to be down.  Also with Anycast as it a 
distributed architecture you are not overloading core paths or certain DC VIPs 
as all traffic is distributed geographically proximity load balanced 
automatically.  So there is a lesser chance of bottleneck as the Anycast 
architecture is distributed.
[Linda] Yes, when multiple clusters of servers are attached to different 
routers, the IGP metric and iBGP load balanced path can select the optimal one.

The  draft-dunbar-lsr-5g-edge-compute-ospf-ext adds another component into 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-lsr-flex-algo-bw-con-01=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf137baecd8394d51827908d8e451643f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637510385527216760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ajhSjizE8O6QiSTy1fUFe%2Bxy6%2FIHKeX3QdKomZaVByo%3D=0>,
 i.e. the "Load to reach the cluster"  which is influenced by  "site-capacity + 
load measurement + Preference + xxx". The "Load to reach the cluster" can be 
the raw measurements collected by the egress routers based on the instruction 
from a controller, or informed by the App Controller periodically.

I don't see  any conflicts to the 
https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hegde-lsr-flex-algo-bw-con-01=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf137baecd8394d51827908d8e451643f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637510385527216760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ajhSjizE8O6QiSTy1fUFe%2Bxy6%2FIHKeX3QdKomZaVByo%3D=0>,
 am I missing anything?

Thanks, Linda Dunbar

From: Gyan Mishra 
Sent: Wednesday, March 10, 2021 11:49 PM
To: Linda Dunbar 
Cc: Christian Hopps ; Liyizhou ; 
lsr@ietf.org
Subject: Re: [Lsr] Why not leverage Network conditions to optimize balancing 
among multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext

Hi Linda

Comments in-line

On Wed, Mar 10, 2021 at 6:46 PM Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:
Gyan,

To a router, having multiple servers with the same (ANYCAST) address attached 
to different egress routers (A-ER) is same as having multiple paths to reach 
the (ANYCAST) address.

You are absolutely correct that there are many tools to influence the path 
section, such as the routing distance, TE metrics, policies, etc.

draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add another component to 
influence the path selection: the "Site-Cost"  which is influenced by  
"site-capacity + load measureme

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Gyan,

To a router, having multiple servers with the same (ANYCAST) address attached 
to different egress routers (A-ER) is same as having multiple paths to reach 
the (ANYCAST) address.

You are absolutely correct that there are many tools to influence the path 
section, such as the routing distance, TE metrics, policies, etc.

draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes to add another component to 
influence the path selection: the "Site-Cost"  which is influenced by  
"site-capacity + load measurement + Preference + xxx". The "site-Cost" can be 
raw measurements collected by the egress routers based on the instruction from 
a controller, or informed by the App Controller periodically.

In the past, ANYCAST has been predominantly used for multiple servers in 
geographically far apart locations so that routing distance alone can always 
nail down to one specific ANYCAST server.

3GPP TR23.748 (5G Edge Computing) is proposing to use multiple servers (or 
multiple App Layer Load Balancers) with the same ANYCAST address in their Local 
IP Data Network to avoid the single point of failure and the bottleneck at the 
App Layer Load Balancer for mission critical applications.

Thank you very much for your comments. I have made some changes to the text. 
Please see the revision: 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/


Linda

From: Gyan Mishra 
Sent: Tuesday, March 9, 2021 12:08 AM
To: Liyizhou 
Cc: Christian Hopps ; Linda Dunbar 
; lsr@ietf.org
Subject: Re: [Lsr] Why not leverage Network conditions to optimize balancing 
among multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext

Linda and authors

Some thoughts regarding load balancing draft.

Anycast in my experience has been used predominantly in my experience within 
operators networks with BGP overlay,  using BGP best path selection and most 
cases boils down to lowest IGP metric tie breaker shortest path for the service 
Anycast proximity route which you can also with unique RD in overlay and can 
take advantage of iBGP multipath equal cost load balancing over an operator 
vaccine or 4G/5G RAN xhaul or internet.

The nice thing about Anycast with BGP overlay you as are automatically 
proximity based routing load balancing inherent to Anycast routing.

Point here is we are using BGP best path selection but it does boils down to 
IGP lowest metric tie breaker but you can use iBGP multipath to further 
optimize the routing for cloud computing.

We have so many tools in our operators toolbox to optimize routing SR or 
Flex-Algo, SDN etc am wondering if some form of SDN or SD-WAN overlay could 
provide the Dyncast type Dynamic Anycast solution.

I want to the wiki page for Dyncast.  The presentation is not available yet.  
Will check tomorrow.

Thanks

Gyan


On Mon, Mar 8, 2021 at 11:36 PM Liyizhou 
mailto:liyiz...@huawei.com>> wrote:
Hi,

Sorry to chime in.

There are certainly some higher layer application/protocols to employ. At the 
same time, there are some advantages of network layer approaches as well in my 
mind.

When talking about edge computing, there are some unique characteristics. The 
number of edge sites could be large or huge in future in a big city. Edges are 
geographically scattered which could be a few, or tens of, or a hundred 
kilometers away from each other, and each site has limited computing resources 
which could be a small cluster. Application layer based approach normally would 
rely on one or several "server"/"broker" to be responsible for request handling 
all over the city. As such "servers" are unlikely available on each and every 
edge site, it introduces additional path stretch for data packets requiring 
delivery to other edge sites first. Such path stretch introduces additional 
(network and processing) delay which could be crucial for short live request 
flow. On the contrary, the network node at the edge is naturally sitting on the 
data path without introducing any additional cost to direct the 
(explicit/implicit) request somewhere else. Also routing system has been proven 
doing good in such distributed manner.


There is a dyncast (dynamic anycast) work ongoing. It is not exactly same as 
what Linda proposed here, but some relations can be seen, like trying to use 
anycast methodology to access an edge computing, especially computational 
intensive, service. The current discussions are about compellingness of the use 
cases, the deficiency of existing solutions, and proposed architecture, not 
gone very far into what specific routing protocols to use yet. A side meeting 
will be held on Wed 10am CET. You may check 
https://github.com/dyncast/ietf110<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdyncast%2Fietf110=04%7C01%7Clinda.dunbar%40futurewei.com%7C090a578c2711455d431808d8e2c1ad0b%7C0f

Re: [Lsr] Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

[Linda Dunbar]

Acee,

Thank you very much for your comments.
Answers are inserted below.

Linda
From: Acee Lindem (acee) 
Sent: Monday, March 8, 2021 2:12 PM
To: draft-dunbar-lsr-5g-edge-compute-ospf-...@ietf.org
Cc: lsr@ietf.org
Subject: Comments on draft-dunbar-lsr-5g-edge-compute-ospf-ext-03

Speaking as WG member:

Hi Linda and Co-authors,

My first major comment is the confusion with the usage of multiple anycast 
addresses for the same application. Why are you requiring multiple anycast 
address? It would seem the load balancing over multiple servers can be done at 
the data center layer. I guess a UE would use the same anycast address for an 
application based on the initial DNS query? It is very confusing.

[Linda] Yeh, agree with you. It is kind of confusing.  That was one of the 
proposed solutions  in  3GPP’s TR23.748.
With OSPF periodically advertising the reachability to the ANYCAST servers, all 
routers should automatically switch to an alternative location for the ANYCAST 
server.
 I will remove the Section 6 in the next revision.

My second major comment is that in section 4, you point out that an aggregated 
metric would solve the problem. However, the purported downside is that all the 
Application Egress Routers (A-ERs) would need to use the same algorithm to 
aggregate the various capacity measurements into a single metric. It would seem 
to be an even larger obstacle for all the OSPF routers in the area to support 
these new metrics and consistent routing based on those metrics.

[Linda] Agree with you. The solution is only useful for a small controlled 
network, for example,  the Application Function Controller could send the 
“aggregated cost” to the egress routers periodically.
Even though the solution description described in the Section 4 has very 
limited usage, I feel it is important to include it in the draft.
I change the text to the following

“If all egress routers that have direct connection to the App Servers can get 
periodic update of the aggregated cost to the App Servers or can be configured 
with a consistent algorithm to compute an aggregated cost that take into 
consideration the Load Measurement, Capacity value and Preference value, this 
aggregated cost can be considered as the Metric of the link to the App Server.
In this scenario, there is no protocol extension needed.”

Also, some minor comments:


  1.  Why do you talk about ACLs to determine the anycast addresses? 
Presumably, you wouldn’t even have these metrics available for other addresses.
[Linda]  There could be large number of addresses attached to each Egress 
router. The egress routers only need to measure the “Running Environment” for 
the addresses filtered by the ACLs.


  1.  Section 5 still references the misguided 
draft-wang-lsr-passive-interface-attribute draft. I believe you meant to remove 
this.
[Linda] AiJun has answered this question.

There are other nits as well but it doesn’t make sense to spend time on them at 
this stage.

Thanks,
Acee


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

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Christian,

If “network fails”, the packets won’t even get into the desired App Server (or 
App Layer Load Balancer).
What the draft has proposed is to add a “Tie breaker” or additional weight to 
the “Best Path” selection by  BGP/IGP.

There is definitely interaction among the Application Function Controller (AF) 
and the network. The Load measurement can be advertised to the AF which can 
perform dynamic analysis and send back more accurate value for the “Site 
preference” to the routers. But they are out of the scope of this draft.

[cid:image003.png@01D714A7.8CDF3010]


Optimizing the ANYCAST for 5G EC is a concrete use case for Dynamic ANYCAST 
initiative. While the Dynamic ANYCAST is for bigger network, the 5G EC 
optimization is for smaller 5G Local Data Network.

Linda

From: Christian Hopps 
Sent: Monday, March 8, 2021 6:00 PM
To: Linda Dunbar 
Cc: Christian Hopps ; lsr@ietf.org
Subject: Re: Why not leverage Network conditions to optimize balancing among 
multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext




On Mar 8, 2021, at 7:40 PM, Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:

Christian,

You said at LSR session today that there might be concern of network optimizing 
ANYCAST traffic to better balance among multiple App Layer Load Balancers.
First of all, only the Applications that need to leverage the network condition 
to balance among their multiple Load Balancers will get the benefit of path 
selection that are based on the combination of routing distance and other 
dynamic running status. The networks (e.g. 5G EC Local Data Networks)  only 
optimize the ANYCAST traffic for the registered addresses.
The network is already responsible for selecting the shortest path to one 
Application Load Balancer. draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes 
to add additional weight in path selection.

ANYCAST makes it possible to dynamically load balance across server locations 
based on network conditions. With multiple servers having the same ANYCAST 
address, it eliminates the single point of failure and bottleneck at the 
application layer load balancer that has the shortest routing distance. Another 
benefit of using ANYCAST address is removing the dependency on how UEs get the 
IP addresses for their Applications. Some UEs (or clients) might use stale 
cached IP addresses for extended period.

Network service providers can even offer this as a value added service, making 
network information more useful to deliver services to applications.
Isn’t it a win-win approach for both network service providers and the 
applications owners?

As WG member,

It's not a win when their network fails.

At a high level I think the idea of a smart network is interesting. I don't 
have good initial feelings though about trying to achieve that by adding 
application load based metrics into the routing protocol. There's all sort of 
layer violations going on there for one, but perhaps more importantly, our 
routing protocols have not been tried and tested over the decades with this use 
in mind.

One could imagine designing a higher layer distributed load balancing 
application/protocol that utilized routing information though, something like 
that would align more closely with the layering we've been designing to all 
these years. It probably would not rely on anycast exclusively, but instead use 
anycast to talk to a server that implemented this LB protocol (something 
anycast is good at) which would provide a unicast address for the requested 
application, with the ability to adjust (reacquire a new unicast address, 
whatever) as conditions (either at the routing or application layer) change 
through notifications or polling. Just brainstorming here, but there are lots 
of ways one could imagine this working.

Thanks,
Chris.



Linda Dunbar

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

[Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Christian,

You said at LSR session today that there might be concern of network optimizing 
ANYCAST traffic to better balance among multiple App Layer Load Balancers.
First of all, only the Applications that need to leverage the network condition 
to balance among their multiple Load Balancers will get the benefit of path 
selection that are based on the combination of routing distance and other 
dynamic running status. The networks (e.g. 5G EC Local Data Networks)  only 
optimize the ANYCAST traffic for the registered addresses.
The network is already responsible for selecting the shortest path to one 
Application Load Balancer. draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes 
to add additional weight in path selection.

ANYCAST makes it possible to dynamically load balance across server locations 
based on network conditions. With multiple servers having the same ANYCAST 
address, it eliminates the single point of failure and bottleneck at the 
application layer load balancer that has the shortest routing distance. Another 
benefit of using ANYCAST address is removing the dependency on how UEs get the 
IP addresses for their Applications. Some UEs (or clients) might use stale 
cached IP addresses for extended period.

Network service providers can even offer this as a value added service, making 
network information more useful to deliver services to applications.
Isn't it a win-win approach for both network service providers and the 
applications owners?

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

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

[Linda Dunbar]

I support the WG Adoption of this draft.
This information draft describes how RFC5305, RFC8570 are used to advertise 
topology specific TE attributes, and SR VTN resource attribute. it is useful.


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

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

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

Thanks,
Acee


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

[Lsr] Request a 10 minute slot at IETF110 LSR session to brief the draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Acee, Christian, and YingZhen,

Can we have a 10-minutes slot at the IETF 110 LSR session to brief the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ ?


Based on the mailing list discussion, we have revised the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/.

In particular,

  *   For App Servers using IPv6, the OSPFv3 Extended LSA with the 
Intra-Area-Prefix Address TLV specified by the Section 3.7 of RFC8362 can be 
used to carry the App-Metrics for the attached App Servers.
  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7 (IPv6 Local-Local Address)   |   Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 AppServer (ANYCAST) address   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Load measurement sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Capability sub-TLV |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 3: IPv6 App Server App-Metrics Encoding


  *   For App Servers using IPv4 addresses, the OSPFv2 Extended Prefix Opaque 
LSA with the extended Prefix TLV can be used to carry the App Metrics sub-TLVs, 
as specified by the Section 2.1 [RFC7684].

Here is the proposed encoding:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Your comments and suggestions are greatly appreciated.

Linda Dunbar

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR

Re: [Lsr] More responses required [Re: WG adoption call for draft-acee-lsr-isis-yang-augmentation-v1-03]

[Linda Dunbar]

Hi Chris and all,

I support the adoption.

Best,
Linda Dunbar

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Friday, January 22, 2021 9:13 PM
To: lsr@ietf.org
Cc: Christian Hopps ; lsr-cha...@ietf.org
Subject: [Lsr] More responses required [Re: WG adoption call for 
draft-acee-lsr-isis-yang-augmentation-v1-03]

Hi Folks, so far we've received only a single feedback on adopting this 
document, can we get a few more responses form the WG?

Thanks,
Chris.

> On Jan 5, 2021, at 4:19 AM, Christian Hopps  wrote:
> 
> Signed PGP part
> This begins a 2 week WG adoption call for the following draft:
> 
>  
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2Fdata=04%7C01%7Clinda.dunbar%40futurewei.com%7Cdb8fde278bed4ff0bf2c08d8c19c4a82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637472224315571581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PvsCLIpMB4Mf9JNPVbywAIEKuAgGWNaS1nhU1NiwsvI%3Dreserved=0
> 
> Please indicate your support or objection by January 19th, 2021.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Thanks,
> Chris.
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Clinda.dunbar%40futurewei.com%7Cdb8fde278bed4ff0bf2c08d8c19c4a82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637472224315571581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9Eg%2FMJ2bJZwbomNE082zWqar4Fuvt4LLWQVspOCAFaY%3Dreserved=0

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

[Lsr] Revised draft-dunbar-lsr-5g-edge-compute-ospf-ext to associated the property with the Prefix (RFC7684) instead of the Stub Link

[Linda Dunbar]

Acee and LSR WG,

Based on the mailing list discussion, we have revised the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/.

In particular,

  *   For App Servers using IPv6, the OSPFv3 Extended LSA with the 
Intra-Area-Prefix Address TLV specified by the Section 3.7 of RFC8362 can be 
used to carry the App-Metrics for the attached App Servers.
  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7 (IPv6 Local-Local Address)   |   Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 AppServer (ANYCAST) address   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Load measurement sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Capability sub-TLV |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 3: IPv6 App Server App-Metrics Encoding


  *   For App Servers using IPv4 addresses, the OSPFv2 Extended Prefix Opaque 
LSA with the extended Prefix TLV can be used to carry the App Metrics sub-TLVs, 
as specified by the Section 2.1 [RFC7684].

Here is the proposed encoding:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Your comments and suggestions are greatly appreciated.

Linda Dunbar

From: Acee Lindem (acee) 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewe

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Anjun,

Replies to your concerns and questions are inserted below:

From: Aijun Wang 
Sent: Thursday, December 17, 2020 12:38 AM
To: Linda Dunbar ; 'Acee Lindem (acee)' 
; 'Jeff Tantsura' ; 
'Yingzhen Qu' ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Linda:

Scenario 1 is straightforward and is the local decision of the router. Do we 
need the draft then?
[Linda] Yes, Scenario 1 is straight forward. There is a short description just 
to make people aware this option.

For scenario 2, I am considering where is the right place to place such 
information. The consideration in my previous mail is not addressed.
[Linda] Yes, it is possible that multiple App Servers share the same Capacity 
Index. But the  site preference might be different and the Load Measurement 
might be different. Even if you use Stub link to advertise those attributes, 
you might need one LSA per prefix.

It seems RFC8362 does not illustrate which "OSPFv3 Extended-LSA Sub-TLVs" 
(https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fospfv3-parameters%2Fospfv3-parameters.xhtml%23extended-lsa-sub-tlvs=04%7C01%7Clinda.dunbar%40futurewei.com%7C96a95de957c9402de90108d8a256544b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637437839094856866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=9ZuDNNa4WD6W1WNG%2B%2Fr8axCpO9XTRIpm5lEWuA%2BFpQM%3D=0>)
 should be put into which "OSPFv3 Extended-LSA TLVs"?

[Linda] The proposed Sub-TLV types need to be added by IANA to OSPFv4 
Extended-LSA Sub-TLVs and OSPFv2 Extended Link Opaque LSA TLVs Registry.

Linda

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Linda Dunbar
Sent: Thursday, December 17, 2020 11:09 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Jeff Tantsura' mailto:jefftant.i...@gmail.com>>; 
'Yingzhen Qu' mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Aijun,

Thank you for the analysis and suggestions.

The draft specified 3 Sub-TLVs to carry the IP Layer Metrics to Gauge App 
Server Running Status: Load Measurement; Capacity Index; and Preference Index. 
More may be added in the future, especially when there are more information 
about UEs and their flows that can be passed from 5G Network Exposure Functions.

Let's consider two different scenarios:

Scenario 1:

All the Egress routers to which the App Servers are attached can be configured 
with a consistent algorithm to compute an aggregated cost that take into 
consideration of Load Measurement, Capacity value and Preference value. Then 
this aggregated cost can be encoded in the Metric field [the interface cost] of 
Intra-Area-Prefix-LSA for  IPv6 [ RFC5340], or  encoded in the "Metric" field 
of the Stub Link LSA [Link type =3] [RFC2328] for IPv4.

In this scenario, there is no protocol extension needed, but requires all 
egress routers to agree upon a consistent algorithm to compute the cost to the 
App server (Prefix)



Scenario 2:

Either it is not possible for all the egress routers to have a consistent 
algorithm to compute the aggregated cost, or the ingress routers need all the 
detailed IP Layer metrics for the App Servers for other purposes. Then, the IP 
Layer Metrics to Gauge App Server running status need to be encoded in LSAs to 
other nodes. Under this scenario, it makes sense to use the OSPFv2 Extended 
Prefix Opaque LSA for IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV 
to carry the detailed sub-TLVs proposed in the draft, so that nodes that don't 
care about those metrics can ignore them very easily.



For OSPFv2 Extended Prefix Opaque LSA or OSPFv3 Extended LSA, the receiving 
nodes, who care about the information, have to adjust path compute engine 
anyway to derive the lowest cost path that takes the IP Layer Metrics into 
consideration.

Do you agree with this approach?

We will revise the draft to reflect those two different scenarios.


Linda



From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, December 15, 2020 9:45 PM
To: 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>; 
'Jeff Tantsura' mailto:jefftant.i...@gmail.com>>; 
'Yingzhen Qu' mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailt

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Aijun,

Thank you for the analysis and suggestions.

The draft specified 3 Sub-TLVs to carry the IP Layer Metrics to Gauge App 
Server Running Status: Load Measurement; Capacity Index; and Preference Index. 
More may be added in the future, especially when there are more information 
about UEs and their flows that can be passed from 5G Network Exposure Functions.

Let's consider two different scenarios:

Scenario 1:

All the Egress routers to which the App Servers are attached can be configured 
with a consistent algorithm to compute an aggregated cost that take into 
consideration of Load Measurement, Capacity value and Preference value. Then 
this aggregated cost can be encoded in the Metric field [the interface cost] of 
Intra-Area-Prefix-LSA for  IPv6 [ RFC5340], or  encoded in the "Metric" field 
of the Stub Link LSA [Link type =3] [RFC2328] for IPv4.

In this scenario, there is no protocol extension needed, but requires all 
egress routers to agree upon a consistent algorithm to compute the cost to the 
App server (Prefix)



Scenario 2:

Either it is not possible for all the egress routers to have a consistent 
algorithm to compute the aggregated cost, or the ingress routers need all the 
detailed IP Layer metrics for the App Servers for other purposes. Then, the IP 
Layer Metrics to Gauge App Server running status need to be encoded in LSAs to 
other nodes. Under this scenario, it makes sense to use the OSPFv2 Extended 
Prefix Opaque LSA for IPv4 and OSPFv3 Extended LSA with Intra-Area-Prefix TLV 
to carry the detailed sub-TLVs proposed in the draft, so that nodes that don't 
care about those metrics can ignore them very easily.



For OSPFv2 Extended Prefix Opaque LSA or OSPFv3 Extended LSA, the receiving 
nodes, who care about the information, have to adjust path compute engine 
anyway to derive the lowest cost path that takes the IP Layer Metrics into 
consideration.

Do you agree with this approach?

We will revise the draft to reflect those two different scenarios.


Linda



From: Aijun Wang 
Sent: Tuesday, December 15, 2020 9:45 PM
To: 'Acee Lindem (acee)' ; 'Jeff Tantsura' 
; 'Yingzhen Qu' ; 
lsr@ietf.org; lsr-cha...@ietf.org; Linda Dunbar 
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Acee and Linda:

The mentioned information in this draft are more related to the links that 
connect the server to the edge router, than to the prefix of the app server.
For example, the "Capacity Index", "Preference Index" are all related to the 
site, not the prefix.
And, for "Load Measurement", it is not enough to detect only the load to the 
server, but omits the load status of the link that connected the servers.
We should also considering the future possible extension, such as the bandwidth 
reservation on these links to the App server etc.

In conclusion, associate these attributes to the link is more reasonable than 
to the prefix.
Such links are another typical use case of passive/stub link within the network.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Thursday, November 5, 2020 8:42 AM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Exactly.
Thanks,
Acee

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:
Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf2827d041dc345cee04d08d8a174e7fe%7C

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Aijun,

I read through your draft, need to clarify a few things:


  1.  Is your “Passive Link” same as the “Stub Link”?
  2.  Are you suggesting that the “Passive Link” to be advertised less often 
than the regular LSA?

Thank you,

Linda

From: Aijun Wang 
Sent: Thursday, November 5, 2020 7:35 PM
To: Linda Dunbar ; 'Acee Lindem (acee)' 
; 'Peter Psenak' ; 'Jeff 
Tantsura' ; 'Yingzhen Qu' ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Linda, Acee, Jeff and Peter:

From this use case, together with another 
draft(https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-passive-interface-attribute%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf8b544146d184bfe98fa08d881f42cb5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402233049926010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=UUGE%2F6VXzQTnAYEqHq8y91zfRlorFitl9wpF5lqiSqI%3D=0>)
 that we are proposing and discussing, as in 
https://mailarchive.ietf.org/arch/msg/lsr/imojDOsS3W3B2H2SbmUT0QKjbxM/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flsr%2FimojDOsS3W3B2H2SbmUT0QKjbxM%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf8b544146d184bfe98fa08d881f42cb5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402233049926010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=yYJ1hceIJEGByWaTha6PjowYkoa0Hbsn0Ekup2pRCpk%3D=0>
It is more convincible to define one new top TLV, for example, Stub-Link TLV, 
to contain your current proposed sub-TLV, and other futures information.

The information contained within the Stub-Link TLV, will not participate the 
SPF calculation on each router.
It is more clear than to put this information associated with the Prefix TLV.


Best Regards

Aijun Wang
China Telecom


From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, November 6, 2020 12:04 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Jeff and Acee,

I understand that RFC8362 has specifies Extended Prefix TLV for IPv6.

Since there are two separate RFCs for the Extended Prefix TLV, one for IPv4 and 
another one for IPv6,  I was asking if the Sub-TLVs proposed for 5G Edge 
Computing needs to have two separate drafts: one for IPv4 and another one for 
IPv6?   Or just one draft to describe the extension to both RFCs?

Your guidance is greatly appreciated.

Linda

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 4, 2020 6:42 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Exactly.
Thanks,
Acee

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:
Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7Cf8b544146d184bfe98fa08d881f42cb5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402233049936011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Aijun,

There are three Metrics to be collected for 5G Edge Computing servers, to be 
carried by the three corresponding  Sub-TLVs proposed by the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/


  *   IP-Layer Metric for App Server Load Measurement:

Two types of Load Measurement Sub-TLVs are specified. One is to carry the 
aggregated cost Index based on weighted combination of the collected 
measurements; another one is to carry the raw measurements of packets/bytes 
to/from the App Server address. The raw measurement is useful when the egress 
routers cannot be configured with a consistent algorithm to compute the 
aggregated load index and the raw measurements are needed by a central analytic 
system.


  *   Capacity Index

Capacity Index is used to differentiate the running environment of the 
application server. Some data centers can have hundreds, or thousands, of 
servers behind an Application Server’s App Layer Load Balancer that is 
reachable from external world. Other data centers can have very small number of 
servers for the application server. “Capacity Index”, which is a numeric 
number, is used to represent the capacity of the application server in a 
specific location.



  *   Site preference index:
[IPv6-StickyService] describes a scenario that some sites are more preferred 
for handling an application than others for flows from a specific UE.

The Update frequency for the 3 sub-TLVs can be different. The Site Preference 
Index and the Capacity Index should be in the same frequency as the Extended 
Prefix TLV because as the Application Server Prefix changes, their 
corresponding Site Preference and the Capacity Index would change as well.
The Update frequency for the Load Measurement should be high to reflect the 
running load of the App servers. Currently, default is 3600 seconds, but can 
also be a user specified period in seconds.


Any other suggestions or comments?

Linda Dunbar

From: Aijun Wang 
Sent: Thursday, November 5, 2020 7:21 PM
To: Linda Dunbar ; 'Acee Lindem (acee)' 
; 'Yingzhen Qu' ; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests


Hi, Linda:

For example,
What’s the update frequency of the App server status data?  Will it influence 
the SPF efficiency on each flooding router etc.?


Best Regards

Aijun Wang
China Telecom

From: Linda Dunbar [mailto:linda.dun...@futurewei.com]
Sent: Friday, November 6, 2020 12:57 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Acee Lindem (acee)' mailto:a...@cisco.com>>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Ai Jun,

Can you elaborate more on your proposed “analysis for the flooding influences”?

Thank you very much.

Linda

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 4, 2020 8:03 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 'Acee Lindem 
(acee)' mailto:a...@cisco.com>>; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Linda:

Is it better to add some analysis for the flooding influences on the router 
performance when we add such dynamic information within the IGP protocol?


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, November 5, 2020 6:44 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C2f1c51ec07de4cfced5908d881f22dc4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637402224453498580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=d%2B5SQkJSd40ykZDu

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Ai Jun,

Can you elaborate more on your proposed “analysis for the flooding influences”?

Thank you very much.

Linda

From: Aijun Wang 
Sent: Wednesday, November 4, 2020 8:03 PM
To: Linda Dunbar ; 'Acee Lindem (acee)' 
; 'Yingzhen Qu' ; lsr@ietf.org; 
lsr-cha...@ietf.org
Subject: RE: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Hi, Linda:

Is it better to add some analysis for the flooding influences on the router 
performance when we add such dynamic information within the IGP protocol?


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, November 5, 2020 6:44 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C3afd55a40224461f77eb08d8812edd22%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637401385584020792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=Pz2aNEDCPc2A1tyT1BZg6Hnt%2BoQk802pB19SQY0l4AY%3D=0>
 proposes the extension to LSA that can carry the three SubTLVs that are used 
to represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:

Ø  Load measurement sub-TLV
Ø  Capacity Index  Sub-TLV
Ø  Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar


From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the appl

Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Jeff and Acee,

I understand that RFC8362 has specifies Extended Prefix TLV for IPv6.

Since there are two separate RFCs for the Extended Prefix TLV, one for IPv4 and 
another one for IPv6,  I was asking if the Sub-TLVs proposed for 5G Edge 
Computing needs to have two separate drafts: one for IPv4 and another one for 
IPv6?   Or just one draft to describe the extension to both RFCs?

Your guidance is greatly appreciated.

Linda

From: Acee Lindem (acee) 
Sent: Wednesday, November 4, 2020 6:42 PM
To: Jeff Tantsura ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org; Linda Dunbar 

Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

Exactly.
Thanks,
Acee

From: Jeff Tantsura mailto:jefftant.i...@gmail.com>>
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem mailto:a...@cisco.com>>, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar 
mailto:linda.dun...@futurewei.com>>, wrote:
Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C5c9f2260a6984c7cdfbc08d88123af6d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637401337583331433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=bRU%2BTD46TwVTPym%2B3Xolyd5vtZhx62Hd9m1XOerHb1I%3D=0>
 proposes the extension to LSA that can carry the three SubTLVs that are used 
to represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:

 • Load measurement sub-TLV
 • Capacity Index  Sub-TLV
 • Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar


From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partiall

[Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
proposes the extension to LSA that can carry the three SubTLVs that are used to 
represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:


  *   Load measurement sub-TLV
  *   Capacity Index  Sub-TLV
  *   Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type  | Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar


From: Acee Lindem (acee) 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C83f990f38fe14407efe208d880300245%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637400290992237706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=CooHUjUYe%2BePz9rwBZe0orzPqku%2BoSL%2FrMVVa%2Fl2uIc%3D=0>

This draft describes an OSPF extension that can distribute the 5G Edge 
Computing App running status and environment, so that other routers in the 5G 
Local Data Network can make intelligent decision on optimizing forwarding of 
flows from UEs. The goal is to improve latency and performance for 5G Edge 
Computing services.

[Lsr] 5G Edge -Computing Solution drafts can be used for Dyncast (dynamic anycast) use cases

[Linda Dunbar]

Yi Zhou, Liang, Peng, and Peter,

We have 4 IETF drafts describing the different aspect of the solutions to 5G 
Edge computing, which can cover your use cases and requirement described in 
draft-geng-rtgwg-cfn-dyncast-ps-usecase:

Through working on the 3GPP Release 17’s 5G Edge Computing project (3GPP 
TR23.748), we noticed that IP Layer can do more to optimize the 5G Edge 
computing services.

https://datatracker.ietf.org/doc/draft-dunbar-ippm-5g-edge-compute-ip-layer-metrics/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1yyVDIoM4pRjqoaLcFtGBohA3Our0GjTsZTI_OhhRqrwPug8uB8BZCGk2WVCYZmJMutbzptopfG2ACz4AxfZxeUgnDWbBu1hcHyGnNbsDXzkStp9bntK0rpjjQPBgg-1jY8eRWaAcB_V85O45nB_MzOBkHjs9r0q1sGjDHKPhx7WjEaZgiAzZ4IsIMfmKhXFfCy_LUF9yMT24QsWdp66L9H5a1h0hA_940C_gOSIQDClYCc_3NcAcy2w665SAxX4zkbf9KrUNoa2w1tIurssNadIg0Miqo-Q9jwqwCGrZhRa3Zf94d0HVx-aI4KJrBQi3%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-ippm-5g-edge-compute-ip-layer-metrics%252F=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903951448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=1oMRUMShQ8Q8fA9JDhv7pyDVLRPpKamyqLvNHMb51qU%3D=0>
 describes the IP Layer metrics and methods to measure the Edge Computing 
Servers running status and environment for IP networks to select the optimal 
Edge Computing server location in 5G Edge Computing (EC) environment. This 
document also describes the method of incorporating those measurements with IP 
routing cost to come up with a more optimal criteria in selecting ANYCAST 
locations.

https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F10q2K1AolUwnJQxE-1zdp20SZ9dJ4nGbrfheOMCk6FhMP7cll-lnH4Ele1vAAkXjvGYaXHnAl_WGczRan0zDSIF25BUg7bs9aWtE1gnvQvPt8_qGMdw5gmM3jpAWOXC6_N_neane1LGU-tFdSie6E94aD3LmVxBQnkkB_qnp3glPLwHgMYiU3hGmAJ_yuBK1a2SBOFdr3VmeUxXESfiXy-k0CflGKYdeAnYHNoIGMvbqPWVpWhjEVqqxUpLISwkvVznxIeTcYl6IGePA_y9uGFwvnl_jqU3tClFSPvy1DDEp12JvdoAa6ygDA_rvVmbfW%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-6man-5g-edge-compute-sticky-service%252F=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=2cZoGaNIOEVm6twNUFp9aBP%2BYDbWnhEQrPYVVL8Alrg%3D=0>
 describes a solution of using IPv6 extension header to help Ingress router to 
stick traffic from a UE to the original App Server when the UE moves from one 
5G Site to another.

https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/
 describes a new BGP Network Layer Reachability Information (BGP NLRI) Path 
Attribute, AppMetaData, that can distribute the 5G Edge Computing App running 
status and environment, so that other routers in the 5G Local Data Network can 
make intelligent decision on optimized forwarding of flows from UEs. The goal 
is to improve latency and performance for 5G Edge Computing services. The 
extension enables a feature, called soft anchoring, which makes one Edge 
Computing Server at one specific location to be more preferred than others for 
the same application to receive packets from a specific source (UE).

https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecure-web.cisco.com%2F1pN4xFsbZmNhUqdhLGnTREMAj8uivXtc4wzAe5JqGqd4rZrJsKGRniQQp0KpmomwEWdnRGFimTXd3kCsWrCfJZK1_IK7-mzNZpLXCnmLbwhM011N3KS_V9ZTbJBsQCpIAz2Se2NJ7c77M8n1w1vTCMA3Mmv9L5yO4SlFI32zj70F_87C-scozGGga61PK-wDmL2JV_2BVvpfnK0YA0ez8WpbnSvQZQsks3bCUl7SQxG2IcuZI4PxNLhA2Y_22SSoaankWjg0sU58se1h4tDt7SrAao_ZcFqSTge-iZYmOyFN996wqXhPh5ZLzGa52Gh2j%2Fhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%252F=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a45f19804e4ec83d4508d87bea9dc6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637395594903961443%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Qb1rHSngDnQYOSDfVH5xyCRnZ9U2WoQ3knWGrUDNcm8%3D=0>
 describe OSPF extension for the Routers that collect the IP Layer Metrics to 
propagate to all other routers.

Please let us know if the proposed solutions can solve your use cases.

Thank you
Linda Dunbar



From: rtgwg mailto:rtgwg-boun...@ietf.org>> On Behalf 
Of Liyizhou
Sent: Monday, November 2, 2020 1:17 AM
To: rt...@ietf.org<mailto:rt...@ietf.org>
Cc: Lifeng (Frank) mailto:frank.lif...@huawei.com>>; 
Peng Liu mailto:liupeng...@chinamobile.com>>; 
gengli...@chinamobile.com<mailto:gengli...@chinamobile.com>
Subject: Dyncast (dynamic anycast)

Hi folks,

We submitted two drafts about dyncast (dynamic anycast)

[Lsr] Need 10 minute slot to discuss OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

[Linda Dunbar]

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/

This draft describes an OSPF extension that can distribute the 5G Edge 
Computing App running status and environment, so that other routers in the 5G 
Local Data Network can make intelligent decision on optimizing forwarding of 
flows from UEs. The goal is to improve latency and performance for 5G Edge 
Computing services.

Thank you very much,

Linda Dunbar

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Monday, October 19, 2020 3:52 PM
To: lsr@ietf.org; lsr-cha...@ietf.org
Subject: [Lsr] IETF 109 LSR Presentation Slot Requests

Hi all,

We're now accepting agenda requests for the LSR Working Grouping meeting IETF 
109. Please send your requests to 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> indicating draft name, speaker, 
and desired duration (covering presentation and discussion).

LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Linda Dunbar]

Support the WG Adoption.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 AM
To: lsr@ietf.org<mailto: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] Request WG adoption of TTZ

[Linda Dunbar]

Acee, 

Many networks have BGP or/and ISIS. 
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS is 
discussed LSR WG. 
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion 
should be in the LSR Wg, instead of RTGwg (in my opinion). 

Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But this 
TTZ zone draft is not about replacing BGP. 

Linda 

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity 
and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  SDWAN 
Fabric setup. However, that is probably a topic that would be better addressed 
in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
    To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a 
bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone 
and a single node will improve customer experience. The work on TTZ should be 
moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
 wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of 
"Topology-Transparent Zone"
> 
> (TTZ for short) 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3Dreserved=0
 .
> 
> 
> 
> This draft comprises the following solutions for helping to 
improve scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo 
node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone 
or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in 
the sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity and 
exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed 
this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
    To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo 
Chen ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  
wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. 
The proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch 
of nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
single node will improve customer experience. The work on TTZ should be moved 
forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen  
wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of 
"Topology-Transparent Zone"
> 
> (TTZ for short) 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%3Dreserved=0
 .
> 
> 
> 
> This draft comprises the following solutions for helping to improve 
scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in the 
sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few zones to a few pseudo nodes.
> 
> 
> 
> While a zone is being abstracted (or transferred) to a single pseudo 
node,
> 
> the network is stable. There is no or minimum service interruption.
> 
> 
> 
> After abstracting a few zones to a few pseudo nodes, if we want to 
reconstruct
> 
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
smoothly
> 
> with no or minimum service interruption.
> 
> 
> 
> We had a prototype implementation of abstracting a zone to zone 
edges' full
> 
> mess in OSPF. The procedures and related protocol extensions for 
transferring
> 
> smoothly from a zone to zone edges' full mess are implemented and tested.
> 
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full 
mess
> 
> without any routing disruptions. The routes on every router are stable 
while
> 
> the zone is being transferred to its edges' mess. It is very easy to 
operate
> 
> the transferring.
> 
> 
> 
> There are two other drafts for imp

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo Chen 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. The 
> proposed TTZ can group a set of nodes not geographically together into one 
> virtual area to scale virtual overlay networks with lots of nodes. Those kind 
> overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of 
nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
> single node will improve customer experience. The work on TTZ should be moved 
> forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen  wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
> 
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
> 
> 
> 
> This draft comprises the following solutions for helping to improve 
> scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in the sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few zones to a few pseudo nodes.
> 
> 
> 
> While a zone is being abstracted (or transferred) to a single pseudo node,
> 
> the network is stable. There is no or minimum service interruption.
> 
> 
> 
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
> 
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
> 
> with no or minimum service interruption.
> 
> 
> 
> We had a prototype implementation of abstracting a zone to zone edges' 
> full
> 
> mess in OSPF. The procedures and related protocol extensions for transferring
> 
> smoothly from a zone to zone edges' full mess are implemented and tested.
> 
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess
> 
> without any routing disruptions. The routes on every router are stable while
> 
> the zone is being transferred to its edges' mess. It is very easy to operate
> 
> the transferring.
> 
> 
> 
> There are two other drafts for improving scalability: "Area Proxy for 
> IS-IS"
> 
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
> short).
> 
> 
> 
> "Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
> 
> abstracts an existing IS-IS L1 area to a single pseudo node.
> 
> 
> 
> "Flood Reflection" 
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
> 
> abstracts an existing IS-IS L1 area to its edges' connections via one or more
> 
> flood reflectors.
> 
> 
> 
> We believe that TTZ has some special advantages even though
> 
> Area Proxy and Flood Reflection are very worthy. We would like
> 
> to ask for working group adoption of TTZ.
> 
> 
> 
> Best Regards,
> 
> Huaimo
> 
> ___
> 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] Request WG adoption of TTZ

[Linda Dunbar]

I also support the adoption of TTZ draft.

The Virtual Zone concept would be very useful for the Overlay networks. The 
proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

Linda Dunbar

From: Lsr  On Behalf Of LEI LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support the adoption of the TTZ draft.

The operation on TTZ is simple. Smooth transferring between a zone and a single 
node will improve customer experience. The work on TTZ should be moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:

Hi Chris and Acee, and everyone,



I would like to request working group adoption of "Topology-Transparent 
Zone"

(TTZ for short) 
https://datatracker.ietf.org/doc/draft-chen-isis-ttz/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093803058=tqunOWC7trBoFu3XBvAFrLDzyFdlLQl9xYMtMdPSMgo%3D=0>
 .



This draft comprises the following solutions for helping to improve 
scalability:

1) abstracting a zone to a single pseudo node in IS-IS,

2) abstracting a zone to a single pseudo node in OSPF,

3) abstracting a zone to zone edges' full mess in IS-IS, and

4) transferring smoothly between a zone and a single pseudo node.

A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or

non-backbone area).



When a network area becomes (too) big, we can reduce its size in the sense

of its LSDB size through abstracting a zone to a single pseudo node or

abstracting a few zones to a few pseudo nodes.



While a zone is being abstracted (or transferred) to a single pseudo node,

the network is stable. There is no or minimum service interruption.



After abstracting a few zones to a few pseudo nodes, if we want to 
reconstruct

them, we can transfer (or roll) any of the pseudo nodes back to its zone 
smoothly

with no or minimum service interruption.



We had a prototype implementation of abstracting a zone to zone edges' full

mess in OSPF. The procedures and related protocol extensions for transferring

smoothly from a zone to zone edges' full mess are implemented and tested.

A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess

without any routing disruptions. The routes on every router are stable while

the zone is being transferred to its edges' mess. It is very easy to operate

the transferring.



There are two other drafts for improving scalability: "Area Proxy for IS-IS"

(Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
short).



"Area Proxy" 
https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093808054=OxU3ikjVtGtL7piPPc2WJQ8GatTz1XMnoREwVA00%2F2E%3D=0>

abstracts an existing IS-IS L1 area to a single pseudo node.



"Flood Reflection" 
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093818056=jiSeOvvxabugWULFhFag%2BvVHEbmXBF6mza9cSwbi5t8%3D=0>

abstracts an existing IS-IS L1 area to its edges' connections via one or more

flood reflectors.



We believe that TTZ has some special advantages even though

Area Proxy and Flood Reflection are very worthy. We would like

to ask for working group adoption of TTZ.



Best Regards,

Huaimo
___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093823049=mqXl2c5rWwvbP%2BW6iRJCK8%2FtTktq56eKhfB53gF4y38%3D=0>


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Peter, 

Thank you for the explanation.  

Linda

-Original Message-
From: Peter Psenak  
Sent: Wednesday, June 10, 2020 3:40 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; gen-...@ietf.org
Cc: last-c...@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; 
lsr@ietf.org
Subject: Re: [Lsr] Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 09/06/2020 22:20, Linda Dunbar wrote:
> Peter,
> 
> Thank you for the explanation.
> 
> So you are saying that a node might not support RSVP or RSVP-TE, but can 
> advertise the TE related attributes for SR purpose. When  the head node 
> receiving the advertisement also support RSVP-TE, it might use the 
> information to establish the RSVP path, which will be rejected by the node 
> that don't support RSVP but advertise the TE related information?  is it 
> correct?

yes.

> 
> It would be useful if you can add a statement to explain the scenario that a 
> node only has a subset of links supporting RSVP-TE but also capable of 
> advertising TE related attributes for links that are not enabled for RSVP-TE.

There is a text in the draft:

 An example where this ambiguity causes a problem is a network in
 which RSVP-TE is enabled only on a subset of its links.  A link
 attribute is advertised for the purpose of another application (e.g.
 SRTE) for a link that is not enabled for RSV-TE.  As soon as the
 router that is an RSVP-TE head-end sees the link attribute being
 advertised for that link, it assumes RSVP-TE is enabled on that
 link, even though it is not.  If such RSVP-TE head-end router tries
 to setup an RSVP-TE path via that link it will result in the path
 setup failure.

thanks,
Peter

> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Tuesday, June 9, 2020 10:18 AM
> To: Linda Dunbar ; Acee Lindem (acee) 
> ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
> 
> Linda,
> 
> On 09/06/2020 16:18, Linda Dunbar wrote:
>> Acee and Peter,
>>
>> Thank you very much for the explanation.
>>
>> My fundamental question is: What problem will be encountered when a node use 
>> the TE information on links that RSVP-TE are not enabled?
> 
> The problem is on a node where RSVP is enabled, when it receives the link 
> attribute for a remote link where RSVP is not enabled.
> 
>  An example where this ambiguity causes a problem is a network in
>  which RSVP-TE is enabled only on a subset of its links.  A link
>  attribute is advertised for the purpose of another application (e.g.
>  SRTE) for a link that is not enabled for RSV-TE.  As soon as the
>  router that is an RSVP-TE head-end sees the link attribute being
>  advertised for that link, it assumes RSVP-TE is enabled on that link,
>  even though it is not.  If such RSVP-TE head-end router tries to
>  setup an RSVP-TE path via that link it will result in the path setup
>  failure.
> 
>>
>> I would think that the reason that RSVP-TE is enabled per interface is 
>> because not every interface is capable of generating the TE information, or 
>> the Node doesn't want to share the detailed TE information to remote nodes 
>> (for security reasons?).
> 
> the simplest reason is that RSVP is not used on the router at all.
> 
>>
>>If SR is enabled on a node, which is capable of detecting the TE 
>> information on the links to be advertised to remote nodes, what problems do 
>> we have when the OSPF-TE application on remote nodes utilizes the Link TE 
>> information?
> 
> please see above.
> 
> thanks,
> Peter
>>
>>
>> Thank you.
>>
>> Linda
>>
>> -Original Message-
>> From: Acee Lindem (acee) 
>> Sent: Tuesday, June 9, 2020 6:25 AM
>> To: Peter Psenak (ppsenak) ; Linda Dunbar 
>> ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org; 
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>>
>> Hi Linda,
>> One more point...
>>
>> On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:
>>
>>   Linda,
>>
>>   On 09/06/2020 02:37, Linda Dunbar wrote:
>>   > Peter,
>>   >
>>   > Thank you very much for adding the extra text to explain.
>>   >
>>   > But SR is supposed to be transparent to all intermediate nodes. Does 
>> your draft require a node to be specifically configured for each link to 
>> sup

[Lsr] Genart telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ospf-te-link-attr-reuse-14
Reviewer: Linda Dunbar
Review Date: 2020-06-09
IETF LC End Date: 2020-05-29
IESG Telechat date: 2020-06-11

Summary:

This document proposes a new OSPF  Link attribute to indicate the intended
purpose of the advertised TE information. So that if the RSVP-TE is not enabled
on a link, the TE attributes of the Link being advertised can't be used by
remote receiving nodes for  RSVP-TE purpose.

It would be useful if the authors can add a statement to explain the scenario
when a node only has a subset of links supporting RSVP-TE but is capable of
advertising TE related attributes for the links that are not enabled for
RSVP-TE.  Just wondering what reasons that some links can collect TE attributes
but not enabled for RSVP-TE.

I have reviewed this draft multiple times, provided comments to -11, -12
version. The authors have addressed many of them in the -14 version.  Many
thanks.

Major issues:

Minor issues:

Nits/editorial comments:

Best Regards,

Linda Dunbar


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Peter, 

Thank you for the explanation. 

So you are saying that a node might not support RSVP or RSVP-TE, but can 
advertise the TE related attributes for SR purpose. When  the head node 
receiving the advertisement also support RSVP-TE, it might use the information 
to establish the RSVP path, which will be rejected by the node that don't 
support RSVP but advertise the TE related information?  is it correct? 

It would be useful if you can add a statement to explain the scenario that a 
node only has a subset of links supporting RSVP-TE but also capable of 
advertising TE related attributes for links that are not enabled for RSVP-TE. 

Linda Dunbar

-Original Message-
From: Peter Psenak  
Sent: Tuesday, June 9, 2020 10:18 AM
To: Linda Dunbar ; Acee Lindem (acee) 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 09/06/2020 16:18, Linda Dunbar wrote:
> Acee and Peter,
> 
> Thank you very much for the explanation.
> 
> My fundamental question is: What problem will be encountered when a node use 
> the TE information on links that RSVP-TE are not enabled?

The problem is on a node where RSVP is enabled, when it receives the link 
attribute for a remote link where RSVP is not enabled.

An example where this ambiguity causes a problem is a network in
which RSVP-TE is enabled only on a subset of its links.  A link
attribute is advertised for the purpose of another application (e.g.
SRTE) for a link that is not enabled for RSV-TE.  As soon as the
router that is an RSVP-TE head-end sees the link attribute being
advertised for that link, it assumes RSVP-TE is enabled on that link,
even though it is not.  If such RSVP-TE head-end router tries to
setup an RSVP-TE path via that link it will result in the path setup
failure.

> 
> I would think that the reason that RSVP-TE is enabled per interface is 
> because not every interface is capable of generating the TE information, or 
> the Node doesn't want to share the detailed TE information to remote nodes 
> (for security reasons?).

the simplest reason is that RSVP is not used on the router at all.

> 
>   If SR is enabled on a node, which is capable of detecting the TE 
> information on the links to be advertised to remote nodes, what problems do 
> we have when the OSPF-TE application on remote nodes utilizes the Link TE 
> information?

please see above.

thanks,
Peter
> 
> 
> Thank you.
> 
> Linda
> 
> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Tuesday, June 9, 2020 6:25 AM
> To: Peter Psenak (ppsenak) ; Linda Dunbar 
> ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
> 
> Hi Linda,
> One more point...
> 
> On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:
> 
>  Linda,
> 
>  On 09/06/2020 02:37, Linda Dunbar wrote:
>  > Peter,
>  >
>  > Thank you very much for adding the extra text to explain.
>  >
>  > But SR is supposed to be transparent to all intermediate nodes. Does 
> your draft require a node to be specifically configured for each link to 
> support or not support SR or RSVP-TE?
> 
>  the draft does not pose any new requirements in terms of how
>  applications are enabled.
> 
>  Please note that RSVP-TE is typically enabled per interface, SRTE is
>  typically enabled on a per node basis.
> 
> For SR, these attributes are attributes are advertised in OSPF so that any 
> OSPF router or controller in the OSPF domain can make use of them to compute 
> the SR path.
> 
> Thanks,
> Acee
> 
> 
>  >
>  > In addition, there is no new attributes described in the document. So 
> if a node is advertising TE related attributes for a specific link, such as 
> bandwidth, delay,  what kind problems this node will encounter if a remote 
> node utilize those TE specific attributes?
> 
>  the problem is when the link attributes advertise for the purpose of
>  application other than RSVP-TE is mistakenly used by RSVP-TE.
> 
>  thanks,
>  Peter
> 
> 
> 
>  >
>  > Linda Dunbar
>  >
>  > -Original Message-
>  > From: Peter Psenak 
>  > Sent: Monday, June 1, 2020 11:01 AM
>  > To: Linda Dunbar ; gen-...@ietf.org
>  > Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>  > Subject: Re: Genart last call review of 
> draft-ietf-ospf-te-link-attr-reuse-12
>  >
> 

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Acee and Peter, 

Thank you very much for the explanation. 

My fundamental question is: What problem will be encountered when a node use 
the TE information on links that RSVP-TE are not enabled? 

I would think that the reason that RSVP-TE is enabled per interface is because 
not every interface is capable of generating the TE information, or the Node 
doesn't want to share the detailed TE information to remote nodes (for security 
reasons?). 

 If SR is enabled on a node, which is capable of detecting the TE information 
on the links to be advertised to remote nodes, what problems do we have when 
the OSPF-TE application on remote nodes utilizes the Link TE information? 


Thank you. 

Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, June 9, 2020 6:25 AM
To: Peter Psenak (ppsenak) ; Linda Dunbar 
; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,
One more point... 

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

Linda,

On 09/06/2020 02:37, Linda Dunbar wrote:
> Peter,
> 
> Thank you very much for adding the extra text to explain.
> 
> But SR is supposed to be transparent to all intermediate nodes. Does your 
draft require a node to be specifically configured for each link to support or 
not support SR or RSVP-TE?

the draft does not pose any new requirements in terms of how 
applications are enabled.

Please note that RSVP-TE is typically enabled per interface, SRTE is 
typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path. 

Thanks,
Acee


> 
> In addition, there is no new attributes described in the document. So if 
a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

the problem is when the link attributes advertise for the purpose of 
application other than RSVP-TE is mistakenly used by RSVP-TE.

thanks,
    Peter



> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, June 1, 2020 11:01 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12
> 
    > Hi Linda,
> 
> 
> On 01/06/2020 17:30, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /“//the problem with existing advertisement is that RSVP-TE will use
>> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
>> problem if RSVP-TE use the advertisement? What specific attributes
>> that RSVP-TE shouldn’t use?
> 
> Following text has been added to the draft based on comments from Scott.
> 
> "An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. 
A link attribute is advertised for the purpose of some other application (e.g. 
SRTE) for a link that is not enabled for RSV-TE. As soon as the router that is 
an RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."
> 
> Hope it makes it clear and addresses your question.
> 
> thanks,
> Peter
> 
> 
> 
> 
> 
>> Linda Dunbar
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Friday, May 29, 2020 10:00 AM
>> To: Linda Dunbar ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Linda,
>> On 29/05/2020 16:52, Linda Dunbar wrote:
>>> Peter,
>>> You said:
>>> /we are not defining any new attributes./ /We are allowing an
>>> existing link attributes to be used by other applications, including,
>>> but not limited to SRTE./ What prevent a node (or an application on
>>> the node) receiving the LSA from using the attributes carried by the 
LSA?
>> the problem with existing advertisement is that RSVP-TE will us

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Peter, 

Thank you very much for adding the extra text to explain. 

But SR is supposed to be transparent to all intermediate nodes. Does your draft 
require a node to be specifically configured for each link to support or not 
support SR or RSVP-TE?

In addition, there is no new attributes described in the document. So if a node 
is advertising TE related attributes for a specific link, such as bandwidth, 
delay,  what kind problems this node will encounter if a remote node utilize 
those TE specific attributes? 

Linda Dunbar

-Original Message-
From: Peter Psenak  
Sent: Monday, June 1, 2020 11:01 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,


On 01/06/2020 17:30, Linda Dunbar wrote:
> Peter,
> You said:
> /“//the problem with existing advertisement is that RSVP-TE will use 
> it, even if it was not intended to be used by RSVP-TE.//”/ What is the 
> problem if RSVP-TE use the advertisement? What specific attributes 
> that RSVP-TE shouldn’t use?

Following text has been added to the draft based on comments from Scott.

"An example where this ambiguity causes problem is a network which has RSVP-TE 
enabled on one subset of links, and SRTE enabled on a different subset. A link 
attribute is advertised for the purpose of some other application (e.g. SRTE) 
for a link that is not enabled for RSV-TE. As soon as the router that is an 
RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."

Hope it makes it clear and addresses your question.

thanks,
Peter





> Linda Dunbar
> -Original Message-
> From: Peter Psenak 
> Sent: Friday, May 29, 2020 10:00 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of
> draft-ietf-ospf-te-link-attr-reuse-12
> Linda,
> On 29/05/2020 16:52, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /we are not defining any new attributes./ /We are allowing an 
>> existing link attributes to be used by other applications, including, 
>> but not limited to SRTE./ What prevent a node (or an application on 
>> the node) receiving the LSA from using the attributes carried by the LSA?
> the problem with existing advertisement is that RSVP-TE will use it, 
> even if it was not intended to be used by RSVP-TE.
> We are providing a way to explicitly advertised apps that are allowed 
> to use the advertised attributes.
>> If no new attributes are
>> to be added, then why need a new ASLA sub-TLV?
> to be able to use the existing attributes for new apps, other than RSVP-TE.
> thanks,
> Peter
>> Linda
>> -Original Message-
>> From: Peter Psenak mailto:ppse...@cisco.com>>
>> Sent: Friday, May 29, 2020 5:51 AM
>> To: Linda Dunbar > <mailto:linda.dun...@futurewei.com>>;
> gen-...@ietf.org <mailto:gen-...@ietf.org>
>> Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; lsr@ietf.org
> <mailto:lsr@ietf.org>;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
> <mailto:draft-ietf-ospf-te-link-attr-reuse@ietf.org>
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Hi Linda,
>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
>>> Reviewer: Linda Dunbar
>>> Review result: Not Ready
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>>> the IESG for the IETF Chair.  Please treat these comments just like 
>>> any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C1bd0e81d5279453d853808d8064500a2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637266240741960001sdata=faz4UopBwiK3D0CXWu%2BiebFOje9qfJt1wL6J4QqcjlY%3Dreserved=0>.
>>> 
>>> Document: draft-ietf-ospf-te-link-attr-reuse-??
>>> Reviewer: Linda Dunbar
>>> Review Date: 2020-05-28
>>> IETF LC End Date: 2020-05-29
>>> IESG Telechat date: Not scheduled for a telechat
>>> 
>>> Summary: this document introduces a new link attribute advertisement 

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Peter,

You said:

  “the problem with existing advertisement is that RSVP-TE will use it, 
even if it was not intended to be used by RSVP-TE.”

What is the problem if RSVP-TE use the advertisement? What specific attributes 
that RSVP-TE shouldn’t use?


Linda Dunbar


-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 10:00 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Linda,

On 29/05/2020 16:52, Linda Dunbar wrote:
> Peter,
> You said:
> /we are not defining any new attributes./ /We are allowing an existing
> link attributes to be used by other applications, including, but not
> limited to SRTE./ What prevent a node (or an application on the node)
> receiving the LSA from using the attributes carried by the LSA?

the problem with existing advertisement is that RSVP-TE will use it, even if it 
was not intended to be used by RSVP-TE.

We are providing a way to explicitly advertised apps that are allowed to use 
the advertised attributes.

> If no new attributes are
> to be added, then why need a new ASLA sub-TLV?

to be able to use the existing attributes for new apps, other than RSVP-TE.


thanks,
Peter

> Linda
> -Original Message-
> From: Peter Psenak mailto:ppse...@cisco.com>>
> Sent: Friday, May 29, 2020 5:51 AM
> To: Linda Dunbar 
> mailto:linda.dun...@futurewei.com>>; 
> gen-...@ietf.org<mailto:gen-...@ietf.org>
> Cc: last-c...@ietf.org<mailto:last-c...@ietf.org>; 
> lsr@ietf.org<mailto:lsr@ietf.org>;
> draft-ietf-ospf-te-link-attr-reuse@ietf.org<mailto:draft-ietf-ospf-te-link-attr-reuse@ietf.org>
> Subject: Re: Genart last call review of
> draft-ietf-ospf-te-link-attr-reuse-12
> Hi Linda,
> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
>> Reviewer: Linda Dunbar
>> Review result: Not Ready
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please treat these comments just like
>> any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C34b141b11fe6484fc65208d803e0e851%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263611798933480sdata=hXIX5xyAiXcFdymKVyg%2BVuQZAznQKJV5Il7U9OOdVv0%3Dreserved=0>.
>>
>> Document: draft-ietf-ospf-te-link-attr-reuse-??
>> Reviewer: Linda Dunbar
>> Review Date: 2020-05-28
>> IETF LC End Date: 2020-05-29
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: this document introduces a new link attribute advertisement
>> in OSPFv2 and OSPFv3 to address general link properties needed for
>> new applications, such as Segment Routing.
>>
>> Major issues:
>> The document has good description on the TLV structure of the
>> Application specific Advertisements, but fails to describe what are
>> the NEW Link attributes needed by Segment Routing. Page 7 (section 5)
>> has a really good description on all the link properties added to
>> OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see
>> Segment Routing would need each node to advertise its own SID and the
>> SIDs of adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE 
>> ID?
> we are not defining any new attributes.
> We are allowing an existing link attributes to be used by other
> applications, including, but not limited to SRTE.
> thanks,
> Peter
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> Best regards,
>>
>> Linda Dunbar
>>
>>
>>
>>


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

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar]

Peter,

You said:

  we are not defining any new attributes.

  We are allowing an existing link attributes to be used by other 
applications, including, but not limited to SRTE.

What prevent a node (or an application on the node) receiving the LSA from 
using the attributes carried by the LSA?  If no new attributes are to be added, 
then why need a new ASLA sub-TLV?


Linda

-Original Message-
From: Peter Psenak 
Sent: Friday, May 29, 2020 5:51 AM
To: Linda Dunbar ; gen-...@ietf.org
Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
Subject: Re: Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

Hi Linda,

On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Not Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaqdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C008faccf0edd4290149908d803be29ea%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263462571035839sdata=gkOw4rUUjCqIpp%2B3opurl5M44kb3cQzOYlIC%2FOLAoD0%3Dreserved=0>.
>
> Document: draft-ietf-ospf-te-link-attr-reuse-??
> Reviewer: Linda Dunbar
> Review Date: 2020-05-28
> IETF LC End Date: 2020-05-29
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: this document introduces a new link attribute advertisement
> in OSPFv2 and OSPFv3 to address general link properties needed for new
> applications, such as Segment Routing.
>
> Major issues:
> The document has good description on the TLV structure of the
> Application specific Advertisements, but fails to describe what are
> the NEW Link attributes needed by Segment Routing. Page 7 (section 5)
> has a really good description on all the link properties added to OSFP
> (RFC4203, RFC 7308, RFC7471, RFC3630) to achieve TE. I can see Segment
> Routing would need each node to advertise its own SID and the SIDs of
> adjacent nodes. Can't they be encoded (or extended) in OSPF's NODE ID?

we are not defining any new attributes.

We are allowing an existing link attributes to be used by other applications, 
including, but not limited to SRTE.

thanks,
Peter

>
> Minor issues:
>
> Nits/editorial comments:
>
> Best regards,
>
> Linda Dunbar
>
>
>
>


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

[Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

[Linda Dunbar via Datatracker]

Reviewer: Linda Dunbar
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ospf-te-link-attr-reuse-??
Reviewer: Linda Dunbar
Review Date: 2020-05-28
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary: this document introduces a new link attribute advertisement in OSPFv2
and OSPFv3 to address general link properties needed for new applications, such
as Segment Routing.

Major issues:
The document has good description on the TLV structure of the Application
specific Advertisements, but fails to describe what are the NEW Link attributes
needed by Segment Routing. Page 7 (section 5) has a really good description on
all the link properties added to OSFP (RFC4203, RFC 7308, RFC7471, RFC3630) to
achieve TE. I can see Segment Routing would need each node to advertise its own
SID and the SIDs of adjacent nodes. Can't they be encoded (or extended) in
OSPF's NODE ID?

Minor issues:

Nits/editorial comments:

Best regards,

Linda Dunbar


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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Linda Dunbar]

Support the WG Adoption.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Friday, May 15, 2020 3:40 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7C5734ce330848415ad72108d7fb62ec30%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637254274611408698=rOiq%2FeRJv6O8Jy2KKHsnj6DMZLFxQUpyP8qopwYCxjI%3D=0>

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

Re: [Lsr] IETF 107 LSR Presentation Slot Requests

[Linda Dunbar]

Opps, meant to send to RTGwg. Wrong reply.

I am very sorry.

Linda

From: Linda Dunbar
Sent: Monday, March 2, 2020 12:56 PM
To: Yingzhen Qu 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: RE: [Lsr] IETF 107 LSR Presentation Slot Requests

Ying Zhen,

Can you please give me 15 minutes to update the
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/

we have made a lot of changes to address comments and suggestions from the  
IETF 106 and mailing list.

Thank you very much

Linda Dunbar

On 28/02/2020 20:56, Yingzhen Qu wrote:
> Hi all,
>
> We're now accepting agenda request for the LSR Working Grouping meeting
> IETF 107. Please send your requests to 
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
> <mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>> indicating draft 
> name, speaker, and desired
> duration (covering presentation and discussion).
>
> If you plan to present remotely, please let us know so we can make the
> arrangements with the Meetecho team.
>
> Thanks,
> Yingzhen
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Recall: IETF 107 LSR Presentation Slot Requests

[Linda Dunbar]

Linda Dunbar would like to recall the message, "[Lsr] IETF 107 LSR Presentation 
Slot Requests".
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr