Dear PCE WG
This new revision of the LSP setup type draft makes the following changes.
1) Added a capability TLV for the OPEN object and rules for processing it, as
discussed in the attached thread. This is to address Julien's WGLC comment that
there was no way for a PCEP speaker to express that it doesn't support RSVP-TE
as a path setup type.
2) Made the path setup type explicit for anything other than RSVP-TE paths
(where absence of TLV implies RSVP-TE). This is to address Stephane's recent
comment to the list.
3) Updated the IANA / code point text to reflect that we have had an early
allocation.
4) Made some editorial fixes and clarifications.
Best regards
Jon
-----Original Message-----
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 14:59
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.
Title : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
Jeff Tantsura
Ina Minei
Robert Varga
Jon Hardwick
Filename : draft-ietf-pce-lsp-setup-type-06.txt
Pages : 10
Date : 2017-11-20
Abstract:
A Path Computation Element can compute traffic engineering paths (TE
paths) through a network that are subject to various constraints.
Currently, TE paths are label switched paths (LSPs) which are set up
using the RSVP-TE signaling protocol. However, other TE path setup
methods are possible within the PCE architecture. This document
proposes an extension to PCEP to allow support for different path
setup methods over a given PCEP session.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--- Begin Message ---
Mahendra, many thanks for your input.
PCE WG, we have a backwards compatible proposal on the table which, apart from
making a special case of SR-PCE-CAPABILITY, seems reasonably clean (or, at
least, not seriously broken). Shall we go forwards with that?
Best regards
Jon
From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: 25 July 2017 13:12
To: adr...@olddog.co.uk; 'Julien Meuric' <julien.meu...@orange.com>; Jonathan
Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org; Dhruv Dhody
<dhruv.dh...@huawei.com>
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org;
draft-ietf-pce-segment-rout...@ietf.org
Subject: RE: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
Dear All,
This is to answer on implantation row, apologies for the delayed response, YES
we do have our PCEP solutions deployed in mixed SR/RSVP-TE environments.
I am afraid any non-backward compatible changes will break our solution. So
hope we choose a backward compatible solution.
Regards,
Mahendra (Huawei Tech India Pvt Ltd)
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org<mailto:pce@ietf.org>
Cc:
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
draft-ietf-pce-segment-rout...@ietf.org<mailto:draft-ietf-pce-segment-rout...@ietf.org>
Subject: Re: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
Sighing slightly:-)
If, as may be the case, there is a demand to make this work either as currently
specified or to be seamlessly interoperable with what is already specified then
so be it. Let's make that as a conscious decision.
However, I think that using 7120 as an "excuse" is a bad idea. What 7120 is
saying is that the allocated code point must show some stability in meaning
from the point of early allocation on to RFC (just as it would need to if the
RFC was revised). But that is not saying that, upon noticing that we are a herd
of lemmings rushing towards the cliff we must say "We have always rushed
towards the cliff. Our parents rushed towards the cliff. We must continue even
if it means we plunge to our deaths."
Of course, nothing so dramatic, but...
If the current specification works well - stay with it.
If the current specification works but is clumsy - tweak it in a backward
compatible way
If the current specification is broken in a minor way - fix it in a backward
compatible way
If the current specification is more seriously broken - burn a new code point
to fix it
In my earlier emails I was only speculating on "how I would have done this if
starting from scratch." Obviously (?) I should have participated in WG
discussions much earlier in the cycle, and as a result my opinion really only
counts if either:
- the current specification is more seriously broken
or
- there is no WG desire to stick close to the current specification.
Clearly, although people who implement against I-Ds are doing so at their own
risk, we should not unnecessarily burden early implementations with changes
just for the sake of change. There is a sliding scale of "better ways to do
things" that incorporates "it's a bit messy," "it will be easier to maintain
and extend," all the way up to "it's broken." The WG will want to work out
where we are on that scale and weigh it against the cost and inconvenience of
change. Shipping in software may be one measure. Deployed and in use is another
measure.
Cheers,
Adrian
From: Julien Meuric [mailto:julien.meu...@orange.com]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>;
pce@ietf.org<mailto:pce@ietf.org>
Cc:
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
draft-ietf-pce-segment-rout...@ietf.org<mailto:draft-ietf-pce-segment-rout...@ietf.org>
Subject: Re: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
Hi,
I agree that capability bitmap with optional capability-specific sub-TLVs would
be the way to go from scratch. However the SR-PCE-CAPABILITY already has an
early allocated codepoint, and RFC 7120 says that "if there is a change,
implementations based on the earlier and later specifications must be
seamlessly interoperable."
As a result, it seems to me that adding this new format may require that the
I-D keeps documenting an optional SR-PCE-CAPABILITY TLV for legacy reasons.
Cheers,
Julien
Jul. 25, 2017 -
jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>:
I agree that allowing optional sub-TLVs is a good thing. However, this
strongly suggests that SR-PCE-CAPABILITY should become a sub-TLV, which is a
non-backwards compatible change. So, we are back to my original question.
Implementers – any views?
Cheers
Jon
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 24 July 2017 19:51
Yes to that, Jon. But what happens when the next thing comes along?
Since sub-TLVs can be present, I would suggest to use a Setup-Type TLV with
a bit map as I previously described in my email, and add optional sub-TLVs
dependent on the bits that are set.
Isn't that the best of both worlds?
Adrian
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 24 July 2017 09:15
Adrian,
The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also
contains information about the maximum SID depth. However, I like your idea
and I think that it gives us a better way to do this without breaking backwards
compatibility with existing SR implementations.
Suppose we introduce a setup-type TLV into the OPEN object as you propose,
and assign a bit to each setup type.
If the TLV is absent, then RSVP-TE is supported.
If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP-TE
and SR are supported. This retains backwards compatibility with existing SR
implementations.
If the TLV is present, then the bits indicate which setup types are
supported.
We would modify the LSP setup type draft to say that implementations
supporting path setup types other than RSVP-TE SHOULD include the setup-type
TLV.
It’s not exactly beautiful, but it’s not as ugly as RSVP-TE-NON-SUPPORT.
Cheers
Jon
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 21 July 2017 19:55
Well, personally, if I was designing this, I would not a whole TLV for each
bit flag!
I would have a Setup-Type TLV.
If that TLV is absent, RSVP-TE is supported.
If the TLV is present, each bit means that a different setup type is
supported.
That means...
Legacy nodes don't include the TLV and are assumed to support RSVP-TE
Legacy nodes that receive the TLV don't know what it means and so object to
the Open (leaving a new node to re-Open for RSVP-TE only).
New nodes include the TLV and so indicate explicitly what they support.
I know it is late for that type of change, so how we proceed might depend on
what implementations have done already.
Adrian
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
Dear PCE-ers
I don’t want to distract from the SDN topic too much, but we have an
important decision to make about draft-ietf-pce-lsp-setup-type.
The shepherd review raised an issue that there is no way for a PCEP speaker
to indicate that it can’t (or won’t) support RSVP-TE as a path setup type. It
is entirely plausible that a node might not support RSVP-TE, or else have it
disabled, for example in an SR-only network.
We think that draft-ietf-pce-lsp-setup-type should be changed to allow a
speaker to declare that they do or don’t have support for RSVP-TE paths. There
are two proposals.
1. Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a
(new) RSVP-TE-CAPABILITY TLV in their OPEN object. If this TLV if missing, but
some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that
the speaker does not support RSVP-TE as a path setup type.
2. Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a
(new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON’T support
RSVP-TE. If this TLV is omitted, it will be assumed that they do support
RSVP-TE.
The problem with (1) is that it is not backwards compatible. Any existing
SR implementation which also supports RSVP will not currently send this new
capability. So, if we make change (1) then forwards-level implementations will
incorrectly conclude that such backwards-level implementations do not support
RSVP-TE.
The problem with (2) is that it is ugly, and in my opinion we should only do
something ugly with a new protocol extension if we simply can’t avoid doing it.
And so the question: are there any *deployments* of PCEP in a mixed
SR/RSVP-TE environment that would be broken if we made change (1)?
Thanks
Jon
--- End Message ---
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
