[Idr] BGP-Extension - 20240104

[[e-mail]]

Hi, Linda,
Thanks for a profound discussion about the document. About the recent updated version, we’ve got some incremental comments listed in the attatched file.
 
Best regards,
Dongyu Yuan




袁冬宇
IT开发工程师
软件平台开发一部/有线研究院/系统产品_有线产品经营部


中兴通讯股份有限公司
南京市雨花台区紫荆花路68号南研一期2楼B2
M: [phone]
E: [e-mail]




Original


From: LindaDunbar <[e-mail]>
To: 袁冬宇10335620;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2023年11月18日 01:40
Subject: RE: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt



Dong Yu,
 
Thank you for the suggested wording.
They look good. A minor grammar changes to make it more readable:
“Aiming to reduce the entries advertised in the control plane and damp the routes update in the forwarding plane, aggregated metrics can be carried in BGP updates in stead of detailed measurements.” ->
 
“The aggregated metrics can be carried in the BGP Update message instead of detailed measurements to reduce the entries advertised in the control plane and dampen the routes update in the forwarding plane.”
 
Linda
 

From: [e-mail] <[e-mail]> 
 Sent: Friday, November 17, 2023 3:29 AM
 To: Linda Dunbar <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt


 
Thanks, Linda. I've made some modification.  Looking forward to your feedback.
 
Multiple instances of the same service could be attached to one egress router. The egress router can have preconfigured policies on aggregating various measurements. Aiming to reduce the entries advertised in the control plane and damp the routes update in the forwarding plane, aggregated metrics can be carried in BGP updates in stead of detailed measurements. Upon receiving packets from ingress routers, the egress router can use its policies to choose an optimal path to one service instance.
Many measurements could impact and correspondingly reflect service performance. In order to simplify an optimal selection process, egress routers can have preconfigured policies or algorithms to aggregate multiple metrics into one simple one to ingress routers. Though out of the scope of this document, an egress router can also have an algorithm to convert multiple metrics to network metrics, an IGP cost for instance, to pass to ingress nodes. This decision-making process integrates network metrics computed by traditional IGP/BGP and the service delay metrics from egress routers to achieve a well-informed and adaptive routing approach. This intelligent orchestration at the edge not only enhances the service's overall performance but also optimizes resource utilization across the distributed infrastructure. 
 
Best regards
Dongyu Yuan
 

袁冬宇
IT开发工程师
软件平台开发一部/有线研究院/系统产品_有线产品经营部
 
中兴通讯股份有限公司
南京市雨花台区紫荆花路68号南研一期2楼B2
M: [phone]
E: [e-mail]




Original

From: LindaDunbar <[e-mail]>



To: 袁冬宇10335620;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2023年11月17日 02:19



Subject: RE: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt




Dong Yu,
 
Are you assuming there are multiple instances of the same service being attached to one Egress router? Therefore,

The egress router should have a policy on how to aggregate the metrics for reaching individual instances into a single value to pass to the interested ingress nodes.

Upon receiving packets from ingress routers, the egress router can use its own policy to choose an optimal path to one instance for the service.

Egress router can have algorithm to aggregate multiple metrics into one simple metrics which can be merged the IGP cost to pass to ingress nodes in the traditional way.


 
 
How about we add a section in the Section 5 (Decision Process) to briefly describe the behavior of Egress router? Please let us know if those text addressed your concern.
Thanks, Linda
-------------------------------------------------------
 
