Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Gyan Mishra]

I support WG adoption of this important PCEP  FlexAlgo extension and I am
willing to work on the draft to progress.

Thanks

Gyan

On Fri, Feb 4, 2022 at 12:15 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.
>
> https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/
>
> Should this draft be adopted by the PCE WG? Please state your reasons -
> Why / Why not? What needs to be fixed before or after adoption? Are you
> willing to work on this draft? Review comments should be posted to the list.
>
> Please respond by Monday 21st Feb 2022.
>
> Have a great weekend.
>
> Thanks!
> Dhruv & Julien
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Dongjie (Jimmy)]

Hi Samuel,

Sorry for the late reply.  It is good to see this document adopted, and please 
see some further replies inline with [Jie #2]:


From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Tuesday, February 22, 2022 5:49 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Samuel,

Thanks for your reply. Please see further inline:

From: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
Sent: Friday, February 18, 2022 7:27 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: 
draft-tokar-pce-sid-a...@ietf.org; 
Dhruv Dhody mailto:d...@dhruvdhody.com>>; 
pce@ietf.org; Mahendra Negi 
mailto:mahen...@rtbrick.com>>
Subject: RE: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi Jie,

Combining responses for 1. and 2. as those are related:

Encoding of SID/ERO-subobject level was used, because of multiple reasons:

a)  We may need to signal SL, which is explicitly configured by user (not 
just computed by PCE) and in such case user can potentially mix SIDs with 
different algorithms (if user is accepting risk of loops or if user knows that 
it cannot happen for various reasons in that specific case).

[Jie] Do you mean using PCEP to signal a configured SID list which consists of 
SIDs with different algorithms? To avoid the risk of loop, normally user would 
prefer to configure either SID list with strict path, or SIDs with consistent 
algorithm. Even if it is known that there is no loop, different algorithms 
represent different requirements to the path, logically can a path built with 
different algorithms meet specific requirement?

Thus it would be helpful to describe the typical scenario(s) of configuring 
SIDs with different algorithms .

 In most of the cases, requirements == algo used, but there are cases, where 
it may not be possible. Some examples.

·case b) bellow (inter-domain)

·support for less capable nodes (e.g. some node/nodes without 
SSPF/Algo1 support, but user want to use SSPF SIDs wherever possible and where 
user knows that it is still safe to mix SIDs). Implementation (PCE/PCC) can 
have local policy (e.g. some configuration) to decide if potentially unsafe 
paths should be used or blocked.

As soon as we have at least possible use case (even if it is corner case), it 
may be bad idea to block it on protocol level. I agree that it may be good to 
describe use cases above in the draft.

[Jie #2] OK, I understand there can be cases of falling back from a specific 
Algorithm to the default algorithm, in such case the PCE may need to be 
responsible for determining whether the path with Mixed SID is safe or not, as 
the PCCs may not have enough information for such check.


b)  Different algorithm ID != different algorithm. With flex-algo different 
ID can be used for identification of same algorithm (e.g. in different IGP 
domains). Mixing SIDs with different algorithm ID in such case is safe, but we 
would not be able to signal such path in PCEP.

[Jie] I agree in the inter-domain case, the same algorithm can be represented 
using different IDs, and SIDs associated with different algorithm IDs can be 
used to build an inter-domain path to meet certain requirement. I’d suggest to 
add some description about this case to the document, and it would be better to 
limit the usage of different algorithm IDs in the ERO to this inter-domain case 
only.

 I’m not sure if we can really have hard requirement for PCC or PCE to check 
it. E.g. in case of configured SID list on PCC - PCC may not have visibility to 
whole topology in case of inter-domain paths, so it may not be able to verify 
it. E.g. consider that user configured SID list like this:

1.  Label 26000 (algo 128)

2.  Label 26005 (algo 129)
PCC can just blindly report such path to PCE even if it does not know if both 
SIDs are in same area/domain or not. If we will strictly say that it is not 
valid, then user configured path can result in breaking protocol level 
limitations. Same applies to PCE, which can be potentially used only as a proxy.

[Jie #2] Agree that the PCC may not have visibility to the whole inter-domain 
topology, and the PCE may need to take the responsibility when 

[Pce] Protocol Action: 'Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.' to Proposed Standard (draft-ietf-pce-binding-label-sid-15.txt)

[The IESG]

The IESG has approved the following document:
- 'Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.'
  (draft-ietf-pce-binding-label-sid-15.txt) as Proposed Standard

This document is the product of the Path Computation Element Working Group.

The IESG contact persons are Alvaro Retana, John Scudder and Martin Vigoureux.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/




Technical Summary:

   In order to provide greater scalability, network confidentiality, and service
   independence, Segment Routing (SR) utilizes a Binding Segment
   Identifier (BSID).  It is possible to associate a BSID to an RSVP-TE-
   signaled Traffic Engineering Label Switch Path or an SR Traffic
   Engineering path.  The BSID can be used by an upstream node for
   steering traffic into the appropriate TE path to enforce SR policies.
   This document specifies the binding value as an MPLS label or Segment
   Identifier.  It further specifies an approach for reporting binding
   label/SID by a Path Computation Client (PCC) to the Path Computation
   Element (PCE) to support PCE-based Traffic Engineering policies.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there 
controversy about particular points or were there decisions where the consensus 
was particularly rough?
- No

Document Quality:

Are there existing implementations of the protocol?
- Yes, 2 implementations are mentioned in the I-D.

Have a significant number of vendors indicated their plan to implement the 
specification?
- There are 4 different vendors among the authors.

Are there any reviewers that merit special mention as having done a thorough 
review, e.g., one that resulted in important changes or a conclusion that the 
document had no substantive issues?
- Adrian Farrel did a careful review of the document and Olivier Dugeon 
suggested to add a flag which resulted in a more robust and consistent 
extension.
 
If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what 
was its course (briefly)? In the case of a Media Type review, on what date was 
the request posted?
- N/a

Personnel:

Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- John Scudder

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