[Idr] following up with GitHub open issues for draft-ietf-idr-5g-edge-service-metadata

[Linda Dunbar <[e-mail]>]

Jeff,

Can you please check if the following resolutions can adequately address the open  Issue 13 & 36?
If yes, can you please close them?


  1.  https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata/issues/36

The intent of this document is not to specify how BFD is set up or operated, but rather to describe how an edge router propagates faults detected within the Edge DC-using proprietary or alternative mechanisms-when standard BFD is either not supported inside the Edge DC or is not integrated with the BFD session that edge routers have with remote ingress routers. The focus is on enabling the ingress routers to make informed path selection decisions based on metadata rather than relying on BFD for failure detection inside the DC.

Do you think the following wording change under Site Physical Availability Index Metadata can make it clearer?

Old:
If the access network attached to the egress router doesn't support BFD, it can be challenging for
the egress router to directly notify ingress routers about failures within the access network.
However, if BFD is implemented on the access network, concatenated path down mechanisms
can be employed to propagate failure information more effectively.
New:

If the network within the Edge DC, which connects services to the DC egress router, relies on proprietary or deployment-specific methods to detect faults instead of BFD, these faults can be propagated to ingress routers using BGP Metadata Path Attributes. When BFD is implemented on the network within the DC  and integrated with the egress router's session to remote ingress routers, concatenated path-down mechanisms can be employed to propagate failure information more effectively. However, this document does not assume that BFD is required or supported within the Edge DC.


  1.  https://github.com/ietf-wg-idr/draft-ietf-idr-5g-edge-service-metadata/issues/13

The Capacity Availability Index Metadata is not associated with a specific protocol or procedural interaction. Instead, its purpose is to enable ingress routers to associate received routes with a common Site-ID. This allows an egress router to propagate failure information efficiently with a single update, rather than sending multiple updates for each individual prefix.



Do you think the following wording change can make it clearer?



Route-Flag in the Sub-TLV (Section 4.3):

Old:

Route-Flag I (1 bit): is a flag bit. When set to 1, the Site Availability Index is for BGP speakers

(receivers) to associate the routes with the Site-ID. The Site Availability Percentage value is

ignored. When set to 0, the BGP speakers (receivers) should apply the Site Availability Index

value to all the routes associated with the Site-ID.



New:



Route-Flag I in the Sub-TLV (Section 4.3):

*              Route-Flag I is a flag bit. When set to 1, the Site Availability Index is for BGP speakers (receivers) to associate the routes with the Site-ID. The Site Availability Percentage value is ignored.

*              When set to 0, the BGP speakers (receivers) should apply the Site Availability Index value to all the routes associated with the Site-ID.





Section 4.3.1:

Old:

The Site Physical Availability Index Sub-TLV (with RouteFlag-I=1) is for ingress routers to associate the Site Identifier with the prefixes.



New:

When the Capacity Availability Index Metadata is attached to a client prefix in a BGP update, it enables ingress routers to associate the client prefix with a Site-Index, effectively grouping prefixes that belong to the same site.

When the Capacity Availability Index Metadata is attached to a loopback address in a BGP update, it serves as a site-wide indicator, notifying receiving routers that all prefixes associated with the Site-Index are impacted. This allows ingress routers to efficiently apply routing adjustments in response to the site-wide event..

Thank you very much,

Linda