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

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Jul 2021 21:41:26 +0000

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) <[email-masked]>
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>
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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66caea5e0b7243b0d4ce08d94578939b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617206455265464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VB%2BWjb2Zd%2Fe0iSE8K%2BMCpL%2FbiZYqhS5T2602e2z2cPc%3D&reserved=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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Yingzhen Qu
Sent: Wednesday, June 30, 2021 4:00 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66caea5e0b7243b0d4ce08d94578939b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617206455275420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uhIFfvuGreFkey%2BMO6fmTK52Y%2FmAc7C7Qlrj8FhzvIw%3D&reserved=0>.

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

Please send slot requests to [email-masked]<mailto:[email-masked]>. Please include name of the presenter, pointer to the draft and time estimation including Q&A.

Thanks,
Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Jul 2021 00:06:02 +0000

Hi Linda,

From: Linda Dunbar <[email-masked]>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem <[email-masked]>, Yingzhen Qu <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

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

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”…

Note that routes are based on IP prefixes and not applications while the draft uses these two interchangeably.

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

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

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Jul 2021 01:31:50 +0000

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. “

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.

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.
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 <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
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,

To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Yingzhen Qu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] LSR Presentation Slot Requests - IETF111

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Jul 2021 17:23:24 +0000

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) <[email-masked]>
Sent: Monday, July 12, 2021 7:06 PM
To: Linda Dunbar <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Hi Linda,

Acee,

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.

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.

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

Speaking as WG member:

Hi Linda,

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cc231cf9bf5a14a7404d908d945920311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617315695998528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EpFFhfCXHM33xhcq7QbqVJGoPpvx3hc%2Fbu80zlsmOdo%3D&reserved=0>
Speaker: Linda Dunbar.

Thank you
Linda Dunbar

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cc231cf9bf5a14a7404d908d945920311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617315696008484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F5iGeQ3x%2Fj50Ga1UjXcCDOiTa%2Fy4e%2FBNObkRR9OinIQ%3D&reserved=0>.

Thanks,
Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Jul 2021 19:24:22 +0000

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 <[email-masked]>
Date: Tuesday, July 13, 2021 at 1:23 PM
To: Acee Lindem <[email-masked]>, Yingzhen Qu <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Acee,

Linda

Hi Linda,

Acee,

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.

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Jul 2021 19:42:06 +0000

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) <[email-masked]>
Sent: Tuesday, July 13, 2021 2:24 PM
To: Linda Dunbar <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
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

Acee,

Linda

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3ad3f28801744a4955b808d94633d46f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618010699791075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=91494U1Xr%2FwDptWMxffbrP0cnnniY96Xt0Bk63KJruE%3D&reserved=0>
Speaker: Linda Dunbar.

Thank you
Linda Dunbar

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C3ad3f28801744a4955b808d94633d46f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618010699801041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3RzIq%2FkW8magEse2aswsQ5BA%2BvGD1YaQNDKpuDHNhKk%3D&reserved=0>.

Thanks,
Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Jul 2021 19:46:27 +0000

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

Date: Tuesday, July 13, 2021 at 3:42 PM

Acee,

Linda

Acee,

Linda

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Jul 2021 20:01:47 +0000

Les,

Thank you for the comments.
Replies are inserted below:

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

Linda -

"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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)

Hi Linda,

Acee,

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"...

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7924484d75ec44a8892f08d9459e0034%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617367189464541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Vjp9BD8jGQfTuvixVyfWDzDnv0tlEkFhYp18Zh%2F0KPE%3D&reserved=0>
Speaker: Linda Dunbar.

Thank you
Linda Dunbar

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7924484d75ec44a8892f08d9459e0034%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637617367189474498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jya3cOSyJ%2BjcKzsddeFhE6DxFEYA89j4E3LFlL1HROo%3D&reserved=0>.

Thanks,
Yingzhen

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 Jul 2021 05:36:07 +0000

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 <[email-masked]>
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Les,

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

Linda -

[LES:] Prefic reachability is advertised using TLVs 135, 235, 236, and 237. If appropriate, new sub-TLVs can be defined for these TLVs - which would be analogous to how you proposed to extend OSPF.

[LES:] The ASLA bit masks identify the application(s) to which the attribute advertisements apply.
If a node does not support a given application, then it simply ignores these advertisements.
But, as per my previous response, link attributes isn't the right place to advertise what seems to be a prefix attribute - which means ASLA isn't relevant for you.

   Les

   Les

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 14 Jul 2021 16:36:24 +0800

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-attri
bute-08.