5.1.  Egress Node Behavior
 
   Multiple instances of the same service could be attached to one
   egress router.  The egress router can have preconfigured policies on
   aggregating various measurements to a simple metric that the ingress
   routers can use to integrate with traditional network metrics for
   path selection.  Upon receiving packets from ingress routers, the
   egress router can use its policies to choose an optimal path to one
   service instance.
 
   Many measurements could impact service delay.  Egress routers can
   have preconfigured policies or algorithms to aggregate multiple
   metrics into one simple one to ingress routers.  Though out of the
   scope of this document, an egress router can have an algorithm to
   convert multiple metrics to an IGP cost to pass to ingress nodes.
   This decision-making process integrates network metrics computed by
   traditional IGP/BGP and the service delay metrics from egress routers
   to achieve a well-informed and adaptive routing approach.  This
   intelligent orchestration at the edge not only enhances the service's
   overall performance but also optimizes resource utilization across

   the distributed infrastructure.


 

From: [e-mail] <[e-mail]> 
 Sent: Thursday, November 9, 2023 1:38 AM
 To: Linda Dunbar <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt


 
Thanks, Linda,
1. Section 3: “the egress further to do a local lookup and selects the optimal service location respectively according to the local Metadata of path and service attributes.”
[Linda] That could be true. Need a separate draft to describe the behavior.  draft-ietf-idr-5g-edge-service-metadata is only about encoding of BGP UPDATE.
 
[Dongyu Yuan] I partly agree that the behavior might require another separate draft to describe. The initial idea to raise the comment is attributed to the expression in the draft,  ‘It encapsulates the packet destined towards the optimal egress node.’ Regarding the mentioned usecase above, a successive egress behaviour description seems complete an overall end-to-end workflow and fulfills a whole framework.
 
2. An abstract simple metric which can be calculated by specific functions and algorithms utilizing a set of metadata as input variables. The purpose is to simplify the decision-making process for path selection. The simple metric would influence BGP selection in a traditional way. For instance, the less the service metric, the higher priority of the next hop.
[Linda] Do you mean changing the text in the -12 version to the following?
“Alternative, an abstract simple metric can be calculated by a specific function or an algorithm utilizing the set of metrics carried by the Metadata Path Attribute. The purpose is to simplify the decision-making process for the path selection.”.
 
[Dongyu Yuan] I’d prefer the previous -12 version. Meatadata PA could be carried from Egress to Ingress, a converted ‘service metric’ could also be a new defined PA in BGP Update. In the current 5.1 and 5.2 of -12 version, decisions can be made according to algorithms using NetD, Pref and CP. With an abstract metric calculated, it is also an applicable way to directly compare converted ‘service metric’ carried in BGP Update in order to decide next hop.
 
3. A set of metrics which aligns with the network metrics. The processing delay of the site and the transmission delay of the network belong to the same dimension of metrics. The price of deployment and a current load may also be converted as a Cost value which also exist in Underlay network. Therefore, if a set of metadata to describe service capabilities is able to be transformed into a set of metrics align with the network metrics, delay, bw, loss, IGP Cost for instance, edge sites or service instances would be able to virtually join the network domain. Afterwards, the selection of next hop and the orchestration of paths would be easier which inherits the traditional network way.
[Linda] Do you mean “price of deployment and the current load may also be converted to the cost of the Underlay Network”? Can you please elaborate?
 
[Dongyu Yuan] We have many metrics in an IGP underlay network, link delay, link loss, link bw, IGP cost, TE metric, etc. Suppose service metrics collected or measured can be converted as:
(This is a temporary example. May not be appropriate, specific algorithms could be discussed in the future.)
a)Transporting delay + computing/process delay ----> virtual link delay(egress - edge site/instance)
b)Min(Computational bandwidth, storage bandwidth, link bw from egress to edge site/instance) ----> virtual link bandwidth(egress - edge site/instance)
c)Preference of site ----> virtual link IGP Cost/TE metric(egress - edge site/instance).
If it is applicable, the edge site or service instance could be orchestrated together with the underlay network.
 
ingress------delay,bw,cost,...-------egress---------‘virtual link’  (converted) delay,bw,cost,...------------edge site/instance
                
