Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

[Vishnu Pavan Beeram]

Dhruv, Hi!

Thanks for the response! Please see inline..

Regards,
-Pavan

On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody  wrote:

> Hi Pavan,
>
> On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram <
> vishnupa...@gmail.com> wrote:
>
>> I would like to get some clarification on the text below (understand that
>> a publication request has been made for the draft).
>>
>> **
>> From Section 5:
>>
>>When L-flag is not set and E-flag is not set then PCE SHOULD consider
>>the protection eligibility as UNPROTECTED PREFERRED but MAY consider
>>protection eligibility as UNPROTECTED MANDATORY constraint.
>>
>>When L-flag is not set and E-flag is set then PCE MUST consider the
>>protection eligibility as UNPROTECTED MANDATORY constraint.
>>
>>
>>
>> **
>> For the scenario where both the L-flag and the E-flag are not set (first
>> statement above), it seems okay to just say
>> that the "PCE MUST consider the protection eligibility as UNPROTECTED
>> PREFERRED". Is there a good reason
>> for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED
>> MANDATORY)" clauses to
>> be included here (and keep things ambiguous)?
>>
>>
> Dhruv: If I recall correctly (and the authors can confirm that), this was
> done for the sake of backward compatibility. I remember it being discussed
> on the mailing list as well.
>
> [VPB] Thanks for the pointer to the mailing list thread (should have
searched there first; apologies for re-opening the topic) -- it was useful!
However, the backwards compatibility section (5.1) seems to be silent about
this particular scenario.

If a PCEP speaker does not understand this document (and thus ignores the E
> flag) and L flag is set to 0, would behave as per RFC 5440 where the
> concept of enforcement is undefined and some implementation could
> understand it to be handled as UNPROTECTED MANDATORY instead of UNPROTECTED
> PREFERRED. And the text allows for it.
>

[VPB] I understand that there was ambiguity with how the (presence/absence
of the) L-flag was interpreted prior to this draft. I was hoping that there
would be no ambiguity left when this draft is implemented -- but that
doesn't seem to be the case. Let's say a PCC implementation assumes [L 0, E
0] to mean "UNPROTECTED PREFERRED" (SHOULD clause), while the PCE
implementation assumes it to mean "UNPROTECTED MANDATORY" (MAY clause) --
this may result in no path being returned (if only protected SIDs are
available on some links along the viable paths). Do we need to retain this
ambiguity?


>
> Happy to get additional eyes and confirm if it still makes sense!
>
> Thanks!
> Dhruv
>
>
>
>> Regards,
>> -Pavan
>> ___
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

[Dhruv Dhody]

Hi Pavan,

On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram 
wrote:

> I would like to get some clarification on the text below (understand that
> a publication request has been made for the draft).
>
> **
> From Section 5:
>
>When L-flag is not set and E-flag is not set then PCE SHOULD consider
>the protection eligibility as UNPROTECTED PREFERRED but MAY consider
>protection eligibility as UNPROTECTED MANDATORY constraint.
>
>When L-flag is not set and E-flag is set then PCE MUST consider the
>protection eligibility as UNPROTECTED MANDATORY constraint.
>
>
>
> **
> For the scenario where both the L-flag and the E-flag are not set (first
> statement above), it seems okay to just say
> that the "PCE MUST consider the protection eligibility as UNPROTECTED
> PREFERRED". Is there a good reason
> for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED
> MANDATORY)" clauses to
> be included here (and keep things ambiguous)?
>
>
Dhruv: If I recall correctly (and the authors can confirm that), this was
done for the sake of backward compatibility. I remember it being discussed
on the mailing list as well.

If a PCEP speaker does not understand this document (and thus ignores the E
flag) and L flag is set to 0, would behave as per RFC 5440 where the
concept of enforcement is undefined and some implementation could
understand it to be handled as UNPROTECTED MANDATORY instead of UNPROTECTED
PREFERRED. And the text allows for it.

Happy to get additional eyes and confirm if it still makes sense!

Thanks!
Dhruv



> Regards,
> -Pavan
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Question on draft-ietf-pce-local-protection-enforcement

[Vishnu Pavan Beeram]

I would like to get some clarification on the text below (understand that a
publication request has been made for the draft).

**
>From Section 5:

   When L-flag is not set and E-flag is not set then PCE SHOULD consider
   the protection eligibility as UNPROTECTED PREFERRED but MAY consider
   protection eligibility as UNPROTECTED MANDATORY constraint.

   When L-flag is not set and E-flag is set then PCE MUST consider the
   protection eligibility as UNPROTECTED MANDATORY constraint.



**
For the scenario where both the L-flag and the E-flag are not set (first
statement above), it seems okay to just say
that the "PCE MUST consider the protection eligibility as UNPROTECTED
PREFERRED". Is there a good reason
for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED
MANDATORY)" clauses to
be included here (and keep things ambiguous)?

Regards,
-Pavan
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE SID-algo draft extension

