Subject: Re: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

From: Dhruv Dhody <[email-masked]>
Date: Wed, 4 Nov 2020 13:34:34 +0530

Hi WG,

Just a reminder, the WG Adoption poll ends on Monday 9th Nov, please
respond to the call with your support (or not), comments, etc.
Please be more vocal on the list [1].

Thanks!
Dhruv & Julien

[1]
https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduction-01
> Please be Vocal
>
> o During WG Adoption and WG LC calls, the response is less.
>
> o Please be vocal on the list to help us gauge the consensus better.
>
> o The working group mailing lists are looked at by the IESG, IAB, and
others (internal and external to IETF) to determine interest/participation
level in our standards process.
>
> o Please review ideas from your peers, these are community outputs of the
working group as a whole.

On Wed, Oct 21, 2020 at 7:10 PM Dhruv Dhody <[email-masked]> wrote:

> Hi WG,
>
> This email begins the WG adoption poll for
> draft-stone-pce-local-protection-enforcement-02.
>
>
> https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02
>
> 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.
>
> This adoption poll will end on 9th Nov 2020 (Monday).
>
> Thanks!
> Dhruv & Julien
>

---

From: Tarek Saad <[email-masked]>
Date: Wed, 4 Nov 2020 18:14:28 +0000

I believe the issue the draft is tackling is useful and I support adoption. I also believe the idea of "enforcing" a constraint can be generalized (e.g. to other constraints). Ideally, we can consider an approach that can be extended to other constraints in future too.

Regards,
Tarek

On 10/21/20, 5:14 PM, "Pce on behalf of Stone, Andrew (Nokia - CA/Ottawa)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello, 

    As co-author, I support the adoption. Document describes various use case needs, has implementations, and has been updated based on existing feedback. Would be good to have adopted to move to early IANA codepoint allocations to allow implementation to progress further, as well as further WG refinement. 

    Thank you
    Andrew

    On 2020-10-21, 9:41 AM, "Pce on behalf of Dhruv Dhody" <[email-masked] on behalf of [email-masked]> wrote:

        Hi WG,

        Thanks!
        Dhruv & Julien

        _______________________________________________
        Pce mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/pce

    _______________________________________________
    Pce mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 4 Nov 2020 23:50:57 +0530

Hi Tarek,

There is a proposal [1] to extend the support for the P
(Processing-Rule) and I (Ignore) flag in the common object header (of
PCEP objects, originally from RFC 5440) to stateful PCEP messages. Do
check it out and let the WG know if that covers what you have in mind.

Thanks!
Dhruv

[1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-optional/

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 5 Nov 2020 11:09:43 +0000

Hi All,

I support the adoption of this draft. 

There have been recent discussions in the Spring WG on the desire to indicate the nature of protection for SRTE paths and this draft proposes a useful mechanism for signalling of the same.

Thanks,
Ketan

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 21 October 2020 19:11
To: [email-masked]
Subject: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

Hi WG,

This email begins the WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

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.

Thanks!
Dhruv & Julien

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 8 Nov 2020 06:35:50 -0600

Support adoption! The draft addresses a hole in the existing protection
toolkit.

It would however be useful to have a generic way of requesting or mandating
each LSP/path attribute (similar to RSVP LSP/HOP attributes). I haven't
read draft-dhody-pce-stateful-pce-optional, but I'm assuming that it
doesn't cover local protection enforcement.

Regards,
-Pavan

---

From: Dhruv Dhody <[email-masked]>
Date: Sun, 8 Nov 2020 19:33:05 +0530

Hi Pavan,

Thanks for participating in the adoption call. Some clarification questions...

Could you point the WG to the right reference in RSVP-TE? Is it RFC 5420?

The Stateful-PCE-optional draft is a generic mechanism to mark whole
PCEP objects as mandatory and optional to process. You are right that
it doesn't cover local protection enforcement at the granularity of
the per-attribute in the LSPA object. Please confirm if my
understanding is correct?

Note that there is a single flag defined in the LSPA object so far, so
generalizing would help a future flag when and if it gets added. Could
you suggest what change you would make to turn this procedure generic?

Thanks!
Dhruv

On Sun, Nov 8, 2020 at 6:06 PM Vishnu Pavan Beeram
<[email-masked]> wrote:
>
> Support adoption! The draft addresses a hole in the existing protection toolkit.
>
> It would however be useful to have a generic way of requesting or mandating each LSP/path attribute (similar to RSVP LSP/HOP attributes). I haven't read draft-dhody-pce-stateful-pce-optional, but I'm assuming that it doesn't cover local protection enforcement.
>
> Regards,
> -Pavan
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 8 Nov 2020 23:52:41 -0600

Dhruv, Hi!

Yes, RFC5420 is the correct reference. I was referring to how the
“Attribute Flags TLV” is processed when present in the LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES objects.

A similar approach can be employed for the PCEP LSPA object. This would
need us to (a) Introduce a new flags TLV and (b) Introduce a new
LSPA_REQUIRED/LSPA_ENFORCED object that can carry this TLV when needed.
This can be done now or later when there are more flags defined.

Regards,

-Pavan

On Sun, Nov 8, 2020 at 8:03 AM Dhruv Dhody <[email-masked]> wrote:

> > It would however be useful to have a generic way of requesting or
> mandating each LSP/path attribute (similar to RSVP LSP/HOP attributes). I
> haven't read draft-dhody-pce-stateful-pce-optional, but I'm assuming that
> it doesn't cover local protection enforcement.
> >
> > Regards,
> > -Pavan
> >

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 11 Nov 2020 18:24:58 +0530

Hi WG,

The WG adoption poll is closed, the response was less than what we
would have liked. The responses were all supportive without any
objections. All authors have
responded to the IPR check. We can adopt it as a WG document.

There is a suggestion on the table to make things generic from Pavan,
we request authors to discuss this with Pavan (preferably on the
list).

Hi Authors,

Please post 'draft-ietf-pce-local-protection-enforcement-00' when the
submission is allowed again with no other change.

Thanks!
Dhruv & Julien