Subject: [Pce] WG Last Call of draft-ietf-pce-lsp-setup-type-04

From: Julien Meuric <[email-masked]>
Date: Tue, 2 May 2017 10:20:07 +0200

Dear all,

The aforementioned I-D has been stable for a while. This message
initiates a 2-week WG Last Call on draft-ietf-pce-lsp-setup-type-04.
Please send your comments to the PCE mailing list by May 15.

Thanks,

Jon, JP & Julien

---

From: Julien Meuric <[email-masked]>
Date: Wed, 3 May 2017 15:47:08 +0200

[Chair hat off]

Authors of draft-ietf-pce-lsp-setup-type,

Reading the I-D, it looks to me that a (small) piece is missing. Let us
assume that I want my PCEP peers to advertise they are both SR-capable
and RSVP-TE-capable over a given session: the SR-PCE-CAPABILITY TLV is
defined in the SR I-D, but where is the RSVP-TE counterpart? I feel we
should add a 4-byte RSVP-TE-CAPABILITY TLV, with length = 0 and
recommended omission in case of RSVP-TE only.

My 50 cents,

Julien

May. 02, 2017 - Julien Meuric:
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 3 May 2017 19:53:13 +0530

Hi Julien,

In my understanding, PCEP sessions are always RSVP-TE capable.
One may not want any LSP to be signaled by RSVP-TE, in which case 
PATH-SETUP-TYPE TLV would be encoded per LSP (in case of SR, this is 
MUST anyways by SR I-D).

Also, isnt this, what we have always done with stateless to stateful PCE 
or P2P to P2MP extensions and so on, should we consider path-setup-type 
to be different?

Just some thoughts, lets see what the authors/WG think...

Regards,
Dhruv

On Wed, May 3, 2017 at 7:17 PM, Julien Meuric <[email-masked] 
<mailto:[email-masked]>> wrote:

    [Chair hat off]

    My 50 cents,

    Julien

    May. 02, 2017 - Julien Meuric:
     > [email-masked] <mailto:[email-masked]>
    <https://www.ietf.org/mailman/listinfo/pce>

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

---

From: Julien Meuric <[email-masked]>
Date: Wed, 3 May 2017 17:17:51 +0200

Hi Dhruv,

Thank you for your feedback, this is valuable.

I fully agree with your first statement: so far, any PCEP peer is
assumed as RSVP-TE-compliant. When no path setup type is explicitly
expressed, this must remain the assumption, I am not questioning the
default.
However, I believe there will be some networks (e.g. SR-enabled) where:
- multiple PCEs may support different capabilities while, in the current
I-D, the only way for a PCC to identify that RSVP-TE is not supported
would be to send a PCReq and get a session-closing "Unsupported path
setup type" error;
- some PCCs are not actually RSVP-TE-capable, thus PCE-initiated TE-LSPs
will also face a session-closing "Unsupported path setup type" error (by
the way, I feel we should not close the session in this case).

I see two ways to address this case with a reasonable effort:
- assume that when path setup types are explicitly expressed (which
remains optional), there is no implicit assumption, thus the RSVP-TE
capability advertisement proposed below;
- stick with this implicit RSVP-TE support by default, which would
require an RSVP-TE-NON-SUPPORT TLV some time.

Assuming we can agree on the requirement, I prefer to add TLVs to
express capabilities rather than disable them. If you believe otherwise,
I wonder if the latter proposal would be an acceptable trade-off.

Cheers,

Julien

May. 03, 2017 - [email-masked]:
> Also, isnt this, what we have always done with stateless to stateful
> PCE or P2P to P2MP extensions and so on, should we consider
> path-setup-type to be different?  
>
> On Wed, May 3, 2017 at 7:17 PM, Julien Meuric
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [Chair hat off]
>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 3 May 2017 22:18:22 +0530

Hi Julien,

This helps me understand your point of view. I agree that there could be 
some PCC that would not support RSVP-TE and would be "SR-only".

In my reading, I assumed that theerror-codes would not hit for RSVP-TE 
in those cases. On re-reading i am not sure that is the case. So it 
could be good to clarify that from authors for -

    Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE
    does not support the intended path setup type it MUST send PCErr with
    Error-Type = TBD (Traffic engineering path setup error) (recommended
    value is 21) and Error-Value = 1 (Unsupported path setup type) and
    close the PCEP session.

I was thinking that the behavior would be similar to "RSVP-TE being not enabled on the PCC", and thus the signaling failed in that case.
The reason being, from the point of view of the protocol, even SR-only peer must understand RSVP-TE semantics i.e. RFC5440 and other stateful extensions.

 From the discussion it is clear we should handle this explicitly in the draft to avoid any confusion, i see two ways -

(1) If the authors intended closing the session for the SR-only peer, then I think your suggestion should be followed.
(2) If the authors intended that all implementation understand (support?) RSVP-TE, they have just not enabled RSVP-TE for SR-only case, then that can also be stated in the draft to avoid confusion.

I hope WG could converge on this quickly.

Thanks!
Dhruv

---

From: Julien Meuric <[email-masked]>
Date: Tue, 16 May 2017 09:51:55 +0200

Hi all,

This LC has ended. Authors, please resolve the open comment on this I-D
so that we can send it to the IESG.

Thanks,

Jon, JP & Julien