Possible benefits include:
a) For end-to-end services, we always raise end-to-end SLA requirements, end-to-end delay, end-to-end min bw, the mentioned scheme could make the orchestration easier. End-to-end delay = link1 delay+link2 delay+...+virtual link delay, End-to-end TE Metric= link1 TE Metric+...+virtual link TE Metric.
b) A unified TE method could be inherited. In the past, we apply SPF/CSPF with metrics including delay, bw, loss, cost, etc. With service metrics introduced, the former scheme maintains the same.
Thus, a possible suggestion here is that metrics in Metadata PA could be align with network metrics and converted as same dimensions. BGP Decision module for services in 5.2 could be further cooperates with conventional LSDB and TEDB to perform unified path decision and TE.
 
Best regards,
Dongyu Yuan
 
 
 
 

袁冬宇
IT开发工程师
软件平台开发一部/有线研究院/系统产品_有线产品经营部
 
中兴通讯股份有限公司
南京市雨花台区紫荆花路68号南研一期2楼B2
M: [phone]
E: [e-mail]




Original

From: LindaDunbar <[e-mail]>



To: 袁冬宇10335620;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2023年11月09日 01:26



Subject: RE: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt




Dong Yu,
Thank you very much for the comments.
Resolutions are inserted below, which will be reflected in -13 version.
 

From: [e-mail] <[e-mail]> 
 Sent: Tuesday, November 7, 2023 8:27 AM
 To: Linda Dunbar <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt


 
Hi, Linda,
For previous e-mails which I’ve forgot to cc to the mailing list. I’m quite sorry for that. To clarify the previous comments:
 
1. Section 3: “the egress further to do a local lookup and selects the optimal service location respectively according to the local Metadata of path and service attributes.”
 
The Metadata is not meant to be carried in the data packets within the data plane. With considerations of a condition in which ubiquitous service instances may be deployed in a distributed manner, it is a possible scene that multiple instances locate behind a same egress node to provide a same Edge Service. Thus, the egress router is also supposed to do a similar lookup in a 'local' FIB (with ANYCAST IP or Service ID as the 'key') to determine a 'best' or 'appropriate' instance. The routes in the mentioned 'local' FIB here is also installed according to the locally collected Metadata information.
[Linda] That could be true. Need a separate draft to describe the behavior.  draft-ietf-idr-5g-edge-service-metadata is only about encoding of BGP UPDATE.
 
2. Section 5: “When a set of service Metadata is converted to a simple metric, a decision process is determined by the metric semantics and deployment situations. The goal is to integrate the conventional network decision process with the service Metadata into a unified decision-making process for the path selection.”
 [Linda] The RED is from the draft. 
It is appreciated that you’ve added into the draft, but I still hope to make a little bit explanations. I think that the form to express service capabilities of an edge site or a service instance include at least the following schemes:
1) Metadata as you’ve already mentioned in the initial work that can be carried in TLVs.
2) An abstract simple metric which can be calculated by specific functions and algorithms utilizing a set of metadata as input variables. The purpose is to simplify the decision-making process for path selection. The simple metric would influence BGP selection in a traditional way. For instance, the less the service metric, the higher priority of the next hop.
[Linda] Do you mean changing the text in the -12 version to the following?
“Alternative, an abstract simple metric can be calculated by a specific function or an algorithm utilizing the set of metrics  carried by the Metadata Path Attribute. The purpose is to simplify the decision-making process for the path selection.”.
 
 
3) A set of metrics which aligns with the network metrics. The processing delay of the site and the transmission delay of the network belong to the same dimension of metrics. The price of deployment and a current load may also be converted as a Cost value which also exist in Underlay network. Therefore, if a set of metadata to describe service capabilities is able to be transformed into a set of metrics align with the network metrics, delay, bw, loss, IGP Cost for instance, edge sites or service instances would be able to virtually join the network domain. Afterwards, the selection of next hop and the orchestration of paths would be easier which inherits the traditional network way.
 [Linda] Do you mean  “price of deployment and the current load may also be converted to the cost of the Underlay Network”? Can you please elaborate?
