Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

Hello Dhruv,

Thanks for your comment.

When we started writing this draft, our main goal was to propose a
mechanism for inter-domain tunnel setup in a coordinated way while
remaining operator independent. We chose to re-use as much as possible
existing PCEP objects and just proposed to request new IANA code points
within existing registries. Of course, this is just a matter of feature
encoding for stateful inter-domain.
You're right: multiplying the number of PSTs to add inter-domain to
each of them isn't a nice way forward. As the I-D is now considered as
a WG item, we are open to study any mechanism that fits WG expectations,
i.e. we fully agree to create a dedicated PCEP object, TLV or new flag
to implement it.

I think the best approach, if the draft is adopted, is to publish it as
a version -00 and then discuss the suitable mechanism as part of the WG
work to produce a version -01 specifying it.
Do you agree with this approach?

Regards

Olivier, on behalf of the authors

Le 08/01/2021 à 10:31, Dhruv Dhody a écrit :
> Hi WG, Authors,
>
> Speaking as a WG participant...
>
> I find the functionality described in this I-D to be very useful. But,
> I have one concern that I would like to be addressed before adoption
> or at least get an agreement on (to be handled post-adoption).
>
> I am not in favor of how the PST is being used in the I-D. The PST is used -
> - between PCEs to indicate inter-domain TE processing
> - between PCE and the head-end (2 PST for RSVP-TE & SR each, but for
> inter-domain i.e also allocate and report stitching label)
>
> We basically need a mechanism to request allocation and reporting of
> stitching labels. I strongly suggest using a flag and/or a new TLV, I
> find the use of PST for this inappropriate.
>
> A weird side-effect of the current proposal is that every time we have
> a new PST defined (PCECC is post-WGLC), we would need another one for
> inter-domain.
>
> Moreover, wouldn't it be better if this I-D is independent of the
> per-domain path setup type? Section 6.3 allows for mixed technologies
> and the protocol procedures between cooperating PCEs can be defined
> such that they are independent of the per-domain path setup type to
> allow for any current or future path setup types. I see no reason to
> differentiate between RSVP-TE and SR (section 6.2 is all about
> forwarding on border nodes, and not about PCEP).
>
> I discussed this with the authors earlier, where we basically pushed
> the can down the road, I hope we can resolve this quickly now :)
>
> Thanks!
> Dhruv
>  (As a WG participant)
>
> On Fri, Dec 18, 2020 at 6:23 PM Dhruv Dhody <dd@dhruvdhody.com> wrote:
>> Hi WG,
>>
>> This email begins the WG adoption poll for
>> draft-dugeon-pce-stateful-interdomain-04.
>>
>> https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-interdomain-04
>>
>> 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.
>>
>> To accommodate for the holiday season, this adoption poll will end on
>> 11th Jan 2021 (Monday).
>>
>> Thanks!
>> Dhruv
>>
>> _______________________________________________
>> 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
>
-- 
Orange logo <http://www.orange.com>

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.