Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

["Andrew Stone (Nokia)" <[e-mail]>]

Hi all / PCE WG

Some thoughts …

In general I think it should be up to local PCE policy/implementation to determine if the 'best' path is one which prefers intra or inter domain paths. This goes for Flex Algo related or non-Flex Algo computations. It would be up to and dependent on PCE implementation for strictly respecting area/domain boundaries vs just a flat graph finding by shortest metric or a hybrid in-between (assuming not H-PCE..). Other questions start to pop up such as permitting path out of a domain and back into it etc.   Of course, when computing and using Flex Algo SIDs, PCE needs to do so with respect to the winning FAD in the IGP.

Objective from FAD + Metric Domain Count as a bound of 1 + draft-ietf-pce-stateful-pce-optional would seem a reasonable way to signal prefer intra-domain.

Do we need to introduce text explicitly in the ietf-pce-sid-algo document for this topic? Currently don’t believe so.  Agreed, mechanics of interdomain discussion is going to create more complexity in ietf-pce-sid-algo. Even though I suspect an interdomain section is inevitably needed in ietf-pce-sid-algo (I currently have no specifics points in mind), I think the topic of intra vs inter preference is applicable outside of just the flex algo scope therefore likely not an ideal document to discuss it in.

Thanks
Andrew


From: Pce <[e-mail]> on behalf of Dhruv Dhody <[e-mail]>
Date: Tuesday, September 19, 2023 at 6:58 AM
To: "Samuel Sidor (ssidor)" <ssidor=[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Samuel,

I stand corrected, how did i forget the long debate on metric-type and FAD :)
What I wanted to convey was if you need to signal this, do look for mechanisms that already exist!

Thanks!
Dhruv

On Tue, Sep 19, 2023 at 12:59 PM Samuel Sidor (ssidor) <ssidor=[e-mail]<mailto:[e-mail]>> wrote:
Hi Dhruv,

In case of path-computation done by PCE based on content of FAD (probably vast majority of cases), optimization metric will be specified in FAD, so it will not be possible to optimize based on other metric type on top of that.

For original question:

I agree with PSF – it would be probably too complex to try to define such behavior in the draft. On top of that, such requirement can potentially come for non-Flex-algo paths as well.

I can still imagine achieving something like that for example with 2 candidate-paths:

  *   1st CP (preferred) which will be limited to intra-domain paths using some constraints
  *   2nd CP which will not have any restrictions and which can be used in case of no intra-domain path

That can be achieved with metric bound of metric pointed out by Dhruv, affinity,… set for 1st CP. Theoretically same thing can be achieved by setting MSD bound in 1st CP as with Flex-algo path-computation will probably result in just one SID anyway (Flex-algo SID of destination) – at least if other constraints are not applied on top of that.

Regards,
Samuel

From: Pce <[e-mail]<mailto:[e-mail]>> On Behalf Of Dhruv Dhody
Sent: Tuesday, September 19, 2023 5:48 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

Hi Marcel, PSF,

Speaking as a WG participant...

Note that we do have a metric type "T=20: Domain Count metric (number of domains crossed)."; we can simply use this metric type, asking the PCE to optimize based on this which should lead to preferring intra-domain paths. See https://www.rfc-editor.org/rfc/rfc8685.html#section-3.5

Thanks!
Dhruv

On Tue, Sep 19, 2023 at 9:04 AM <[e-mail]<mailto:[e-mail]>> wrote:



Hi Marcel,



May it be a local policy of PCE ?

For a given <ingress PE, egress PE> that belongs to the same domain, it may be

the default policy for PCE to calculate a candidate path intra domain.

Otherwise, it may bring unnecessary complexity. For example, for a real inter-domain

path requirement of <ingress PE, egress PE> that belongs to the different domain,

the intention is to split the path calculation requirements into multiple domains, e.g,

<ingress PE, ABR1> for domain 1, <ABR1, ABR2> for domain 2, etc. Now, in this case,

does <ingress PE, ABR1> itself again get a inter-domain path ? In theory, yes. But in

reality, it doesn't make sense.



Regards,

PSF


Original
From: MarcelReuter(External) <[e-mail]<mailto:[e-mail]>>
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
Date: 2023年09月15日 16:25
Subject: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain
_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce
Aloha,
Dear colleagues,

I have a question regarding the PCE with SR Flex-algo and multiple IGP domains.

In my understanding in each IGP Domain the Flex-Algo is calculated independently of each other domain.
The PCE should have the view of all IGP domains, including IGP metrics and delay metrics.

So if the PCE calculate a path and ingress and egress PE are in the same IGP domain,
It would be preferable to choose an IGP intra domain vs using another IGP as transit.
Or at least have the possibility to choose or prefer an Intra-Domain path (with a flag maybe?)

Reason:
Especially in mobile operator RAN networks, there could be bandwidth limitations in RAN IGP domains, but still a lower delay path.

What’s your opinion about this?

Thanks
Marcel







________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição


_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pce