[Pce] 答复: IPR Poll for draft-ietf-pce-vn-association-05

2022-02-22 Thread Zhenghaomian
Hi All,

I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

Best wishes,
Haomian

发件人: Dhruv Dhody [mailto:d...@dhruvdhody.com]
发送时间: 2022年2月22日 20:24
收件人: Young Lee ; Zhenghaomian ; 
Daniele Ceccarelli 
抄送: pce@ietf.org; pce-chairs 
主题: IPR Poll for draft-ietf-pce-vn-association-05

Hi Authors,

In preparation for WG LC on this draft, I'd like all authors to confirm on the 
list that they are in compliance with IETF IPR rules for 
https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been disclosed 
to the IETF. I will work to ensure that it will be disclosed in a timely manner.

Thanks,
Dhruv

PS. Note that one IPR has been disclosed - 
https://datatracker.ietf.org/ipr/3329/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] IPR Poll for draft-ietf-pce-vn-association-05

2022-02-22 Thread Daniele Ceccarelli
Hi Dhruv, all,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

BR
Daniele

From: Dhruv Dhody 
Sent: den 22 februari 2022 13:24
To: Young Lee ; zhenghaom...@huawei.com; Daniele 
Ceccarelli 
Cc: pce@ietf.org; pce-chairs 
Subject: IPR Poll for draft-ietf-pce-vn-association-05

Hi Authors,

In preparation for WG LC on this draft, I'd like all authors to confirm on the 
list that they are in compliance with IETF IPR rules for 
https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been disclosed 
to the IETF. I will work to ensure that it will be disclosed in a timely manner.

Thanks,
Dhruv

PS. Note that one IPR has been disclosed - 
https://datatracker.ietf.org/ipr/3329/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] IPR Poll for draft-ietf-pce-vn-association-05

2022-02-22 Thread Young Lee
Hi,

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

Thanks.
Young

2022년 2월 22일 (화) 오후 9:24, Dhruv Dhody 님이 작성:

> Hi Authors,
>
> In preparation for WG LC on this draft, I'd like all authors to confirm on
> the list that they are in compliance with IETF IPR rules for
> https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/
>
> Please respond (copying the mailing list) to say one of:
>
> I am not aware of any IPR applicable to this draft that should be
> disclosed in accordance with IETF IPR rules.
>
> I am aware of the IPR applicable to this draft, and it has already been
> disclosed to the IETF.
>
> I am aware of IPR applicable to this draft, but that has not yet been
> disclosed to the IETF. I will work to ensure that it will be disclosed in a
> timely manner.
>
> Thanks,
> Dhruv
>
> PS. Note that one IPR has been disclosed -
> https://datatracker.ietf.org/ipr/3329/
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

2022-02-22 Thread Dhruv Dhody
Looks like the chairs had a "collision" in sending out the WGLC notice!
Apologies! :)

The only parameter that was different was when the WGLC ends, and let's
pick the larger of the two dates i.e.  WGLC will end on March 16, 2022.

Thanks!
Dhruv


On Tue, Feb 22, 2022 at 5:48 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email starts a 3-weeks working group last call for
> draft-ietf-pce-vn-association-05 [1
> ] to
> accommodate the upcoming draft submission deadline.
>
> Please indicate your support or concern for this draft. If you are opposed
> to the progression of the draft to RFC, please articulate your concern. If
> you support it, please indicate that you have read the latest version and
> it is ready for publication in your opinion. As always, review comments and
> nits are most welcome.
>
> The WG LC will end on Tuesday 15th March 2022.
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption and help us unclog our queues :)
>
> Thanks,
> Dhruv & Julien
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] IPR Poll for draft-ietf-pce-vn-association-05

2022-02-22 Thread Dhruv Dhody
Hi Authors,

In preparation for WG LC on this draft, I'd like all authors to confirm on
the list that they are in compliance with IETF IPR rules for
https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
Dhruv

PS. Note that one IPR has been disclosed -
https://datatracker.ietf.org/ipr/3329/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] WGLC for draft-ietf-pce-vn-association-05

2022-02-22 Thread Dhruv Dhody
Hi WG,

This email starts a 3-weeks working group last call for
draft-ietf-pce-vn-association-05 [1
] to
accommodate the upcoming draft submission deadline.

Please indicate your support or concern for this draft. If you are opposed
to the progression of the draft to RFC, please articulate your concern. If
you support it, please indicate that you have read the latest version and
it is ready for publication in your opinion. As always, review comments and
nits are most welcome.

The WG LC will end on Tuesday 15th March 2022.

