[Idr] Re: [Cats] Re: [CATS & IDR] Discussing the distribution of service metrics via BGP[draft-lin-idr-distribute-service-metri]

[linchangwang <[e-mail]>]

Hi Linda

Thanks for the review and comments,  Please check inline below for responses with Changwang.


Thanks,
Changwang

发件人: Linda Dunbar <[e-mail]>
发送时间: 2024年6月7日 2:54
收件人: Robert Raszuk <[e-mail]>; linchangwang (RD) <[e-mail]>
抄送: cats <[e-mail]>; [e-mail]; [e-mail]; idr-chairs <[e-mail]>
主题: RE: [Cats] Re: [Idr] [CATS & IDR] Discussing the distribution of service metrics via BGP[draft-lin-idr-distribute-service-metri]

Dear Authors of  draft-lin-idr-distribute-service-metric<https://datatracker.ietf.org/doc/draft-lin-idr-distribute-service-metric/>,

I share the similar concern as Robert.

Your draft states that the goal for propagating the Service metrics is for optimal path selection. Therefore, those metrics should be carried by the Path Attribute, instead of NLRI. Creating a new BGP NLRI to carry metrics for path selection has many issues, such as


  *   BGP NLRI is primarily designed to carry reachability information, i.e., which IP prefixes are reachable through which paths. Path attributes, on the other hand, are designed to carry additional information about those paths, such as metrics for path selection. Mixing reachability information with path selection metrics complicates the protocol implementation.


  *   Changwang> The initial design of BGP NLRI was to carry IP prefixes, but with the extension of MP-BGP, BGP NLRI can also carry additional attribute information, such as BGP EVPN NLRI. The protocol implementation is not complex and can draw from the BGP EVPN NLRI for reference.



  *   Introducing a new NLRI type for metrics would significantly increase the complexity of BGP implementations. This complexity arises from the need to support, parse, and process a new type of NLRI in addition to the existing ones. It can lead to higher chances of bugs and interoperability issues.


  *   Changwang> The protocol implementation is not complex and can draw from BGP EVPN NLRI for reference.



  *   Existing BGP routers and systems are designed to understand and process standard NLRIs and path attributes. A new NLRI for metrics would require updates to all BGP routers to handle this new information correctly. This could cause compatibility issues with older devices that do not support the new NLRI, potentially leading to network instability.


  *   Changwang> The new NLRI does not need to be supported by all BGP routers, only the ingress, egress, and route reflector devices need to support it. The handling of the new NLRI is isolated from the existing NLRI in device implementation, so there will be no compatibility issues. On the contrary, using the existing NLRI to carry metric information may lead to compatibility issues.
  *


  *   Carrying metrics within NLRI can lead to redundancy, as the same metric information would need to be replicated across multiple NLRIs. This increases the overhead on the network, consuming more bandwidth and processing power compared to carrying the metrics once as path attributes.

Changwang>

  *   When designing a new address family, metadata can be placed within the NLRI, or it can continue to be placed within the attributes. The current preference is to place it within the NLRI, for the following reasons:
  *   BGP message encapsulation involves grouping NLRI with the same attributes together. As the metric information for each site may be different and subject to frequent updates due to periodic changes, placing metric information within the original NLRI's path attributes may result in each site having different metric attributes. This could lead to the inability to encapsulate NLRI from different sites within the same BGP message, which would increase network overhead as the scale expands. However, by using the new NLRI and placing metric information within the NLRI, it avoids the issue of being unable to encapsulate NLRI from different sites within the same BGP message due to changes in metric information. A comparison of the BGP encapsulation for the original NLRI and the new NLRI is as follows:
  *   Site Prefix Attributes
Site 1 1.1.1.1 Common PATH attributes + Metric Attribute 1
Site 2 1.1.2.1 Common PATH attributes + Metric Attribute 2
  *   BGP encapsulation for the original NLRI:
BGP UPDATE Message Header + Common PATH attributes + Metric Attribute 1 + NLRI(1.1.1.1);
BGP UPDATE Message Header + Common PATH attributes + Metric Attribute 2 + NLRI(1.1.2.1);
Due to the different attributes, two separate BGP UPDATE messages are required.
  *   BGP encapsulation for the new NLRI:
BGP UPDATE Message Header + Common PATH attributes + NLRI1(1.1.1.1 + Metric 1) + NLRI2(1.1.2.1 + Metric 2);
Since the attributes are the same, they can be encapsulated within a single BGP UPDATE message. The BGP encapsulation for the new NLRI reduces one BGP UPDATE Message Header and the Common PATH attributes compared to the original NLRI's encapsulation.



