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

[Gyan Mishra <[e-mail]>]

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]
>