Best regards,
Dongyu Yuan
 
 
 
 

袁冬宇
IT开发工程师
软件平台开发一部/有线研究院/系统产品_有线产品经营部
 
中兴通讯股份有限公司
南京市雨花台区紫荆花路68号南研一期2楼B2
M: [phone]
E: [e-mail]




Original

From: LindaDunbar <[e-mail]>



To: 袁冬宇10335620;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2023年10月20日 05:53



Subject: RE: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt




Dong Yu,
 
Thank you very much for the comments. Need to confirm your requested addition.
Can you give some explanation on the detailed scenario that requires the egress further to do a local lookup and selects the optimal service location respectively according to the local Metadata of path and service attributes?
 
Are you assuming that the Metadata is included in the data packets?
The “Metadata Path Attribute”  of this document is one attribute in the BGP UPDATE message from on egress node to ingress nodes. They are not meant to be attached to data packets.
 
 
 
3.2.  Ingress Router Forwarding Behavior      When the ingress router receives a packet and does a lookup on the    route in the FIB, it gets the destination prefix's whole path.  It    encapsulates the packet destined towards the optimal egress node. The egress further does a local lookup and selects the optimal service location respectively according to the local Metadata of path and service attributes. 
 
 
For your suggested addition to Section 5.1:
When a set of service Metadata is converted as a simple metric, a decision process is determined by the metric sematics. Under appropriate circumstances of both service requirements and service performance property, the metrics from the service as well as its associated instances are able to be in line with that of network metrics for the benefits of unified decision making process and seamless end-to-end routing and forwarding.Thus, a conventional network decision process is able to be directly inherited. 
 
Grammarly Tool showed several language errors. Does the following statement correctly represent what you want to express?
“When a set of service Metadata is converted to a simple metric, a decision process is determined by the metric semantics and deployment situations. The goal is to integrate the conventional network decision process with the service Metadata into a unified decision-making process for the path selection.”
 
 
Thank you,
Linda
 

From: [e-mail] <[e-mail]> 
 Sent: Thursday, October 19, 2023 12:37 AM
 To: Linda Dunbar <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt


 
Hi, authors, I have read through this draft [draft-ietf-idr-5g-edge-service-metadata-09.txt], and I've got some comments listed in the attachment file (about Section 3.2 and 5.1), thanks.  

袁冬宇
IT开发工程师
软件平台开发一部/有线研究院/系统产品_有线产品经营部
 
中兴通讯股份有限公司
南京市雨花台区紫荆花路68号南研一期2楼B2
M: [phone]
E: [e-mail]




Original

From: LindaDunbar <[e-mail]>



To: Igor Malyushkin <[e-mail]>;



Cc: [e-mail] <[e-mail]>;draft-ietf-idr-5g-edge-service-metadata <[e-mail]>;idr <[e-mail]>;



Date: 2023年10月19日 04:50



Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt




_______________________________________________
 Idr mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/idr

Igor,
 
I am very sorry for missing your comments posted on the mailing list.
 
The replies to your questions and resolutions are inserted below.
If you are attending IETF118, we can also discuss in person more.
 
Thank you for the valuable comments .
Linda
 
 
 
Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-07.txt
Igor Malyushkin <[e-mail]> Fri, 11 August 2023 13:20 UTCShow header
Hello authors,
 
I've read this draft and have several questions.
 
*First*, it's not crystal clear to me the procedure of next-hop addresses'
manipulation. Section 5.2 says:
 
When an ingress router receives BGP updates for the same IP
  address from multiple egress routers, all those egress routers
  are considered as the next hops for the IP address. For the
  selected services configured to be influenced by the Edge
  Service Metadata, the ingress router's BGP Decision process
  [IDR-CUSTOM-DECISION] would trigger the Edge Service
  Management function to compute the weight to be applied to the
  route's next hop in the forwarding plane.
 