[slitkows.ietf]

Hi

 

Happy new year guys !

 

IMO, from a use case point of view, the SID filtering use case is far more 
limited and niche (e.g.: plane selection…) vs the interdomain FA path 
computation which is widely required. For large networks that are multidomain, 
there must be a PCE based solution for interdomain FA path computation.

 

Brgds,

 

Stephane

 

From: Pce  On Behalf Of Dhruv Dhody
Sent: mardi 10 janvier 2023 14:00
To: Samuel Sidor (ssidor) 
Cc: pce@ietf.org; pce-chairs 
Subject: Re: [Pce] PCE SID-algo draft extension

 

Hi Samuel,

As a WG participant --- Assuming the WG agrees with the usecase, we need a 
clear way to signal when the Algo is a constraint along with others (current) 
v/s when Algo is a shorthand to refer to the constraints as per the IGP 
definition (proposed). 

This could be a flag in the SID Algorithm TLV or could be a brand new mechanism 
(such as a new dynamic association type for FlexAlgo). More importantly, we 
need to be clear on how other PCEP constraints interact with the constraints 
referred in the IGP. The easiest thing would be to not allow other PCEP 
constraints to be encoded at all and rely only on IGP; or have flags to signal 
how to handle the complexity of combining them including mismatch! This needs 
to be handled with care! 

Thanks! 
Dhruv

 

On Tue, Jan 10, 2023 at 3:51 PM Samuel Sidor (ssidor) mailto:ssi...@cisco.com> > wrote:

Hi all,

 

I would like to get feedback from PCE WG for one extension proposed for 
existing SID-algo draft 

  (currently expired), which is trying to cover all existing algorithm types as 
defined in IGP – that includes SPF (algo 0), Strict-SPF (algo 1) and Flex-algo 
(algo 128-255)

It introduced SID-algo constraint, which currently can be used for filtering 
SIDs used in path computed by PCE. 

To be able to compute inter-domain Flex-algo path, PCE Flex-algo 
path-computation must be aligned with path-computation done by IGP (Use ASLA 
attributes, honor FAD lookup priorities,…). This use-case is different one from 
SID filtering we need to use constraints/metric-type from Flex-algo definition 
that is bound to SID algo number specified in constraint. 

 

Before we modify the draft, we would like to know if WG has any objection.

 

Thanks,

Samuel

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE SID-algo draft extension

[Dhruv Dhody]

Hi Samuel,

As a WG participant --- Assuming the WG agrees with the usecase, we need a
clear way to signal when the Algo is a constraint along with others
(current) v/s when Algo is a shorthand to refer to the constraints as per
the IGP definition (proposed).

This could be a flag in the SID Algorithm TLV or could be a brand new
mechanism (such as a new dynamic association type for FlexAlgo). More
importantly, we need to be clear on how other PCEP constraints interact
with the constraints referred in the IGP. The easiest thing would be to not
allow other PCEP constraints to be encoded at all and rely only on IGP; or
have flags to signal how to handle the complexity of combining them
including mismatch! This needs to be handled with care!

Thanks!
Dhruv

On Tue, Jan 10, 2023 at 3:51 PM Samuel Sidor (ssidor) 
wrote:

> Hi all,
>
>
>
> I would like to get feedback from PCE WG for one extension proposed for
> existing SID-algo draft
> 
> (currently expired), which is trying to cover all existing algorithm types
> as defined in IGP – that includes SPF (algo 0), Strict-SPF (algo 1) and
> Flex-algo (algo 128-255)
>
> It introduced SID-algo constraint, which currently can be used for
> filtering SIDs used in path computed by PCE.
>
> To be able to compute inter-domain Flex-algo path, PCE Flex-algo
> path-computation must be aligned with path-computation done by IGP (Use
> ASLA attributes, honor FAD lookup priorities,…). This use-case is different
> one from SID filtering we need to use constraints/metric-type from
> Flex-algo definition that is bound to SID algo number specified in
> constraint.
>
>
>
> Before we modify the draft, we would like to know if WG has any objection.
>
>
>
> Thanks,
>
> Samuel
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi all,

I would like to get feedback from PCE WG for one extension proposed for 
existing SID-algo 
draft
 (currently expired), which is trying to cover all existing algorithm types as 
defined in IGP - that includes SPF (algo 0), Strict-SPF (algo 1) and Flex-algo 
(algo 128-255)
It introduced SID-algo constraint, which currently can be used for filtering 
SIDs used in path computed by PCE.
To be able to compute inter-domain Flex-algo path, PCE Flex-algo 
path-computation must be aligned with path-computation done by IGP (Use ASLA 
attributes, honor FAD lookup priorities,...). This use-case is different one 
from SID filtering we need to use constraints/metric-type from Flex-algo 
definition that is bound to SID algo number specified in constraint.

Before we modify the draft, we would like to know if WG has any objection.

Thanks,
Samuel
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce