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
On Wednesday 03 May 2017 08:47 PM, Julien Meuric wrote:
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 - dhruv.i...@gmail.com:
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
<julien.meu...@orange.com <mailto:julien.meu...@orange.com>> wrote:
[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:
> 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
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org <mailto:Pce@ietf.org>
> https://www.ietf.org/mailman/listinfo/pce
<https://www.ietf.org/mailman/listinfo/pce>
>
_______________________________________________
Pce mailing list
Pce@ietf.org <mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
<https://www.ietf.org/mailman/listinfo/pce>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
