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

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 14 July 2021 08:36 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480993A18AD; Wed, 14 Jul 2021 01:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpO_OAloF5dM; Wed, 14 Jul 2021 01:36:32 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3690E3A18B0; Wed, 14 Jul 2021 01:36:29 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 7C0E51C00E1; Wed, 14 Jul 2021 16:36:26 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: "'Les Ginsberg (ginsberg)'" <ginsberg=40cisco.com@dmarc.ietf.org>, 'Linda Dunbar' <linda.dunbar@futurewei.com>, "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>, 'Yingzhen Qu' <yingzhen.ietf@gmail.com>, lsr@ietf.org
Cc: lsr-chairs@ietf.org
References: <CO1PR13MB49205570912CA823A3002A1685159@CO1PR13MB4920.namprd13.prod.outlook.com> <11585166-801F-4CE2-9E2B-D30141915776@cisco.com> <BY5PR11MB433793E4073EF414A68B4227C1149@BY5PR11MB4337.namprd11.prod.outlook.com> <CO1PR13MB4920D8676F69945DD64CC1CE85149@CO1PR13MB4920.namprd13.prod.outlook.com> <BY5PR11MB43375B6315919586DA33AFADC1139@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43375B6315919586DA33AFADC1139@BY5PR11MB4337.namprd11.prod.outlook.com>
Date: Wed, 14 Jul 2021 16:36:24 +0800
Message-ID: <000001d7788b$55275fb0$ff761f10$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D778CE.634DACF0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJRkZdNfawuq557nR0WQ7ucEYcMmgKfC90JAe2KBWoBpKvdJgHjz3GPqg1AESA=
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQkpJHlZLTxpPHhgZSR1JGkhVEwETFhoSFyQUDg9ZV1kWGg8SFR0UWUFZT0tIVU pKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NRw6FBw5Iz9LPgsQSjQ2SDgS LCoKCRxVSlVKTUlNSU5KTENMSUlMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU5PTUhPNwY+
X-HM-Tid: 0a7aa428f9dad993kuws7c0e51c00e1
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0Lk8IPxsD1BJYT9D-NcRQJEnwHU>
Subject: Re: [Lsr] IP layer metrics collected by Edge routers - draft-dunbar-lsr-5g-edge-compute-ospf-ext (was: LSR Presentation Slot request)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 08:36:38 -0000

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: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg
(ginsberg)
Sent: Wednesday, July 14, 2021 1:36 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>; Acee Lindem (acee)
<acee=40cisco.com@dmarc.ietf.org>; Yingzhen Qu <yingzhen.ietf@gmail.com>;
lsr@ietf.org
Cc: lsr-chairs@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 <linda.dunbar@futurewei.com
<mailto:linda.dunbar@futurewei.com> > 
Sent: Tuesday, July 13, 2021 1:02 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com <mailto:ginsberg@cisco.com>
>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org
<mailto:acee=40cisco.com@dmarc.ietf.org> >; Yingzhen Qu
<yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org
<mailto:lsr@ietf.org> 
Cc: lsr-chairs@ietf.org <mailto:lsr-chairs@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) <ginsberg@cisco.com
<mailto:ginsberg@cisco.com> > 
Sent: Monday, July 12, 2021 8:32 PM
To: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org
<mailto:acee=40cisco.com@dmarc.ietf.org> >; Linda Dunbar
<linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >; Yingzhen
Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org
<mailto:lsr@ietf.org> 
Cc: lsr-chairs@ietf.org <mailto:lsr-chairs@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? 

 

[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 <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> > On Behalf Of
Acee Lindem (acee)
Sent: Monday, July 12, 2021 5:06 PM
To: Linda Dunbar <linda.dunbar@futurewei.com
<mailto:linda.dunbar@futurewei.com> >; Yingzhen Qu <yingzhen.ietf@gmail.com
<mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> 
Cc: lsr-chairs@ietf.org <mailto:lsr-chairs@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 <linda.dunbar@futurewei.com
<mailto:linda.dunbar@futurewei.com> >
Date: Monday, July 12, 2021 at 5:41 PM
To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com> >, Yingzhen Qu
<yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >, "lsr@ietf.org
<mailto:lsr@ietf.org> " <lsr@ietf.org <mailto:lsr@ietf.org> >
Cc: "lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> " <lsr-chairs@ietf.org
<mailto:lsr-chairs@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 prefixes and not applications while the
draft uses these two interchangeably. 

 

Thanks,

Acee

 

 

Any other concerns? 

 

Thank you

Linda Dunbar

 

From: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> > 
Sent: Monday, July 12, 2021 4:04 PM
To: Linda Dunbar <linda.dunbar@futurewei.com
<mailto:linda.dunbar@futurewei.com> >; Yingzhen Qu <yingzhen.ietf@gmail.com
<mailto:yingzhen.ietf@gmail.com> >; lsr@ietf.org <mailto:lsr@ietf.org> 
Cc: lsr-chairs@ietf.org <mailto:lsr-chairs@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 <linda.dunbar@futurewei.com
<mailto:linda.dunbar@futurewei.com> >
Date: Monday, July 12, 2021 at 4:27 PM
To: Yingzhen Qu <yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@gmail.com> >,
"lsr@ietf.org <mailto:lsr@ietf.org> " <lsr@ietf.org <mailto:lsr@ietf.org> >
Cc: "lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org> " <lsr-chairs@ietf.org
<mailto:lsr-chairs@ietf.org> >
Subject: RE: [Lsr] LSR Presentation Slot Requests - IETF111
Resent-From: <alias-bounces@ietf.org <mailto:alias-bounces@ietf.org> >
Resent-To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com> >, Christian
Hopps <chopps@chopps.org <mailto:chopps@chopps.org> >, Yingzhen Qu
<yingzhen.ietf@gmail.com <mailto:yingzhen.ietf@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://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 <lsr-bounces@ietf.org <mailto:lsr-bounces@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-chairs@ietf.org <mailto:lsr-chairs@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%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 lsr-chairs@ietf.org
<mailto:lsr-chairs@ietf.org> . Please include name of the presenter, pointer
to the draft and time estimation including Q&A. 

 

Thanks,

Yingzhen