[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 <[e-mail]>]

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) <[e-mail]>
Sent: Wednesday, July 14, 2021 12:41 PM
To: Linda Dunbar <[e-mail]>; Aijun Wang <[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>; 'Yingzhen Qu' <[e-mail]>; [e-mail]
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 14, 2021 at 1:16 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, Aijun Wang <[e-mail]<mailto:[e-mail]>>, "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>, Yingzhen Qu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 14, 2021 12:08 PM
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; 'Yingzhen Qu' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 14, 2021 at 4:37 AM
To: "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>, 'Linda Dunbar' <[e-mail]<mailto:[e-mail]>>, Acee Lindem <[e-mail]<mailto:[e-mail]>>, Yingzhen Qu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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%7C8dd58f0d75234f9309c608d946ee86c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618812557513063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mjbzQcTc2BBHCEg1sTANZLfvgYrie43I5xRTyw7F79s%3D&reserved=0>.

Do you have other concerns for such solution?

Best Regards

Aijun Wang
China Telecom

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 12, 2021 8:32 PM
To: Acee Lindem (acee) <acee=[e-mail]<mailto:acee=[e-mail]>>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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?

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

+1 to Acee's other comments.

   Les


From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Acee Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, Yingzhen Qu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 prefixes and not applications while the draft uses these two interchangeably.

Thanks,
Acee


Any other concerns?

Thank you
Linda Dunbar

From: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, Christian Hopps <[e-mail]<mailto:[e-mail]>>, Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
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%7C8dd58f0d75234f9309c608d946ee86c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618812557523016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oHkqg7dn%2BnmcKW2mKPNeDsg7CxqW12IZjZD1PDvLI84%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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Yingzhen Qu
Sent: Wednesday, June 30, 2021 4:00 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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%7C8dd58f0d75234f9309c608d946ee86c5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637618812557532971%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fqYIJ%2F9N649fCUehga6%2FQjEcr3vcvQjVHWSc1FchqAs%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 [e-mail]<mailto:[e-mail]>. Please include name of the presenter, pointer to the draft and time estimation including Q&A.

Thanks,
Yingzhen