Subject: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 21 Jul 2017 15:07:01 +0000

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Jul 2017 18:55:17 +0100

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:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
 
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

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 24 Jul 2017 08:14:58 +0000

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:[email-masked]]
Sent: 21 July 2017 19:55
To: Jonathan Hardwick <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

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:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Dear PCE-ers

Thanks
Jon

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 24 Jul 2017 13:10:17 +0000

+1

I know you don’t like +1 that much, but there isn’t that much to add. In Italian we’d say “salva capra e cavoli” (it saves goat and cabbage)…meaning it’s backward compatible and not ugly 😊

Daniele

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: lunedì 24 luglio 2017 10:15
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Adrian,

It’s not exactly beautiful, but it’s not as ugly as RSVP-TE-NON-SUPPORT.

Cheers
Jon

From: Adrian Farrel [mailto:[email-masked]]
Sent: 21 July 2017 19:55
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

That means...

Adrian

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.

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 (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.

Thanks
Jon

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Jul 2017 19:50:36 +0100

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:[email-masked]] 
Sent: 24 July 2017 09:15
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
 
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.

Cheers
Jon

From: Adrian Farrel [mailto:[email-masked]] 
Sent: 21 July 2017 19:55
To: Jonathan Hardwick <[email-masked]>; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?

That means...

Adrian
 
From: Pce [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf
Of Jonathan Hardwick
Sent: 21 July 2017 16:07
To:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]>
[email-masked];
<mailto:[email-masked]>
[email-masked]
Cc:  <mailto:[email-masked]> [email-masked]
Subject: [Pce] Can we make a non-backwards compatible change to
draft-ietf-pce-lsp-setup-type?
 
Dear PCE-ers

 

 

Thanks
Jon

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 25 Jul 2017 05:21:06 +0000

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

Sent: 24 July 2017 19:51

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.

Adrian

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: 24 July 2017 09:15
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Adrian,

Cheers
Jon

That means...

Adrian

Dear PCE-ers

Thanks
Jon

---

From: Julien Meuric <[email-masked]>
Date: Tue, 25 Jul 2017 10:31:02 +0200

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 -
[email-masked]:

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:[email-masked]]

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

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:[email-masked]]

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:[email-masked]]
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Jul 2017 11:56:14 +0100

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:[email-masked]] 
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; [email-masked]; [email-masked]
Cc: [email-masked];
[email-masked]
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 - [email-masked]:
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.

Cheers
Jon

 

 
Adrian
 
From: Jonathan Hardwick [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: 24 July 2017 09:15

Adrian,

 

Cheers
Jon

From: Adrian Farrel [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: 21 July 2017 19:55

 
That means...

Adrian

 
Dear PCE-ers

 

 

Thanks
Jon

---

From: Mahendra Singh Negi <[email-masked]>
Date: Tue, 25 Jul 2017 12:12:25 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; [email-masked]
Cc: [email-masked]; [email-masked]
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."

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:[email-masked]]
Sent: 25 July 2017 09:31
To: Jonathan Hardwick; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 - [email-masked]<mailto:[email-masked]>:
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.

Cheers
Jon

Adrian

Adrian,

Cheers
Jon

That means...

Adrian

Dear PCE-ers

Thanks
Jon

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 25 Jul 2017 15:03:55 +0000

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:[email-masked]]
Sent: 25 July 2017 13:12
To: [email-masked]; 'Julien Meuric' <[email-masked]>; Jonathan Hardwick <[email-masked]>; [email-masked]; Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Dear All,

Regards,

From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Sighing slightly:-)

Cheers,
Adrian

Hi,

Cheers,

Julien

Cheers
Jon

Adrian

Adrian,

Cheers
Jon

That means...

Adrian

Dear PCE-ers

Thanks
Jon

---

From: Mahendra Singh Negi <[email-masked]>
Date: Wed, 26 Jul 2017 04:57:44 +0000

Very much OK with that.
Thanks a lot.

Regards,
Mahendra (Huawei Tech India Pvt. Ltd.)
From:Jonathan Hardwick
To:Mahendra Singh Negi,adrian,'Julien Meuric',pce,Dhruv Dhody,
Cc:draft-ietf-pce-lsp-setup-type,draft-ietf-pce-segment-routing,
Date:2017-07-25 20:36:04
Subject:RE: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

Best regards
Jon

Dear All,

Regards,

Sighing slightly:-)

Cheers,
Adrian

Hi,

Cheers,

Julien

Implementers – any views?

Cheers
Jon

Adrian

Adrian,

Cheers
Jon

That means...

Adrian

Dear PCE-ers

Thanks
Jon