[Idr] Re: revision idr-5g-edge-service-metadata to address Route selection issues #40 on the GitHub

[Linda Dunbar <[e-mail]>]

Gyan,

Thank you very much for the suggestion.

What do you think of the following wording changes to incorporate a reference to ORR to address the hot potato routing issue in the section discussing RR-computed routes?

In Section 6: Policy-Based Metadata Integration, under the subsection "At the Route Reflector (RR)", modify the existing text to incorporate ORR:

Current Text:

In deployments where RRs are responsible for pre-selecting routes, the RR integrates metadata and traditional BGP attributes when determining the "best" route. The RR reflects only the selected route to its client routers (e.g., Ingress PEs). This ensures that the reflected route already aligns with service-specific requirements.

Revised Text (with ORR reference):

In deployments where RRs are responsible for pre-selecting routes, the RR integrates metadata and traditional BGP attributes when determining the "best" route. The RR reflects only the selected route to its client routers (e.g., Ingress PEs), ensuring alignment with service-specific requirements. To mitigate hot potato routing issues, deployments SHOULD consider Optimal Route Reflection (ORR) as specified in [RFC9107], which enables the RR to compute and advertise routes based on ingress routers' perspectives rather than the RR's own location.


It is important to include the "Centralized RR model" in the document because the Centralized RR Model exists in some deployments where RRs are used as a component for centralized policy control, or  SDN architectures. Rather than avoiding the topic, it is better to describe the associated issues and reference relevant RFCs, such as RFC 9107 for ORR, to ensure proper guidance.

Please let us know.

Linda

From: Gyan Mishra <[e-mail]>
Sent: Monday, February 24, 2025 9:11 PM
To: Linda Dunbar <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>; Sue Hares <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Idr] revision idr-5g-edge-service-metadata to address Route selection issues #40 on the GitHub

Hi Linda

I would like to comment on section 6 centralized model.

I would recommend adding a few words stating that historically the centralized model may result in hot potato routing due to RR calculating best path based on it's location and not egress PE location. ORR Optimized RR should be mentioned as a workaround.  This is orthogonal to metadata path attribute since hot potato routing is with IGP metric path attribute.  However since centralized model is still used in certain use cases and is mentioned in the draft I think it's important to mention this hot potato routing issue and ORR workaround.

Kind Regards

Gyan



On Wed, Dec 4, 2024 at 2:10 AM Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
Jeff,

We added a new section (6. Policy Based Metadata Integration) to describes how the information carried in the Metadata Path Attribute is integrated into the BGP route selection process to address the Route selection issues #40 on the GitHub.

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

Can you please check if the new section description is enough?

If yes, can you close the issues #40 on the GitHub?

Thank you very much,

Linda

From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, November 3, 2024 11:36 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Sue Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: revision and slides for idr-5g-edge-service-metadata

Linda,

Thanks for the slides.

The details on route selection are still too vague from a BGP process standpoint.  As you know, bgp has a extensive tie breaking mechanism covered in RFC 4271 as the basis and further refined in other documents.  What's being explicitly requested is "our procedures GO HERE in that list".

We can certainly reserve some of this for mic discussion.

That also said, Sue has a need to push her FSv2 presentation to Friday.  Would you consider moving your presentation to Monday morning?  I realize this is short notice.

If you will consider this, please forward your final slides to [e-mail]<mailto:[e-mail]> and note to Jie that you'll be taking a Monday slot per our discussion.

If you are uncomfortable to move for some reason, we understand and will keep you in your current slot.

-- Jeff


On Nov 2, 2024, at 3:50 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

Jeff,

Attached are the slides.

Linda

From: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, November 2, 2024 7:34 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Sue Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: revision and slides for idr-5g-edge-service-metadata

Linda,


On Oct 31, 2024, at 7:48 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

Jeff,

Thank you very much for the detailed suggestions. I revised the draft (especially rewrite the BGP Route Selection and removed Custom Decision reference), responded on GitHub to your comments, and put together the slides.

Thanks. I haven't seen the slides yet.



Can we have a chat next week in Dublin before the Friday IDR session to see if the revision and slides for idr-5g-edge-service-metadata have addressed your concern?

Unfortunately I won't be in Dublin this round.  Due to the direction of the time zone skew, I'd suggest iterating in email.

-- Jeff

<draft-ietf-idr-5g-edge-service-metadata-IETF121.pptx>

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>