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

2017-05-03 Thread Dhruv Dhody 

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
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 
 > https://www.ietf.org/mailman/listinfo/pce
 
 >

 ___
 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] WG Last Call of draft-ietf-pce-lsp-setup-type-04

2017-05-03 Thread Julien Meuric 
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
> 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 
> > https://www.ietf.org/mailman/listinfo/pce
> 
> >
>
> ___
> 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] WG Last Call of draft-ietf-pce-lsp-setup-type-04

2017-05-03 Thread Dhruv Dhody 

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 > 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 
> https://www.ietf.org/mailman/listinfo/pce
   
>

   ___
   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] WG Last Call of draft-ietf-pce-lsp-setup-type-04

2017-05-03 Thread Julien Meuric 
[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
> https://www.ietf.org/mailman/listinfo/pce
>

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