In addition,

  *   many metrics are related to a specific site, such as power, network conditions, which should be carried as Path Attribute for the site (i.e. NextHop) as specified by https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/
  *   the service metrics are meant to be sent to the ingress routers that make path selection. Intermediate routers can ignore the path attributes, while as if using new NLRI, all routers have to process them.

Changwang>
This document[https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/ ]
nicely illustrates BGP's scalability and the potential definition of meta properties, allowing for the distribution of routing attribute metrics through BGP.
The main reasons for adopting a new address family   for distributing computational power metrics are as follows:

  1.  On the existing address family, adding attributes can only accommodate the scenario where computational power is identified by IP address, and it is not feasible for future extensions.
  2.  For traditional routing, the old address family must enable the add-path feature to ensure the multi-instance sending of computational power; this requires an extension to the old address family.
  3.  Minimize the impact on the existing address family. The periodic transmission of computational power metrics will impact the existing address family.
  4.  Metadata properties can be placed within the NLRI of the new address family, or they can continue to be placed within the attributes of the new address family. If metadata keeps changing, it is not suitable to be placed within the attributes as it would lead to continuous small BGP updates being sent.
  5.  Computational power metrics can be reported directly to the controller or route reflector, independent of the existing address family.
  6.  Consideration for expanding functionality and implementing on-demand periodic announcements.

My two cents.

Linda

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 6, 2024 3:09 AM
To: linchangwang <[e-mail]<mailto:[e-mail]>>
Cc: cats <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; idr-chairs <[e-mail]<mailto:[e-mail]>>
Subject: [Cats] Re: [Idr] [CATS & IDR] Discussing the distribution of service metrics via BGP[draft-lin-idr-distribute-service-metri]

Dear Authors of  draft-lin-idr-distribute-service-metric<https://datatracker.ietf.org/doc/draft-lin-idr-distribute-service-metric/>,

I have read your proposal with interest.

I have a few comments on it.

#1 Fundamental - The document as written today is not scalable. However if you just slightly modify the proposal and insert in between Subscriber and Publisher a regular Route Reflector or Route Server I do believe we will start to have a solid base for discussion.

#2 Editorial - There are a number of terms in this document which should be renamed to better reflect their role. Example: "Register Route" advertisement should be renamed to "Service Metric Advertisement" or something that is not a synonym of Subscribe Route.

In general IMO we should discourage advertising service metrics using BGP. I understand that as we have TCP sessions we are loading BGP more and more simply for convenience. BGP is a "spray and pray" protocol. Not a pub/sub bus.

So at very minimum a section in this document should discuss alternative options to distribute service metrics to RRs/Controllers and highlight why using BGP would be superior.

Kind regards,
Robert


On Thu, Jun 6, 2024 at 11:11 AM linchangwang <[e-mail]<mailto:[e-mail]>> wrote:
Hi Wg,

Link: https://datatracker.ietf.org/doc/html/draft-lin-idr-distribute-service-metric-02

This document is based on the extension address families of BGP for distributing the computing metrics of CATS.
It primarily focuses on the following aspects:

1. Transmitting computing metrics information through the new BGP extension address families to ensure isolation from the routing information of other existing address families.
  This approach can enhance the performance of computing routing while minimizing the impact on existing address families.

2. Implementing dynamic subscriptions of corresponding computing metrics through BGP-extended routes based on the on-demand concept to mitigate the repercussions of periodic computing metrics updates.

3. Defining computing metrics information in the new NLRI of BGP, rather than in the attributes of BGP. This enhances the efficiency of computing routing transmission and processing, and overall performance.

4. Normalizing computing metrics measurement information.

We welcome any comments and discussions.

Thank you!

Thanks,
Changwang


-----邮件原件-----
发件人: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
发送时间: 2024年6月6日 13:22
收件人: [e-mail]<mailto:[e-mail]>
主题: I-D Action: draft-lin-idr-distribute-service-metric-02.txt

Internet-Draft draft-lin-idr-distribute-service-metric-02.txt is now available.

   Title:   Distribute Service Metric By BGP
   Authors: Changwang Lin
            Huijuan Yao
   Name:    draft-lin-idr-distribute-service-metric-02.txt
   Pages:   20
   Dates:   2024-06-05

Abstract:

   When calculating the path selection for service traffic, it is
   important to consider not only network metrics, but also the impact
   of service Metric. Therefore, it is necessary to transmit service
   Metric information from the server site to the user access site, in
   order to facilitate path selection for service traffic at the access
   router.

   This document describes an approach for using the BGP Control Plane
   to steer traffic based on a set of metrics that reflect the
   underlying network conditions and other service-specific state
   collected from available service locations.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-lin-idr-distribute-service-metric/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-lin-idr-distribute-service-metric-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-lin-idr-distribute-service-metric-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!
_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>