A general reminder to the WG to be more vocal during the last-call/adoption
and help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] WGLC for draft-ietf-pce-vn-association

2022-02-22 Thread julien.meuric

Hi all,

This message starts a 3-week WG Last Call for 
draft-ietf-pce-vn-association-05. The I-D is not long: please review and 
share your feedback using the PCE mailing list.


This LC will end on March 16, 2022.

Regards,

Dhruv & Julien




smime.p7s
Description: S/MIME Cryptographic Signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


Re: [Pce] Clarification regarding SR-ERO Validation Error

2022-02-22 Thread Mrinmoy Das
Thanks Dhruv for the clarification.

On Tue, Feb 22, 2022 at 5:17 PM Dhruv Dhody  wrote:

> Hi Mrinmoy,
>
> On Tue, Feb 22, 2022 at 4:52 PM Mrinmoy Das 
> wrote:
>
>> Hello Team,
>>
>> I found below SR-ERO validation in RFC 8664, 5.2.1
>> . SR-ERO
>> Validation
>>
>>The SR-ERO subobjects can be classified according to whether they
>>contain a SID representing an MPLS label value or an index value, or
>>no SID.  If a PCC detects that the SR-ERO subobjects are a mixture of
>>more than one of these types, then it MUST send a PCErr message with
>>Error-Type = 10 ("Reception of an invalid object") and Error-value =
>>20 ("Inconsistent SIDs in SR-ERO/SR-RRO subobjects").
>>
>>
>> As per my understanding of the above text, there could be three types of
>> SIDs:
>>
>> 1. *SID index: *S-bit = 0, M = 0,C = 0
>> 2. *SID as MPLS label:* S-bit = 0, M = 1, C = 0/1
>> 3. *Null:* S-bit = 1
>>
>> Now, if a LSP contains 3 SR-ERO subobjects then all those three should
>> have the same SID type, e.g. all may be type 1, or type 2 or type 3 and
>> there shouldn't be any combination of these 3 types.
>>
>> Is this understanding correct? Please let me know.
>>
>>
> Yes! Your understanding is correct.
>
> Thanks!
> Dhruv
>
>
>
>> Thanks,
>> Mrinmoy
>> ___
>> 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] Clarification regarding SR-ERO Validation Error

2022-02-22 Thread Dhruv Dhody
Hi Mrinmoy,

On Tue, Feb 22, 2022 at 4:52 PM Mrinmoy Das  wrote:

> Hello Team,
>
> I found below SR-ERO validation in RFC 8664, 5.2.1
> . SR-ERO
> Validation
>
>The SR-ERO subobjects can be classified according to whether they
>contain a SID representing an MPLS label value or an index value, or
>no SID.  If a PCC detects that the SR-ERO subobjects are a mixture of
>more than one of these types, then it MUST send a PCErr message with
>Error-Type = 10 ("Reception of an invalid object") and Error-value =
>20 ("Inconsistent SIDs in SR-ERO/SR-RRO subobjects").
>
>
> As per my understanding of the above text, there could be three types of
> SIDs:
>
> 1. *SID index: *S-bit = 0, M = 0,C = 0
> 2. *SID as MPLS label:* S-bit = 0, M = 1, C = 0/1
> 3. *Null:* S-bit = 1
>
> Now, if a LSP contains 3 SR-ERO subobjects then all those three should
> have the same SID type, e.g. all may be type 1, or type 2 or type 3 and
> there shouldn't be any combination of these 3 types.
>
> Is this understanding correct? Please let me know.
>
>
Yes! Your understanding is correct.

Thanks!
Dhruv



> Thanks,
> Mrinmoy
> ___
> 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] Clarification regarding SR-ERO Validation Error

2022-02-22 Thread Mrinmoy Das
Hello Team,

I found below SR-ERO validation in RFC 8664, 5.2.1
. SR-ERO
Validation

   The SR-ERO subobjects can be classified according to whether they
   contain a SID representing an MPLS label value or an index value, or
   no SID.  If a PCC detects that the SR-ERO subobjects are a mixture of
   more than one of these types, then it MUST send a PCErr message with
   Error-Type = 10 ("Reception of an invalid object") and Error-value =
   20 ("Inconsistent SIDs in SR-ERO/SR-RRO subobjects").


As per my understanding of the above text, there could be three types of
SIDs:

1. *SID index: *S-bit = 0, M = 0,C = 0
2. *SID as MPLS label:* S-bit = 0, M = 1, C = 0/1
3. *Null:* S-bit = 1

Now, if a LSP contains 3 SR-ERO subobjects then all those three should have
the same SID type, e.g. all may be type 1, or type 2 or type 3 and there
shouldn't be any combination of these 3 types.