So, from the text above I expect that for the selected routes the
decision-altered process constructs a separate next-hop structure with
weighted records.
 
[Linda] The Figure 6 is intended for showing the additional function “EdgeServiceMgn” to handle the details of the weighted records. Please see the newly proposed text to see if it addresses your concern. If not, please propose a new text.   
.
 
  Suppose a destination address for aa08::4450 can be reached by
  three next hops (R1, R2, R3). Further, suppose the local BGP's
  Decision Process based on the traditional network layer
  policies & metrics identifies the R1 as the optimal next hop
  for this destination (aa08::4450). The Edge Service Metadata
  might result in R2 as the optimal next hop for the prefix and
  influence the Forwarding Plane.
 
What is the resulting next-hop/next-hops for aa04::4450? Would it be a
single next-hop, selected by the Edge Service Metadata function, or it be a
weighted pair of R1 & R2?
[Linda]The resulting next-hop is R2. There is only a single Next-hop computed until the weighted algorithm compute a different one.  How about changing the paragraph to the following?
 
“Suppose a destination address for aa08::4450 can be reached by three next hops (R1, R2, R3). Further, suppose the local BGP's Decision Process based on the traditional network layer policies and metrics identifies the R1 as the optimal next hop for this destination (aa08::4450). If the Edge Service Metadata results in R2 as the optimal next hop for the prefix, the Forwarding Plane will have R2 as the next-hop for the destination address of aa08::4450.”
 
 
So, I'm concerned with "to compute the weight to be applied to the route's
next hop in the forwarding plane" and "The Edge Service Metadata
influencing next-hop selection is different from the metric (or weight) to
the next hop" statements. Isn't here some contradiction?
 
[Linda] no. The Edge Service Metadata is just another attribute in addition to other attributes described in [IDR-CUSTOM-DECISION] in determining the optimal next hop for the prefix.
 
*Second*, from my understanding, some egress router advertises several
prefixes with the Metadata Path Attribute, these prefixes contain anycast
service routes. To manipulate these routes at once the egress router sends
just a route of its next-hop address, equal to the next-hop address of the
routes in question, and the new Metadata Path Attribute.
Is my understanding correct that a receiving ingress router still needs to
process its RIB, and then FIB, route by route?
 
[Linda] The Edge Service routes are a small number of routes that subscribers paid premium. They should be separated from other regular routes.
 
 
The next question is, will the egress router eventually send the affected
anycast routes with the new values of the Metadata Path Attribute?
 
[Linda] do you mean that “egress routers will send the updated metadata path attributes for the affected routes”? The answer is YES.  
 
*Third*, Section 6 looks the most questionable.
 
    Service Metadata are only distributed to the relevant ingress
    nodes interested in the Service, which can be configured or
    automatically formed.
 
For this task, it is offered to use RTC/RTF mechanism later. But from
Section 4.1, I see that the Metadata Path Attribute can be attached to
non-VPN routes (1/1). Here either vanilla routes dissipated uncontrolled
through the network, or this draft offers to use RTC/RTF for them too. Can
you please clarify this point?
 
[Linda] RFC4684 allows the Route Target to be individual IP Address Prefixes. The second paragraph says:
For each registered low-latency Service, BGP RT Constrained
Distribution [RFC4684] can be used to form the Group interested in
the Service. The "Service ID", an IP address prefix, is the Route
Target.
 
The "Service ID," an IP address
   prefix, is the Route Target.
[Linda] Yes. The RFC4684 clearly states that Route Target can be an IP address.
 
 
This statement is absolutely unclear to me. Should every route have an RT
with its address in the Global Administrator field? I'm sure, I'm reading
this sentence wrong. Can you also clarify it?
[Linda] Only a small number of premium Edge service IDs are used.
 
When an ingress router receives
   the first packet of a flow destined to a Service ID, the
   ingress router sends a BGP UPDATE that advertises the Route
   Target membership NLRI per RFC4684.
 