Do you have other concerns for such solution?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg
(ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar <[email-masked]>; Acee Lindem (acee)
<acee=[email-masked]>; Yingzhen Qu <[email-masked]>;
[email-masked]
Cc: [email-masked]
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.

From: Linda Dunbar <[email-masked]
<mailto:[email-masked]> > 
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>
>; Acee Lindem (acee) <acee=[email-masked]
<mailto:acee=[email-masked]> >; Yingzhen Qu
<[email-masked] <mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: RE: [Lsr] IP layer metrics collected by Edge routers -
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot
request)

Les, 

 

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

Linda -

"Note that routes are based on IP prefixes and not applications while the
draft uses these two interchangeably. "

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? 

[LES:] Prefic reachability is advertised using TLVs 135, 235, 236, and 237.
If appropriate, new sub-TLVs can be defined for these TLVs - which would be
analogous to how you proposed to extend OSPF.

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? 

[LES:] The ASLA bit masks identify the application(s) to which the attribute
advertisements apply.

If a node does not support a given application, then it simply ignores these
advertisements.

But, as per my previous response, link attributes isn't the right place to
advertise what seems to be a prefix attribute - which means ASLA isn't
relevant for you.

   Les

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. 

   Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of
Acee Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar <[email-masked]
<mailto:[email-masked]> >; Yingzhen Qu <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
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 <[email-masked]
<mailto:[email-masked]> >
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Yingzhen Qu
<[email-masked] <mailto:[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: IP layer metrics collected by Edge routers -
draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot
request)

Acee, 

"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 prefixes and not applications while the
draft uses these two interchangeably. 

Thanks,

Acee

Any other concerns? 

Thank you

Linda Dunbar

From: Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar <[email-masked]
<mailto:[email-masked]> >; Yingzhen Qu <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
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 <[email-masked]
<mailto:[email-masked]> >
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: <[email-masked] <mailto:[email-masked]> >
Resent-To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Christian
Hopps <[email-masked] <mailto:[email-masked]> >, Yingzhen Qu
<[email-masked] <mailto:[email-masked]> >
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
er.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda
.dunbar%40futurewei.com%7C7924484d75ec44a8892f08d9459e0034%7C0fee8ff2a3b2401
89c753a1d5591fedc%7C1%7C0%7C637617367189464541%7CUnknown%7CTWFpbGZsb3d8eyJWI
joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V
jp9BD8jGQfTuvixVyfWDzDnv0tlEkFhYp18Zh%2F0KPE%3D&reserved=0>
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 <[email-masked] <mailto:[email-masked]> > On Behalf Of
Yingzhen Qu
Sent: Wednesday, June 30, 2021 4:00 PM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
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%2Fdatatrack
er.ietf.org%2Fmeeting%2F111%2Fagenda&data=04%7C01%7Clinda.dunbar%40futurewei
.com%7C7924484d75ec44a8892f08d9459e0034%7C0fee8ff2a3b240189c753a1d5591fedc%7
C1%7C0%7C637617367189474498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Jya3cOSyJ%2BjcKzsdde
FhE6DxFEYA89j4E3LFlL1HROo%3D&reserved=0> . 

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

Please send slot requests to [email-masked]
<mailto:[email-masked]> . Please include name of the presenter, pointer
to the draft and time estimation including Q&A. 

Thanks,

Yingzhen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 14 Jul 2021 16:20:10 +0000

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) <[email-masked]>
Sent: Tuesday, July 13, 2021 2:46 PM
To: Linda Dunbar <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
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

Acee,

Linda

Acee,

Linda

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942568077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7f0TuUw7LVnzT2doHdN0CIJ4SinQP7KKzIUA61yBDrg%3D&reserved=0>
Speaker: Linda Dunbar.

Thank you
Linda Dunbar

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942578032%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xI%2F46njm9a3I0qx7fDKRaULJ2qygqdDRT4QIBUtkBqQ%3D&reserved=0>.

