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

[Gyan Mishra <[e-mail]>]

Hi Linda

Your revised txt looks good


Thank you

Gyan



On Tue, Feb 25, 2025 at 12:17 PM Linda Dunbar <[e-mail]>
wrote:

> 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]>
> 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]>
> *Sent:* Sunday, November 3, 2024 11:36 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Sue Hares <[e-mail]>;
> [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] 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]>
> wrote:
>
>
>
> Jeff,
>
>
>
> Attached are the slides.
>
>
>
> Linda
>
>
>
> *From:* Jeffrey Haas <[e-mail]>
> *Sent:* Saturday, November 2, 2024 7:34 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* Sue Hares <[e-mail]>;
> [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]>
> 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]
> To unsubscribe send an email to [e-mail]
>
>