I always thought that RTC/RTF procedures are premature. In other words, to
construct a distribution tree prior to any forwarding. Here I see exactly
the opposite logic.
[Linda] The ingress routers should register for the interested Service IDs prior to any forwarding.
 
Next, when the first packet of a flow arrives, what will a receiving router
do with this packet and all the coming packets from this flow until it
signals a distribution tree? What if there are lots of packets destined for
many Service IDs at a single moment in time? I expect some burden on the
CPU of the router.
 
[Linda] as said before, those premium Edge Service IDs are pre-registered.
 
Upon receiving a packet destined
   for the Service ID, the ingress router must refresh the Timer.
   The ingress router must send a BGP Withdraw UPDATE for the
   Service ID upon expiration of the Timer
 
It is not clear what means "must send a BGP Withdraw UPDATE". From my
understanding, the ingress router receives routes with Service IDs (and
does not propagate them further). Maybe it is about a RTC/RFC membership
route? If so, my next question is: will routes distribution trees live
depend on the Timer?
 
[Linda] “Withdraw UPDATE” message is sent when the egress site encounter events that cause those routes no longer reachable. The “Withdraw UPDATE” is for the ingress nodes to recompute the optimal nexthop.  RTC/RFC membership is for RR to determine which ingress nodes should receive this “WITHDRAW UPDATE”.
 
*Fourth*, despite that this draft says that a new path attribute should be
confined to a single domain all of us know that with optional transitive
attributes, there is always a possibility of leaking them outside. Should
this draft express this situation in its security considerations?
 
[Linda] Thanks for the suggestion. How about we add the following to the Security Section?
 
“The proposed Edge Service Metadata are advertised within the trusted domain of 5G LDN’s ingress and egress routers. The ingress routers should not propagate the Edge Service Metadata to any nodes that are not within the trusted domain”.
Thank you.
Linda
 
Thank you in advance.
 
чт, 10 авг. 2023 г. в 04:52, <[e-mail]>:
 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Inter-Domain Routing
> (IDR) WG of the IETF.
> 
>    Title           : BGP Extension for 5G Edge Service Metadata
>    Authors         : Linda Dunbar
>                      Kausik Majumdar
>                      Haibo Wang
>                      Gyan Mishra
>                      Zongpeng Du
>    Filename        : draft-ietf-idr-5g-edge-service-metadata-07.txt
>    Pages           : 24
>    Date            : 2023-08-09
> 
> Abstract:
>    This draft describes a new Metadata Path Attribute and some
>    Sub-TLVs for egress routers to advertise the Metadata about
>    the attached edge services (ES). The Edge Service Metadata can
>    be used by the ingress routers in the 5G Local Data Network to
>    make path selections not only based on the routing cost but
>    also the running environment of the edge services. The goal is
>    to improve latency and performance for 5G edge services.
> 
>    The extension enables an edge service at one specific location
>    to be more preferred than the others with the same IP address
>    (ANYCAST) to receive data flow from a specific source, like a
>    specific User Equipment (UE).
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/
> 
> There is also an htmlized version available at:
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-07
> 
> A diff from the previous version is available at:
> 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-5g-edge-service-metadata-07
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 
 
 

From: Igor Malyushkin <[e-mail]> 
 Sent: Tuesday, October 17, 2023 10:26 PM
 To: Linda Dunbar <[e-mail]>
 Cc: [e-mail]; draft-ietf-idr-5g-edge-service-metadata <[e-mail]>; idr <[e-mail]>
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt


 

Hi all,
 

Linda, I also posted several questions regarding this document some time ago. Can you please look at them? Thanks in advance.


 

https://mailarchive.ietf.org/arch/msg/idr/Dqs2SFnXU2t4eo6byp4oIwIvYcw/
 
 



 

ср, 18 окт. 2023 г. в 06:25, Linda Dunbar <[e-mail]>:



Yaohuijuan,
 
Thank you very much for your valuable comments.
 
Here are our resolutions to your suggested changes:
 
Section 3 Metadata Influenced Ingress Node Behavior:
 
The original text is
“The goal of this Edge Service Metadata Path Attribute is for egress routers to propagate the metrics about their running environment to ingress routers. Here are some examples of the metrics propagated by
the egress routers:”
 
 
For your following suggested addition, I think most of them, such as computing power, resources, etc. , should be discussed in the CATS WG. The purpose of BGP Metadata Path Attribute is to carry the detailed SUB-TLVs once those proposed metrics are finalized by CATS WG.

 
How about we change the text to:
“The goal of this Edge Service Metadata Path Attribute is for egress routers to propagate the metrics about their running environment to ingress routers. CATS WG has been created to identify more detailed metrics about edge services running environment, such as  [draft-ldbc-cats-framework]. Once those metrics are finalized, their corresponding sub-TLVs can be carried under the Metadata Path Attribute if those metrics need to be distributed by BGP. Here are some examples of the metrics propagated by the egress routers.”
 
Section 4.4 Service Delay Predication:
 
The original text of -09 is:
“The Service Delay Prediction Index is a value that predicts processing delays at the site for future service requests. The
higher the value, the longer of the delay.”
 
You suggest changing to the following:
The Service Delay Prediction Index is a value that predicts processing delays at the site for future service requests. The
higher the value, the longer of the delay. The Service Delay Prediction Index is one of computing service status information,which can also include service connections number, and service duration and so on.
 
What do you mean by “service connections number”?  what is your definition of “service duration” and “computing service status”?
 
Thank you very much,
Linda
 


From: [e-mail] <[e-mail]> 
 Sent: Wednesday, October 11, 2023 6:56 PM
 To: draft-ietf-idr-5g-edge-service-metadata <[e-mail]>
 Cc: idr <[e-mail]>; Linda Dunbar <[e-mail]>
 Subject: Re: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt



 

Hi, authors,


 

I have read through this document, it is clear to define the Metadata Path Attribute for the computing characters. I have some comments  in attachment,thanks. 



 

 
--------------------------------------------------------------------------------








[e-mail]





 

From: internet-drafts



Date: 2023-09-08 00:00



To: [e-mail]



CC: idr



Subject: [Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-09.txt





Internet-Draft draft-ietf-idr-5g-edge-service-metadata-09.txt is now



available. It is a work item of the Inter-Domain Routing (IDR) WG of the IETF.


 

   Title:   BGP Extension for 5G Edge Service Metadata



   Authors: Linda Dunbar



            Kausik Majumdar



            Haibo Wang



            Gyan Mishra



            Zongpeng Du



   Name:    draft-ietf-idr-5g-edge-service-metadata-09.txt



   Pages:   21



   Dates:   2023-09-07


 

Abstract:


 

   This draft describes a new Metadata Path Attribute and some Sub-TLVs



   for egress routers to advertise the Metadata about the attached edge



   services (ES).  The Edge Service Metadata can be used by the ingress



   routers in the 5G Local Data Network to make path selections not only



   based on the routing cost but also the running environment of the



   edge services.  The goal is to improve latency and performance for 5G



   edge services.


 

   The extension enables an edge service at one specific location to be



   more preferred than the others with the same IP address (ANYCAST) to



   receive data flow from a specific source, like a specific User



   Equipment (UE).


 

The IETF datatracker status page for this Internet-Draft is:



https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/


 

There is also an HTMLized version available at:



https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-09


 

A diff from the previous version is available at:



https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-5g-edge-service-metadata-09


 

Internet-Drafts are also available by rsync at:



rsync.ietf.org::internet-drafts


 
 

_______________________________________________



Idr mailing list



[e-mail]



https://www.ietf.org/mailman/listinfo/idr





_______________________________________________
 Idr mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/idr