Subject: [CCAMP] The description of Path Key retaining time in RFC5553

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 7 Nov 2013 19:24:26 +0000

Hi, all,

  The following is the piece of information that i mentioned already require retaining the Path key information for the lifetime of LSP. 

Section 3.2 from RFC5553
"
.......
On a Path message, the PKS SHOULD identify the LSR replacing the CPS and provide a Path Key that can be used to expand  the path segment.  In the latter case, the Path Key and its expansion SHOULD be retained by the LSR that performs the substitution for at least the lifetime of the LSP.  In both cases, the expansion of the PKS SHOULD be made available to diagnostic tools under the control of local policy.
"

My understanding of the stateful PCE (from PCE WG) is to have LSP-DB documenting information such as the identifiers (the 5-tuple), route, bw information etc. So I do not think our extensions defined in http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00 incur any new additional requirements. Please review our draft and let us know what you think.

Cheers,
Xian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 9 Nov 2013 03:57:53 +0000

Hi Zhang: 

Section 2.1 from RFC5553 state: "It is RECOMMENDED for a PCE to store the
PKS for a period of 10 minutes." Furthermore, please note that 16 bit path
keys are used as reuse of the path key is assumed.

The bottom line is that in your draft the PCE needs to remember the (path
key, path info) "states" for "indefinite" time. If you like we call such
PCE "path-stateful PCE" but it is stateful. Also, the solution is not
scalable as a PCE can only hold 64K of (path key, path info) states. Such
limitations and requirements need to be clearly stated in the draft.

Thanks

Regards Š Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Thursday, November 7, 2013 11:24 AM
To: zali <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: The description of Path Key retaining time in RFC5553

>Hi, all,
>
>  The following is the piece of information that i mentioned already
>require retaining the Path key information for the lifetime of LSP.
>
>Section 3.2 from RFC5553
>"
>.......
>On a Path message, the PKS SHOULD identify the LSR replacing the CPS and
>provide a Path Key that can be used to expand  the path segment.  In the
>latter case, the Path Key and its expansion SHOULD be retained by the LSR
>that performs the substitution for at least the lifetime of the LSP.  In
>both cases, the expansion of the PKS SHOULD be made available to
>diagnostic tools under the control of local policy.
>"
>
>My understanding of the stateful PCE (from PCE WG) is to have LSP-DB
>documenting information such as the identifiers (the 5-tuple), route, bw
>information etc. So I do not think our extensions defined in
>http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00
>incur any new additional requirements. Please review our draft and let us
>know what you think.
>
>Cheers,
>Xian

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 12 Nov 2013 02:09:41 +0000

Hi Zafar,

It does not matter what it is. 

Do you see any problem for an element (a stateless PCE or NMS or even a node) to store path key information?

Please don't argue scaliblity issue because you can see even a GMPLS node can store lots of informaiton. 

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Saturday, November 09, 2013 11:58 AM
To: Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Hi Zhang: 

Thanks

Regards Š Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Thursday, November 7, 2013 11:24 AM
To: zali <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: The description of Path Key retaining time in RFC5553

>incur any new additional requirements. Please review our draft and let us

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:44:22 +0000

Fatai -

If a PCE is saving state, then in what way is it "stateless".  The text
you have below and along with Zafar's quote (from RFC5520) is of a PCE
that CACHEs the result (ERO segment) of a constrained path selection along
with the key it handed out.  As a path is signaled an LSR or (or perhaps
several LSRs) may contact PCEs using a path key to retrieve the path in
order to extend or complete the ERO.

But the PCE merely caches.  The only state that is saved for the life of
the LSP is at the LSR.

George

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 15 Nov 2013 02:43:48 +0000

Hi George,

Apart from the difference between "CACHE" and "SAVE", it seems that you don't see any problem. 

In addition, you can find a place to store so complex 5 tuplet information, why there is no place to store simple Path Key? 

Please make our logic more logical. 

Best Regards

Fatai

-----Original Message-----
From: George Swallow (swallow) [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 2:44 AM
To: Fatai Zhang; Zafar Ali (zali); Zhangxian (Xian)
Cc: [email-masked]; George Swallow (swallow)
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Fatai -

George

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 Nov 2013 03:12:33 +0000

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Monday, November 11, 2013 9:09 PM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

>can store lots of informaiton.

Fatai- 

I did not get what you are saying. What I was saying is:

* Tunnel-id is 16 bit. I.e., client name space is 16 bit. There can be
more than one LSP per tunnel.
* Path key is 16 bits. I.e., server name space is 16 bits. Each LSP needs
a Path Key. 
* There is 1:N relationship between PCC and PCE (server). PCE sever may
even be centralized.
* You are requiring (Path key, path info) "state" to be stored at the PCE
server for the life time of the connections.
* Path keys have hold-off timer of 30 minutes before they can be reused.

Hence, in your solution, PCE server would run out of Path Keys much before
clients runs out of tunnel name space. In your solution, if you have a
centralized PCE, you can only support 64K connection IN THE NETWORK! I am
not sure why you want to ignore these scaling restrictions.

Thanks

Regards...Zafar

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 15 Nov 2013 03:43:44 +0000

Hi, Zafar,
   
   Thank you for sharing your thought. But I disagree. Why having a 16-bit PK space will constrain the network to have only 64k LSPs? PK is needed only when the LSP is needed to use as a constraint for path diversity. 

   Furthermore, I do not see why storing PKS in PCE for a longer time, even if the lifetime of LSP, will cause any scalability issue. PKS can be used locally by the PCE (stateless) per node basis, i.e. combining PKS + source node address as a way for PCE to solve the issue you mentioned below, which is internal to the PCE. Do you agree? If needed, we can capture this in the manageability section.

Regards,
Xian

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]] 
Sent: 2013年11月15日 11:13
To: Fatai Zhang; Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: The description of Path Key retaining time in RFC5553

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Monday, November 11, 2013 9:09 PM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

Fatai- 

Thanks

Regards...Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 Nov 2013 18:55:32 +0000

Hi Xian:

Please see in-line.

Thanks

Regards … Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Thursday, November 14, 2013 10:43 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

>Hi, Zafar,
>   
>   Thank you for sharing your thought. But I disagree. Why having a
>16-bit PK space will constrain the network to have only 64k LSPs? PK is
>needed only when the LSP is needed to use as a constraint for path
>diversity.

I disagree - 

- How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.

> 
>
>   Furthermore, I do not see why storing PKS in PCE for a longer time,
>even if the lifetime of LSP, will cause any scalability issue. PKS can be
>used locally by the PCE (stateless) per node basis

Please stop calling a solution that mandate (path key, path) "states" to
be stored for lifetime of the connection as a stateless solution. It is
stateful w.r.t. Path info states. Let's define a new term for such
stateful PCE and use it. Furthermore, as you solution required PCE to keep
path states for life time of the connection, why not just use stateful
PCE, instead? 

>, i.e. combining PKS + source node address as a way for PCE to solve the
>issue you mentioned below, which is internal to the PCE.
>Do you agree?

No... In your solution a PCE cannot serve more than 64 paths in the
network. If you have a centralized PCE, you cannot have more than 64K LSPs
in the *entire network*. This does not fly.

> If needed, we can capture this in the manageability section.
>
>Regards,
>Xian
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 15 Nov 2013 19:47:39 +0000

Hi Fatai- 

Please see in-line.

Thanks

Regards ... Zafar

<snip>
>Apart from the difference between "CACHE" and "SAVE", it seems that you

There is a BIG difference than the words may suggest. Both from protocol
view point as well as PCE implementation view point.
- From protocol view point, in addition to other issues emailed earlier, I
also sent you/ Xian scalability concerns and your solution simply does not
work. 
- From implementation point of view, the differences are as follows: a PCE
that caches the (path key, path info) state, does not need to worry high
availability cases. Your solution requires a PCE to make (path key, path
info) persistence across the life time of the LSP using this (path key,
path info) state. 

>
>In addition, you can find a place to store so complex 5 tuplet
>information, why there is no place to store simple Path Key?

In addition to what is mentioned above:

1. All RSVP TE nodes that perform the ERO computation, already store the
ERO info for the LSP in the Path State block of the LSP. And that too for
the life time of the connection!
2. Use of 5 tuple (RSVP TE FEC) does not suffer from 16 bit path key
scaling issues I outlined in the other email chain.

---

From: Cyril Margaria <[email-masked]>
Date: Fri, 15 Nov 2013 21:09:29 +0100

Hi,
please see inline for comments.

> * Path key is 16 bits. I.e., server name space is 16 bits. Each LSP needs

I do not recall that each LSP needs a path key, each path does, but not
each LSP.
So the scalability is not related to amount of LSPs, but the amount of path
use, which scale quite differently than the number of LSPs.

> server for the life time of the connections.

That is correct, the PCE need to keep a state on the path used, but using
the term statefull in that case is confusing and misleading, as its tied to
a full LSP DB. TED itself is a state too.

> as stated before, you would support a maximum of 64k Paths, given the
diversity constraint you want to support.
In any case the scaling of the solution is to be considered, but is there
other problem with that solution?
This solution is attractive as it provides a complete solution ( deploy a
PCE colocated with the LSR, only resolving  PKS, the rest is already
defined).

Regards,
Cyril.

Thanks

---

From: John E Drake <[email-masked]>
Date: Fri, 15 Nov 2013 20:38:05 +0000

Zafar,

Lest we forget, I have already pointed out your solution not only requires more state but also requires that this state be kept at orders of magnitude more nodes and that you have not said a word as to how to accomplish this.

Yours Irrespectively,

John

> Sent: Friday, November 15, 2013 11:48 AM
> To: Fatai Zhang; George Swallow (swallow); Zhangxian (Xian)
> Cc: [email-masked]
> There is a BIG difference than the words may suggest. Both from protocol view
> point as well as PCE implementation view point.
> - From protocol view point, in addition to other issues emailed earlier, I also
> sent you/ Xian scalability concerns and your solution simply does not work.
> - From implementation point of view, the differences are as follows: a PCE that
> caches the (path key, path info) state, does not need to worry high availability
> cases. Your solution requires a PCE to make (path key, path
> info) persistence across the life time of the LSP using this (path key, path info)
> state.
> 
> >
> 1. All RSVP TE nodes that perform the ERO computation, already store the ERO
> info for the LSP in the Path State block of the LSP. And that too for the life time
> of the connection!
> 2. Use of 5 tuple (RSVP TE FEC) does not suffer from 16 bit path key scaling
> issues I outlined in the other email chain.
> 
> >
> >that CACHEs the result (ERO segment) of a constrained path selection
> >along with the key it handed out.  As a path is signaled an LSR or (or
> >perhaps several LSRs) may contact PCEs using a path key to retrieve the
> >path in order to extend or complete the ERO.
> >
> >But the PCE merely caches.  The only state that is saved for the life
> >of the LSP is at the LSR.
> >
> >George
> >
> >>Do you see any problem for an element (a stateless PCE or NMS or even
> >>a
> >>node) to store path key information?
> >>
> >>Section 2.1 from RFC5553 state: "It is RECOMMENDED for a PCE to store
> >>the PKS for a period of 10 minutes." Furthermore, please note that 16
> >>bit path keys are used as reuse of the path key is assumed.
> >>
> >>
> >>The bottom line is that in your draft the PCE needs to remember the
> >>(path key, path info) "states" for "indefinite" time. If you like we
> >>call such PCE "path-stateful PCE" but it is stateful. Also, the
> >>solution is not scalable as a PCE can only hold 64K of (path key, path
> >>info) states. Such limitations and requirements need to be clearly stated in
> the draft.
> >>
> >>Thanks
> >>
> >>Regards Š Zafar
> >>
> >>
> >>>On a Path message, the PKS SHOULD identify the LSR replacing the CPS
> >>>and provide a Path Key that can be used to expand  the path segment.
> >>>In the latter case, the Path Key and its expansion SHOULD be retained
> >>>by the LSR that performs the substitution for at least the lifetime
> >>>of the LSP.  In both cases, the expansion of the PKS SHOULD be made
> >>>available to diagnostic tools under the control of local policy.
> >>>"
> >>>
> >>>documenting information such as the identifiers (the 5-tuple), route,
> >>>bw information etc. So I do not think our extensions defined in
> >>>http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-
> >>>00 incur any new additional requirements. Please review our draft and
> >>>let us know what you think.
> >>>
> >>>Cheers,
> >>>Xian
> >>

---

From: John E Drake <[email-masked]>
Date: Fri, 15 Nov 2013 21:04:00 +0000

Cyril,

A very nice note regarding a very nice draft.  I have a few questions for clarification, viz, is the reason why 'Path Key' is called that because it deals with paths and not LSPs?  Given this, doesn't our 'stateful PCE thingy', as defined by Zafar, need to maintain path state and not LSP state?  Given the transient nature of LSPs doesn't this actually make a lot of sense?

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cyril Margaria
Sent: Friday, November 15, 2013 12:09 PM
To: Zafar Ali (zali)
Cc: [email-masked]
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Hi,

On 15 November 2013 04:12, Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 11, 2013 9:09 PM
To: zali <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: The description of Path Key retaining time in RFC5553

Fatai-

I do not recall that each LSP needs a path key, each path does, but not each LSP.
So the scalability is not related to amount of LSPs, but the amount of path use, which scale quite differently than the number of LSPs.

That is correct, the PCE need to keep a state on the path used, but using the term statefull in that case is confusing and misleading, as its tied to a full LSP DB. TED itself is a state too.
* Path keys have hold-off timer of 30 minutes before they can be reused.

Hence, in your solution, PCE server would run out of Path Keys much before
clients runs out of tunnel name space. In your solution, if you have a
centralized PCE, you can only support 64K connection IN THE NETWORK! I am
not sure why you want to ignore these scaling restrictions.
as stated before, you would support a maximum of 64k Paths, given the diversity constraint you want to support.
In any case the scaling of the solution is to be considered, but is there other problem with that solution?
This solution is attractive as it provides a complete solution ( deploy a PCE colocated with the LSR, only resolving  PKS, the rest is already defined).

Regards,
Cyril.
Thanks

Regards...Zafar

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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 18 Nov 2013 08:22:22 +0000

Hi, Zafar, 

    Let me summarize a bit, so that whoever follow our discussion are not lost. 

1st viewpoint: you still think that 16-bit PKS is not sufficient, since it limits the number of a LSP within a network to be 64k. 
Our Reply: the purpose of this draft is to address the LSPs that across UNI and/or multi-domains, *NOT* the LSP within a network. Let's not argue theoretically it can be any number for the former. From current deployment, it is far from enough. Besides, we also provide a PKS+ first node of the encode segment as an alternative for the problem you worry much about, is it enough? 

2nd viewpoint: you believe that the PCE needs to store the PKS information longer than required as RFC5520 and you would like to give a name to it.
Our reply: We get your point and will add into our draft this information, as you suggested. However, we disagree to use the term "stateful" since people already accept the definition of stateful PCE in PCE WG. Also, it is meaningless to argue on the terminologies as long as we make the point clear in the draft. Please do not forget that the border node can be the "PCE" for decoding the PK (which you should be much aware of), storing such information is not an problem. Having said that, our draft do not limit the model of how PKS is decoded.

  As usual, we can agree to disagree, but I think we both have made the point clear enough till now. 

  Please do not forget the reason we write this draft. As you John already mentioned, we do not see any description in draft-ietf-ccamp-lsp-diversity about how the border node can decode the sub-object defined upon receiving the path diversity constraint, thus there is NO complete solution in your draft. I vaguely remember you mentioned a proprietary method for doing so, do you mean that whoever implement draft-ietf-ccamp-lsp-diversity are forced to need to consult the draft authors for a complete solution? Please consider this in the next update of this draft.

Cheers,
Xian(on behalf of all co-authors of the draft draft-zhang-ccamp-route-exclusion-pathkey)

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]] 
Sent: 2013年11月16日 2:56
To: Zhangxian (Xian); Fatai Zhang
Cc: [email-masked]
Subject: Re: The description of Path Key retaining time in RFC5553

Hi Xian:

Please see in-line.

Thanks

Regards … Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Thursday, November 14, 2013 10:43 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

I disagree -

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 13:56:07 +0000

Xian,

As Cyril pointed out, Zafar does not understand that RFC 5553 deals with paths rather than with LSPs.  Hence his arguments wrt the lack of the scalability of an RFC 5553 based solution are specious. 

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Zhangxian (Xian)
> Sent: Monday, November 18, 2013 12:22 AM
> To: Zafar Ali (zali)
> Cc: [email-masked]
> 1st viewpoint: you still think that 16-bit PKS is not sufficient, since it limits the
> number of a LSP within a network to be 64k.
> Our Reply: the purpose of this draft is to address the LSPs that across UNI
> and/or multi-domains, *NOT* the LSP within a network. Let's not argue
> theoretically it can be any number for the former. From current deployment, it
> is far from enough. Besides, we also provide a PKS+ first node of the encode
> segment as an alternative for the problem you worry much about, is it
> enough?
> 
> 2nd viewpoint: you believe that the PCE needs to store the PKS information
> longer than required as RFC5520 and you would like to give a name to it.
> Our reply: We get your point and will add into our draft this information, as you
> suggested. However, we disagree to use the term "stateful" since people
> already accept the definition of stateful PCE in PCE WG. Also, it is meaningless
> to argue on the terminologies as long as we make the point clear in the draft.
> Please do not forget that the border node can be the "PCE" for decoding the PK
> (which you should be much aware of), storing such information is not an
> problem. Having said that, our draft do not limit the model of how PKS is
> decoded.
> 
>   Please do not forget the reason we write this draft. As you John already
> mentioned, we do not see any description in draft-ietf-ccamp-lsp-diversity
> about how the border node can decode the sub-object defined upon receiving
> the path diversity constraint, thus there is NO complete solution in your draft. I
> vaguely remember you mentioned a proprietary method for doing so, do you
> mean that whoever implement draft-ietf-ccamp-lsp-diversity are forced to
> need to consult the draft authors for a complete solution? Please consider this
> in the next update of this draft.
> 
> 
> Cheers,
> diversity by another LSP in a future time? E.g., if you are signaling LSP1 at t1.
> How would PCC or PCE will know that some other LSP (LSP2) will be requesting
> diversity from LSP1 at a future time t2.
> 
> >
> >
> >even if the lifetime of LSP, will cause any scalability issue. PKS can
> >be used locally by the PCE (stateless) per node basis
> 
> Please stop calling a solution that mandate (path key, path) "states" to be
> stored for lifetime of the connection as a stateless solution. It is stateful w.r.t.
> Path info states. Let's define a new term for such stateful PCE and use it.
> Furthermore, as you solution required PCE to keep path states for life time of
> the connection, why not just use stateful PCE, instead?
> 
> 
> >, i.e. combining PKS + source node address as a way for PCE to solve
> >the issue you mentioned below, which is internal to the PCE.
> >Do you agree?
> 
> No... In your solution a PCE cannot serve more than 64 paths in the network. If
> you have a centralized PCE, you cannot have more than 64K LSPs in the *entire
> network*. This does not fly.
> 
> 
> >* Path key is 16 bits. I.e., server name space is 16 bits. Each LSP
> >needs a Path Key.
> >* You are requiring (Path key, path info) "state" to be stored at the
> >PCE server for the life time of the connections.
> >Hence, in your solution, PCE server would run out of Path Keys much
> >before clients runs out of tunnel name space. In your solution, if you
> >have a centralized PCE, you can only support 64K connection IN THE
> >NETWORK! I am not sure why you want to ignore these scaling restrictions.
> >
> >Thanks
> >
> >Regards...Zafar
> >
> >>
> >
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 17:46:55 +0000

Cyrill-

Please see in-line.

Thanks

Regards … Zafar

From: Cyril Margaria <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 15, 2013 3:09 PM
To: zali <[email-masked]<mailto:[email-masked]>>
Cc: Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

Hi,

-----Original Message-----
From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 11, 2013 9:09 PM
To: zali <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: The description of Path Key retaining time in RFC5553

Fatai-

I just responded to the same confusion in the other email – sorry for the duplicate.

  *
How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.

Yes, we need a new term for such stateful PCEs. Let's call it "path-stateful" PCE.

If we are using "path-stateful" PCE, why not use "stateful" PCE.

Regards,
Cyril.

Thanks

Regards...Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 18:32:01 +0000

Hi Xian:

Please see in-line.

Thanks

Regards … Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Monday, November 18, 2013 3:22 AM
To: zali <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

>1st viewpoint: you still think that 16-bit PKS is not sufficient, since
>it limits the number of a LSP within a network to be 64k.
>Our Reply: the purpose of this draft is to address the LSPs that across
>UNI and/or multi-domains, *NOT* the LSP within a network.

You dogged my question:

How can PCE differentiate between requests that require path keys to be
persistent for life time of LSP vs. LSPs that require path keys during LSP
setup only? 
This couple with the following still present a Scaling issue with your
solution: 
+ How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.

note: Path info expiry timer is same for all types of requests/ LSPs.
Hence, I still see the scaling issue.

You also did not answer why we cannot use stateful PCE, instead.

>Let's not argue theoretically it can be any number for the former.

This is not a theoretically discussion.

>From current deployment, it is far from enough. Besides, we also provide
>a PKS+ first node of the encode segment as an alternative for the problem
>you worry much about, is it enough?
>
>2nd viewpoint: you believe that the PCE needs to store the PKS
>information longer than required as RFC5520 and you would like to give a
>name to it.
>Our reply: We get your point and will add into our draft this
>information, as you suggested. However, we disagree to use the term
>"stateful" since people already accept the definition of stateful PCE in
>PCE WG. 

I agree and I did mention that let's define a new term. I suggested
"path-stateful" PCE.

>Also, it is meaningless to argue on the terminologies as long as we make
>the point clear in the draft. Please do not forget that the border node
>can be the "PCE" for decoding the PK (which you should be much aware of),
>storing such information is not an problem. Having said that, our draft
>do not limit the model of how PKS is decoded.
>
>  Please do not forget the reason we write this draft. As you John
>already mentioned, we do not see any description in
>draft-ietf-ccamp-lsp-diversity about how the border node can decode the
>sub-object defined upon receiving the path diversity constraint, thus
>there is NO complete solution in your draft. I vaguely remember you
>mentioned a proprietary method for doing so, do you mean that whoever
>implement draft-ietf-ccamp-lsp-diversity are forced to need to consult
>the draft authors for a complete solution? Please consider this in the
>next update of this draft.
>
>
>Cheers,
>Xian(on behalf of all co-authors of the draft
>draft-zhang-ccamp-route-exclusion-pathkey)
>
>>>Please don't argue scaliblity issue because you can see even a GMPLS
>>>node
>>>can store lots of informaiton.
>>>
>>
>>Fatai- 
>>
>>before

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 18:24:18 +0000

Snipped, comment inline

Yours Irrespectively,

John

I just responded to the same confusion in the other email - sorry for the duplicate.

  *   How would PCC or PCE know ahead of time which LSP will be used for
diversity by another LSP in a future time? E.g., if you are signaling LSP1
at t1. How would PCC or PCE will know that some other LSP (LSP2) will be
requesting diversity from LSP1 at a future time t2.
[JD]   A PCE would return a path key to the initiator of LSP 1.  When LSP2 is signaled, it would include that path key along w/ an indication of whether LSP2 is to be disjointly or congruently routed wrt that path key.  Btw, as has been noted, if one is truly interested in disjoint routing, one should request LSP1 and LSP2 together so that Suurballe can be used.
Perhaps the WG should be developing the signaling to support this.
as stated before, you would support a maximum of 64k Paths, given the diversity constraint you want to support.
In any case the scaling of the solution is to be considered, but is there other problem with that solution?
This solution is attractive as it provides a complete solution ( deploy a PCE colocated with the LSR, only resolving  PKS, the rest is already defined).

[JD]  Because it is an already defined term w/ a completely different meaning?

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 18:59:02 +0000

John: 

Can you advise what assumptions can be made between Paths served by the
PCE and LSPs using those paths to justify your (hostile) assertion that I
do not understand scalability of
draft-zhang-ccamp-route-exclusion-pathkey-00? E.g., if you assume Path
<--> LSP is 1:M, what is value of M we can assume in debating scaling of
the draft under discussion? Please also see my recent response to Xian.

n.b. BTW I was commenting on scaling issue with
draft-zhang-ccamp-route-exclusion-pathkey-00.txt and not RFC 5553. We are
having technical discussion in a friendly environment. But I am
consistently seeing degrading comments or personal attacks from you :(.

Thanks

Regards … Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, November 18, 2013 8:56 AM
To: "Zhangxian (Xian)" <[email-masked]>, zali <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

>Xian,
>
>As Cyril pointed out, Zafar does not understand that RFC 5553 deals with
>paths rather than with LSPs.  Hence his arguments wrt the lack of the
>scalability of an RFC 5553 based solution are specious.
>
>Yours Irrespectively,
>
>John
>
>>it limits the
>>UNI
>>information
>>information, as you
>>   As usual, we can agree to disagree, but I think we both have made the
>>point
>> clear enough till now.
>> 
>>already
>>network. If
>> >>node can store lots of informaiton.
>> >>
>> >
>> >Fatai-
>> >

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 19:07:33 +0000

John-

I understand that but my point was that draft-zhang-ccamp-route-exclusion-pathkey-00 requires path info to be persistent across the life time of the connection. Also there is no way to differentiate which LSP will require path info to be persistent vs. requests for which Path info can be purged.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 18, 2013 1:24 PM
To: zali <[email-masked]<mailto:[email-masked]>>, Cyril Margaria <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] The description of Path Key retaining time in RFC5553

Snipped, comment inline

Yours Irrespectively,

John

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 19:28:55 +0000

Zafar,

A given PCE can maintain path state for 64K paths.  Since it is keeping path state it does not need to keep *any* LSP state.  This is simply RFC5553 behavior.   

Yours Irrespectively,

John

> Sent: Monday, November 18, 2013 10:59 AM
> To: John E Drake; Zhangxian (Xian)
> Cc: [email-masked]
> PCE and LSPs using those paths to justify your (hostile) assertion that I do not
> understand scalability of draft-zhang-ccamp-route-exclusion-pathkey-00? E.g.,
> if you assume Path <--> LSP is 1:M, what is value of M we can assume in
> debating scaling of the draft under discussion? Please also see my recent
> response to Xian.
> 
> n.b. BTW I was commenting on scaling issue with draft-zhang-ccamp-route-
> exclusion-pathkey-00.txt and not RFC 5553. We are having technical discussion
> in a friendly environment. But I am consistently seeing degrading comments or
> personal attacks from you :(.
> 
> Thanks
> 
> Regards … Zafar
> 
> 
> >As Cyril pointed out, Zafar does not understand that RFC 5553 deals
> >with paths rather than with LSPs.  Hence his arguments wrt the lack of
> >the scalability of an RFC 5553 based solution are specious.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >>Behalf  Of Zhangxian (Xian)
> >> 1st viewpoint: you still think that 16-bit PKS is not sufficient,
> >>since it limits the  number of a LSP within a network to be 64k.
> >> Our Reply: the purpose of this draft is to address the LSPs that
> >>across UNI  and/or multi-domains, *NOT* the LSP within a network.
> >>From current deployment, it  is far from enough. Besides, we also
> >>provide a PKS+ first node of the encode  segment as an alternative for
> >>the problem you worry much about, is it  enough?
> >>
> >>information  longer than required as RFC5520 and you would like to
> >>give a name to it.
> >>"stateful" since people  already accept the definition of stateful PCE
> >>in PCE WG. Also, it is meaningless  to argue on the terminologies as
> >>long as we make the point clear in the draft.
> >> Please do not forget that the border node can be the "PCE" for
> >>decoding the PK  (which you should be much aware of), storing such
> >>information is not an  problem. Having said that, our draft do not
> >>limit the model of how PKS is  decoded.
> >>
> >>draft-ietf-ccamp-lsp-diversity  about how the border node can decode
> >>the sub-object defined upon receiving  the path diversity constraint,
> >>thus there is NO complete solution in your draft. I  vaguely remember
> >>you mentioned a proprietary method for doing so, do you  mean that
> >>whoever implement draft-ietf-ccamp-lsp-diversity are forced to  need
> >>to consult the draft authors for a complete solution? Please consider
> >>this  in the next update of this draft.
> >>
> >>
> >> Cheers,
> >> >16-bit PK space will constrain the network to have only 64k LSPs? PK
> >> >is needed only when the LSP is needed to use as a constraint for
> >> >path diversity.
> >>
> >> I disagree -
> >>
> >> How would PCC or PCE will know that some other LSP (LSP2) will be
> >> >   Furthermore, I do not see why storing PKS in PCE for a longer
> >> >time, even if the lifetime of LSP, will cause any scalability issue.
> >> >PKS can be used locally by the PCE (stateless) per node basis
> >>
> >> Furthermore, as you solution required PCE to keep path states for
> >>life time of  the connection, why not just use stateful PCE, instead?
> >>
> >>
> >>network. If  you have a centralized PCE, you cannot have more than 64K
> >>LSPs in the *entire  network*. This does not fly.
> >>
> >>
> >> >>Please don't argue scaliblity issue because you can see even a
> >> >>GMPLS node can store lots of informaiton.
> >> >>
> >> >
> >> >Fatai-
> >> >
> >> >* Tunnel-id is 16 bit. I.e., client name space is 16 bit. There can
> >> >be more than one LSP per tunnel.
> >> >* There is 1:N relationship between PCC and PCE (server). PCE sever
> >> >may even be centralized.
> >> >* You are requiring (Path key, path info) "state" to be stored at
> >> >the PCE server for the life time of the connections.
> >> >before clients runs out of tunnel name space. In your solution, if
> >> >you have a centralized PCE, you can only support 64K connection IN
> >> >THE NETWORK! I am not sure why you want to ignore these scaling
> >>restrictions.
> >> >
> >> >Thanks
> >> >
> >> >Regards...Zafar
> >> >
> >> >>
> >> >
> >>

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 19:40:50 +0000

Comments inline.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, November 18, 2013 11:08 AM
To: John E Drake; Cyril Margaria
Cc: [email-masked]
Subject: Re: [CCAMP] The description of Path Key retaining time in RFC5553

John-

I understand that but my point was that draft-zhang-ccamp-route-exclusion-pathkey-00 requires path info to be persistent across the life time of the connection.

[JD]  It doesn't say that.  However, given that a PCE maintains path state and not LSP state, it seem perfectly reasonable to assume that a path key is valid for the duration of an LSP's existence, modulo changes in the server network topology that invalidate it.  Also, although it is extremely unlikely that the path state would be deleted, nothing breaks if it is deleted.  The network is simply unable to compute a disjoint route, which can also happen for a variety of other reasons.

Also there is no way to differentiate which LSP will require path info to be persistent vs. requests for which Path info can be purged.

[JD]  Given that a PCE maintains path state and not LSP state, why would it care?

Thanks

Regards ... Zafar

Snipped, comment inline

Yours Irrespectively,

John

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 19:51:17 +0000

Hi John- 

So you agree that a PCE cannot support more than 64K Paths. In a
centralized PCE environment this would mean 64K Path states for the entire
network. If I would assume M =1 (I asked a question for M; you can pick
some other M) this would mean that *network* cannot served more than 64K
LSPs. Recall this scaling restriction is not with RFC5553 (as RFC5553
RECOMMENDS path info to be purged after 10 mins). This restriction comes
from draft-zhang-ccamp-route-exclusion-pathkey-00, which requires path
info to be saved for the life of an LSP (using it).

Given that Path to "LSPs using the Path" is not stored at (stateless) PCE,
how would PCE ever be able to purge the Path state? We keep saying for
life time of the connection but how would PCE know (all) client(s) has
(have) deleted the LSP in question? I.e., how would (and when) PCE be able
to purge the Path states? Again RFC5553 RECOMMENDS a simple (10 min) timer
based mechanism, which does not work for
draft-zhang-ccamp-route-exclusion-pathkey-00.

Thanks

Regards … Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, November 18, 2013 2:28 PM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: The description of Path Key retaining time in RFC5553

>Zafar,
>
>A given PCE can maintain path state for 64K paths.  Since it is keeping
>path state it does not need to keep *any* LSP state.  This is simply
>RFC5553 behavior. 
>
>Yours Irrespectively,
>
>John
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 18 Nov 2013 19:58:35 +0000

John-

In-line please.

Thanks

Regards … Zafar

Date: Monday, November 18, 2013 2:40 PM

Comments inline.

Yours Irrespectively,

John

Cc: [email-masked]<mailto:[email-masked]>

John-

[JD]  It doesn’t say that.  However, given that a PCE maintains path state and not LSP state, it seem perfectly reasonable to assume that a path key is valid for the duration of an LSP’s existence, modulo changes in the server network topology that invalidate it.  Also, although it is extremely unlikely that the path state would be deleted, nothing breaks if it is deleted.  The network is simply unable to compute a disjoint route, which can also happen for a variety of other reasons.

If LSP1 is signaled at t1 (using PK1). How would PCC or PCE will know that some other LSP (LSP2) will no longer be requesting diversity from LSP1 (using PK1) at a future time t2? I.e., when PCE can purge PK1? If PK1 is purged before t2, the solution did not address the requirement. On the other hand, PCE needs to purge Path states to scale.

Please also see my response to the other email w.r.t. Difficulties in purging Path Keys in the way draft-zhang-ccamp-route-exclusion-pathkey-00 is using it.

Thanks

Regards … Zafar

Snipped, comment inline

Yours Irrespectively,

John

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 20:47:46 +0000

Comments inline.

Yours Irrespectively,

John

> Sent: Monday, November 18, 2013 11:51 AM
> So you agree that a PCE cannot support more than 64K Paths.

[JD]  There are 64k path keys associated with a given PCE address.  There is no requirement that a PCE
have only one address.   

> In a centralized
> PCE environment this would mean 64K Path states for the entire network. If I
> would assume M =1 (I asked a question for M; you can pick some other M) this
> would mean that *network* cannot served more than 64K LSPs.

[JD]  in an optical network a more realistic number is in the range 64-128, resulting in 4,096,000 - 8,192,000
LSPs, again per PCE address.

> Recall this
> scaling restriction is not with RFC5553 (as RFC5553 RECOMMENDS path info
> to be purged after 10 mins). 

 [JD]  That's incorrect.  RFC 5553 does not say a word about this.  RFC 5520 recommends that a path key be *kept*
 for at least ten minutes and indicates that this value is configurable.  It also indicates that the purging of path state
is simply a house keeping procedure.

>This restriction comes from draft-zhang-ccamp-
> route-exclusion-pathkey-00, which requires path info to be saved for the life of
> an LSP (using it).

[JD]  That's incorrect.  It *does not* say this.  Further, why would diversely routed LSPs not be established concurrently?  If they are not,
it defeats the purpose of having diversely routed LSPs.  

> 
> Given that Path to "LSPs using the Path" is not stored at (stateless) PCE, how
> would PCE ever be able to purge the Path state? We keep saying for life time of
> the connection but how would PCE know (all) client(s) has
> (have) deleted the LSP in question?

[JD]   It continues to purge path state as per RFC 5520.  Nothing breaks if the path state is purged, and path state can also be
invalidated due to depletion of server network resources or changes in server network topology.

[> I.e., how would (and when) PCE be able to
> purge the Path states? Again RFC5553 RECOMMENDS a simple (10 min) timer
> based mechanism, which does not work for draft-zhang-ccamp-route-
> exclusion-pathkey-00.

[JD]  See my previous comments.

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Nov 2013 21:16:18 +0000

If LSP1 is signaled at t1 (using PK1). How would PCC or PCE will know that some other LSP (LSP2) will no longer be requesting diversity from LSP1 (using PK1) at a future time t2? I.e., when PCE can purge PK1? If PK1 is purged before t2, the solution did not address the requirement.

[JD]  Three points.  Operationally, diversely routed LSPs are established concurrently so operationally this is a non-issue.  Since path state can be used for multiple LSPs there is no reason to aggressively purge it.  Your solution requires that every node at the edge of an abstract node has complete knowledge of the RSVP-TE explicit route and identifier of every LSP transiting that abstract node and to this point you have not indicated how this information would be distributed or maintained.

On the other hand, PCE needs to purge Path states to scale.

[JD]  Sever blades currently have on the order of 768GB of system memory and a path is on the order of 1K.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 19 Nov 2013 18:52:31 +0000

Hi John- 

Please see in-line.

Thanks

Regards Š Zafar

<snip> 
>is no requirement that a PCE

This is incorrect. One address per PCE is a requirement as per rfc5088.
Quoting from http://tools.ietf.org/html/rfc5088#page-7

"The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
   PCED TLV.  It MAY appear twice, when the PCE has both an IPv4 and
   IPv6 address.  It MUST NOT appear more than once for the same address
   type.  If it appears more than once for the same address type, only
   the first occurrence is processed and any others MUST be ignored."

>[JD]  in an optical network a more realistic number is in the range
>64-128, resulting in 4,096,000 - 8,192,000

I am not sure where you brought 64-128 bit space. In rfc5520, PCE Path Key
is defined as a 16 bit number.

> [JD]  That's incorrect.  RFC 5553 does not say a word about this.  RFC
>5520 recommends that a path key be *kept*
> for at least ten minutes and indicates that this value is configurable.
>It also indicates that the purging of path state

I was quoting following text from rfc5520:

"It is RECOMMENDED for a PCE to store the PKS for a period of 10 minutes."

>[JD]  That's incorrect.  It *does not* say this.  Further, why would
>diversely routed LSPs not be established concurrently?  If they are not,

In that case, why cannot we use RFC5440 (SVEC object), instead? Why do you
need draft-zhang-ccamp-route-exclusion-pathkey-00?

>[JD]   It continues to purge path state as per RFC 5520.  Nothing breaks
>if the path state is purged, and path state can also be

So you agree that the solution is broken. It only works sometimes.

Speaking of handling changes in server topology. This is another aspect
that draft-zhang-ccamp-route-exclusion-pathkey-00 does NOT talks about at
all. In this respect, please note that:

1. A PCC that does not have server topology (UNI, which is target case for
this draft). So it cannot verify Paths or check if diversity is still met.
2. A passive PCE can verify Paths and can detect if diversity is still met
but cannot take action.

So once draft-zhang-ccamp-route-exclusion-pathkey-00 sets up the service,
it cannot handle topology changes.

---

From: John E Drake <[email-masked]>
Date: Tue, 19 Nov 2013 21:38:11 +0000

Comments inline

Yours Irrespectively,

John

> >[JD]  There are 64k path keys associated with a given PCE address.
> >There is no requirement that a PCE have only one address.
> 

[JD]  Where in RFC 5508 does it say that only one PCED TLV per router can be advertised?  Further, RFC 5508 is but one of many methods of establishing PCEP sessions.

> >> would assume M =1 (I asked a question for M; you can pick some other
> >>M) this  would mean that *network* cannot served more than 64K LSPs.
> >
> >64-128, resulting in 4,096,000 - 8,192,000 LSPs, again per PCE address.
> 
> I am not sure where you brought 64-128 bit space. In rfc5520, PCE Path Key is
> defined as a 16 bit number.

[JD]   I think you missed the point.  In an optical network there are typically 64 or 128 channels per DWDM line system.  This means that there could be 64 or 128 LSPs routed on the same path through the server and they would all use the same path key. 

> 
> >
> >> Recall this
> >> scaling restriction is not with RFC5553 (as RFC5553 RECOMMENDS path
> >> info to be purged after 10 mins).
> >
> >5520 recommends that a path key be *kept*  for at least ten minutes and
> >indicates that this value is configurable.
> >It also indicates that the purging of path state is simply a house
> >keeping procedure.
> 

[JD]  Actually, you weren't.  According to you, you were quoting from RFC 5553 and as I pointed out, you were incorrect.

As I indicated above, I think the more relevant text from RFC 5520, which clearly indicates that aggressive cache management isn't necessary, is the following:

"The operation of the PKS extensions require that path-keys are retained by the issuing PCE to be available for retrieval by an LSR (acting as a PCC) at a later date.  But it is possible that the
retrieval request will never be made, so good housekeeping requires that a timer is run to discard unwanted path-keys."

> >>route-exclusion-pathkey-00, which requires path info to be saved for
> >>the life of  an LSP (using it).
> >
> >diversely routed LSPs not be established concurrently?  If they are
> >not, it defeats the purpose of having diversely routed LSPs.
> 

[JD]  Um, I think I was the one that suggested this, when critiquing your drafts.  That would be fine too, particularly if it was augmented to compute disjoint paths concurrently.  It also has the nice property of rendering all of your drafts DOA.  Do we have consensus on this?

> 
> >
> >>
> >> Given that Path to "LSPs using the Path" is not stored at (stateless)
> >>PCE, how  would PCE ever be able to purge the Path state? We keep
> >>saying for life time of  the connection but how would PCE know (all)
> >>client(s) has
> >if the path state is purged, and path state can also be invalidated due
> >to depletion of server network resources or changes in server network
> >topology.
> >
> 

[JD]  Hardly, rather I have been making two points.  Diversely routed paths are typically established concurrently so they should not be
affected by aggressive cache management and there is nothing, other than some vague assertions by you, that indicates that aggressive
cache management  is required to scale PCE performance. 

> 
> Speaking of handling changes in server topology. This is another aspect that
> draft-zhang-ccamp-route-exclusion-pathkey-00 does NOT talks about at all. In
> this respect, please note that:
> 
> 1. A PCC that does not have server topology (UNI, which is target case for this
> draft). So it cannot verify Paths or check if diversity is still met.
> 2. A passive PCE can verify Paths and can detect if diversity is still met but
> cannot take action.
> 
> So once draft-zhang-ccamp-route-exclusion-pathkey-00 sets up the service, it
> cannot handle topology changes.

[JD]   A better way to say this is that neither your draft nor this draft solves this problem.  In both drafts, the explicit routes and LSP IDs are available inside the server network but a mechanism is required to distribute this information to the correct PE nodes and neither draft proposes any such mechanism.  I have pointed out this problem in your drafts out to you on numerous occasions but to no effect.