Is this understanding correct? Please let me know.

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


[Pce] I-D Action: draft-ietf-pce-sid-algo-00.txt

2022-02-22 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : Carrying SID Algorithm information in PCE-based 
Networks.
Authors : Alex Tokar
  Samuel Sidor
  Shaofu Peng
  Siva Sivabalan
  Tarek Saad
  Shuping Peng
  Mahendra Singh Negi
Filename: draft-ietf-pce-sid-algo-00.txt
Pages   : 12
Date: 2022-02-22

Abstract:
   The Algorithm associated with a prefix Segment-ID (SID) defines the
   path computation Algorithm used by Interior Gateway Protocols (IGPs).
   This information is available to controllers such as the Path
   Computation Element (PCE) via topology learning.  This document
   proposes an approach for informing headend routers regarding the
   Algorithm associated with each prefix SID used in PCE-computed paths,
   as well as signalling a specific SID algorithm as a constraint to the
   PCE.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo-00


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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


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

2022-02-22 Thread Samuel Sidor (ssidor)
Hi Jie,

Thanks for your comments. Please see inline :

Regards,
Samuel

From: Dongjie (Jimmy) 
Sent: Monday, February 21, 2022 4:45 PM
To: Samuel Sidor (ssidor) 
Cc: draft-tokar-pce-sid-a...@ietf.org; Dhruv Dhody ; 
pce@ietf.org; Mahendra Negi 
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.


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.


c)  Also related to explicit SL – in some cases, user may configure SL 
explicitly on headend. Headend may not be able to resolve complete SL, so it 
may not be sure if algorithm of all SIDs is same.

[Jie] Understood.

3. We defined new types in older version of this draft – see:
https://datatracker.ietf.org/doc/html/draft-tokar-pce-sid-algo-03#section-6.1
but there were multiple comments indicating that it is resulting in too many 
new types (we need to extend draft for Adjacency SIDs as well) and it would be 
hard to maintain it for future – e.g. for cases where new NAI types are added. 
With this change we would have to double number of NAI types. Any extension 
like this in the future would double it again.

[Jie] Thanks for the pointer, I understand the cost of introducing new NAI 
types. While comparing to the format of SID types in BGP SR Policy, there is a 
fixed algorithm field and a A Flag is used to indicate whether this field 
carries an algorithm value or not. Perhaps another approach is to update the 
format of the existing NAI types to include the algorithm field. This could 
also better align the NAI types in PCEP with the 

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

2022-02-22 Thread Dhruv Dhody
Hi WG,

The adoption poll is closed. The I-D is adopted as a PCE WG item.

Authors,

Please submit the existing I-D as draft-ietf-pce-sid-algo-00. You have also
received various comments and suggestions for improvements. Please handle
them in the -01 version. Do think about adding text describing your
motivations behind the various design choices to help the reader understand
them.

Thank you,
Dhruv & Julien

On Fri, Feb 4, 2022 at 10:44 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


Re: [Pce] IPR Poll for draft-tokar-pce-sid-algo

2022-02-22 Thread Pengshuping (Peng Shuping)
Hi,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Best Regards,
Shuping

From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Saturday, February 5, 2022 1:58 AM
To: ssi...@cisco.com; peng.sha...@zte.com.cn; ato...@cisco.com; 
msiva...@gmail.com; Pengshuping (Peng Shuping) ; 
ts...@juniper.net; Mahend Negi 
Cc: pce@ietf.org
Subject: IPR Poll for draft-tokar-pce-sid-algo


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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


Re: [Pce] IPR Poll for draft-tokar-pce-sid-algo

2022-02-22 Thread Alex Tokar (atokar)
I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Thanks,
Alex

From: Mahendra Negi 
Sent: Friday, February 18, 2022 05:49
To: Siva Sivabalan 
Cc: Hariharan Ananthakrishnan ; Samuel Sidor (ssidor) 
; peng.sha...@zte.com.cn ; Alex Tokar 
(atokar) ; Pengshuping (Peng Shuping) 
; Tarek Saad ; pce@ietf.org 

Subject: Re: IPR Poll for draft-tokar-pce-sid-algo


Hi all,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.


Regards,

Mahendra


On Sun, Feb 13, 2022 at 6:57 AM Siva Sivabalan 
mailto:msiva...@gmail.com>> wrote:

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF rules.

Regards,
Siva

On Fri, Feb 4, 2022 at 12:58 PM Hariharan Ananthakrishnan 
mailto:h...@netflix.com>> wrote:

Hi Authors,

In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

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