Thanks,
Yingzhen

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Jul 2021 12:35:09 -0400

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.
> 
> 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.
> 
> The work proposed is for the LSR Chartered Work Item “4) Extensions for 
> source-destination routing”.
> 
> *From:* Acee Lindem (acee) <[email-masked]>
> *Sent:* Tuesday, July 13, 2021 2:46 PM
> *To:* Linda Dunbar <[email-masked]>; Yingzhen Qu 
> <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: IP layer metrics collected by Edge routers - 
> 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 <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Tuesday, July 13, 2021 at 3:42 PM
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: IP layer metrics collected by Edge routers - 
> 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) <[email-masked] <mailto:[email-masked]>>
> *Sent:* Tuesday, July 13, 2021 2:24 PM
> *To:* Linda Dunbar <[email-masked] 
> <mailto:[email-masked]>>; Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: IP layer metrics collected by Edge routers - 
> 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 <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Tuesday, July 13, 2021 at 1:23 PM
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: IP layer metrics collected by Edge routers - 
> 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.
> 
> *From:* Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>
> *Sent:* Monday, July 12, 2021 7:06 PM
> *To:* Linda Dunbar <[email-masked] 
> <mailto:[email-masked]>>; Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: IP layer metrics collected by Edge routers - 
> *From: *Linda Dunbar <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Monday, July 12, 2021 at 5:41 PM
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *IP layer metrics collected by Edge routers - 
> -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.
> 
> 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 
> 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.
> 
> *From:* Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>
> *Sent:* Monday, July 12, 2021 4:04 PM
> *To:* Linda Dunbar <[email-masked] 
> <mailto:[email-masked]>>; Yingzhen Qu 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *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 <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Monday, July 12, 2021 at 4:27 PM
> *To: *Yingzhen Qu <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *RE: [Lsr] LSR Presentation Slot Requests - IETF111
> *Resent-From: *<[email-masked] <mailto:[email-masked]>>
> *Resent-To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, 
> Christian Hopps <[email-masked] <mailto:[email-masked]>>, Yingzhen 
> Qu <[email-masked] <mailto:[email-masked]>>
> *Resent-Date: *Monday, July 12, 2021 at 4:27 PM
> 
> Yingzhen and LSR Chairs,
> 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942568077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7f0TuUw7LVnzT2doHdN0CIJ4SinQP7KKzIUA61yBDrg%3D&reserved=0> 
> 
> 
> Speaker: Linda Dunbar.
> 
> *From:* Lsr <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Yingzhen Qu
> *Sent:* Wednesday, June 30, 2021 4:00 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Lsr] LSR Presentation Slot Requests - IETF111
> 
> Hi all,
> 
> 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fagenda&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C492fc62171624e5792ea08d94636e9d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618023942578032%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xI%2F46njm9a3I0qx7fDKRaULJ2qygqdDRT4QIBUtkBqQ%3D&reserved=0>. 
> 
> 
> <mailto:[email-masked]>. Please include name of the presenter, 
> pointer to the draft and time estimation including Q&A.
> 
> Thanks,
> 
> Yingzhen
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 14 Jul 2021 16:58:17 +0000

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 <[email-masked]> 
Sent: Wednesday, July 14, 2021 11:35 AM
To: Linda Dunbar <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
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.
> 
> 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:
> 
> "Capacity Index", which is a numeric number configured by the Domain 
> flows that are identified by the IP header fields. "Site Preference 
> Index", which is a numeric number configured by the Domain Controller.
> 
> 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.
> 
> We seem to be in a circular discussion - we're not standardizing 
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen 
> Qu <[email-masked] <mailto:[email-masked]>>,
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> Linda - we're not doing routing for limited domains in LSR. It doesn't 
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen 
> Qu <[email-masked] <mailto:[email-masked]>>,
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>, Yingzhen 
> Qu <[email-masked] <mailto:[email-masked]>>,
> "Aggregated Cost" is only applicable to scenario where all the A-ER 
> can have a consistent algorithm to compute the Aggregated cost.
> 
> consistent algorithm to compute the aggregated cost or some routers 
> need all the detailed IP Layer metrics for the App Servers for other 
> So, why would these "capable" nodes have a consistent algorithm for 
> 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.
> 
> 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".  \
> 
> 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.
> 
> 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.
> 
> <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> 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
> 
> Christian Hopps <[email-masked] <mailto:[email-masked]>>, 
> Yingzhen Qu <[email-masked] <mailto:[email-masked]>>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&amp;data=
> 04%7C01%7Clinda.dunbar%40futurewei.com%7C1343088f05a845cecb8608d946e55
> a27%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618773148844727%7C
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=egQVdPhH0gFPEH%2FG04Q8ZqhDGjAlLV2R
> mpuvtoBWrfk%3D&amp;reserved=0 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&amp;data
> =04%7C01%7Clinda.dunbar%40futurewei.com%7C1343088f05a845cecb8608d946e5
> 5a27%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618773148844727%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=egQVdPhH0gFPEH%2FG04Q8ZqhDGjAlLV2
> RmpuvtoBWrfk%3D&amp;reserved=0>
> 
> 
> Speaker: Linda Dunbar.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fmeeting%2F111%2Fagenda&amp;data=04%7C01%7Clinda.dun
> bar%40futurewei.com%7C1343088f05a845cecb8608d946e55a27%7C0fee8ff2a3b24
> 0189c753a1d5591fedc%7C1%7C0%7C637618773148844727%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&amp;sdata=CniobGmY%2FOz6gmbkXWo%2B29TtH20oKOg9rG6658Icrw0%3D&am
> p;reserved=0 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fagenda&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C1343088f05a845cecb8608d946e55a27%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618773148844727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=CniobGmY%2FOz6gmbkXWo%2B29TtH20oKOg9rG6658Icrw0%3D&amp;reserved=0>.
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Clinda.dunbar%40
> futurewei.com%7C1343088f05a845cecb8608d946e55a27%7C0fee8ff2a3b240189c7
> 53a1d5591fedc%7C1%7C0%7C637618773148844727%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> &amp;sdata=z3oCltG3C9K0jC9Gd%2BSEcZpc%2BGlvg3wsAsn1Kkh8hI0%3D&amp;rese
> rved=0
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Jul 2021 17:07:59 +0000

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 <[email-masked]>
Date: Wednesday, July 14, 2021 at 4:37 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, 'Linda Dunbar' <[email-masked]>, Acee Lindem <[email-masked]>, Yingzhen Qu <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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.

Best Regards

Aijun Wang
China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Yingzhen Qu <[email-masked]>; [email-masked]
Cc: [email-masked]
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.

To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; Yingzhen Qu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Les,

Linda –

[LES:] Prefic reachability is advertised using TLVs 135, 235, 236, and 237. If appropriate, new sub-TLVs can be defined for these TLVs – which would be analogous to how you proposed to extend OSPF.

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?

[LES:] The ASLA bit masks identify the application(s) to which the attribute advertisements apply.
If a node does not support a given application, then it simply ignores these advertisements.
But, as per my previous response, link attributes isn’t the right place to advertise what seems to be a prefix attribute – which means ASLA isn’t relevant for you.

   Les

   Les

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 14 Jul 2021 17:15:45 +0000

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) <[email-masked]>
Sent: Wednesday, July 14, 2021 12:08 PM
To: Aijun Wang <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Linda Dunbar <[email-masked]>; 'Yingzhen Qu' <[email-masked]>; [email-masked]
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 14, 2021 at 4:37 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, 'Linda Dunbar' <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce1a6bb1151174fcb3bc008d946ea1d31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618793596728139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OoaZZGKRuWtDKeurkB6vjgbOk%2BoQncJ9U5VCatEDcnU%3D&reserved=0>.

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>; Yingzhen Qu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)

Linda -

Les,

Linda -

   Les

   Les

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce1a6bb1151174fcb3bc008d946ea1d31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618793596728139%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sTOqiTHYttBS%2F%2FqhZBK2e7lV3F56AnsGTL%2FanfKQqcE%3D&reserved=0>
Speaker: Linda Dunbar.

Thank you
Linda Dunbar

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&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce1a6bb1151174fcb3bc008d946ea1d31%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618793596738099%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EgXBgFKMTOjrUcj7P%2B3y7FpUZ1gidjCPvydJUj3LZDU%3D&reserved=0>.

Thanks,
Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Jul 2021 17:40:43 +0000

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 <[email-masked]>
Date: Wednesday, July 14, 2021 at 1:16 PM
To: Acee Lindem <[email-masked]>, Aijun Wang <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, Yingzhen Qu <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

Aijun, Linda,

Hi, Les and Acee:

Best Regards

Aijun Wang
China Telecom

Linda –

Les,

Linda –

   Les

   Les

Hi Linda,

Acee,

Thanks,
Acee

Any other concerns?

Thank you
Linda Dunbar

Speaking as WG member:

Hi Linda,

Yingzhen and LSR Chairs,

Thank you
Linda Dunbar

Hi all,

Thanks,
Yingzhen