Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

From: John E Drake <[email-masked]>
Date: Wed, 2 Oct 2013 18:26:34 +0000

HI,

I was reading:   http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include_text=1, and I happened to notice the following paragraph:

"The means by which the node calculating or expanding the route of the signaled LSP discovers the route of the path(s) from which the signaled LSP
 requires diversity are beyond the scope of this document. "

Doesn't this disclaimer effectively render this draft useless?  The draft also does not define how the node that initially signaled the LSP finds the 'node calculating
or expanding the route'  nor how it delivers the signaled LSP request to that node.

As an aside, the draft:  http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/?include_text=1 would be subject to the same criticism
except that the above quoted paragraph is replaced with:

"The above-mentioned use cases require relevant path inclusion requirements to be communicated to the route expanding nodes.  This document addresses
 these requirements and defines procedures to address them." 

Even though this is helpful, the draft doesn't actually define these procedures.

Yours Irrespectively,

John

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 8 Oct 2013 07:01:33 +0000

Hi John,

Totally agree with you, I already found these two drafts are much *useless*. 

This is why we made a new draft (very simple and useful) and put our feet on the ground. 

http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-pathkey-00.txt

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, October 03, 2013 2:27 AM
To: CCAMP ([email-masked])
Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

HI,

Yours Irrespectively,

John

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 8 Oct 2013 16:32:24 +0000

Thanks John for pointing that out. When I first read the draft I missed that point.

I see two differences between the two drafts:
1. utilization of 5ple vs Path key
2. The path diversity draft does not say how to collect the 5ple (which in some cases could not be available at all), the path key draft covers this aspect also

Re 1 I have a moderate preference for the path key for the security reasons that lead to the definition of the Path Key years ago and secondly it's simpler.
Re 2 I don't know how the WG will manage the issue of two competing drafts (one wg, the other individual) but in any case it's an issue that need to be fixed somehow.

BR
Daniele

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fatai Zhang
> Sent: martedì 8 ottobre 2013 09:02
> To: John E Drake; CCAMP ([email-masked])
> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> (RSVP-TE) Path Diversity using Exclude Routes
> 
> Hi John,
> 
> I was reading:   http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-
> diversity/?include_text=1, and I happened to notice the following paragraph:
> 
> "The means by which the node calculating or expanding the route of the
> signaled LSP discovers the route of the path(s) from which the signaled LSP
> Doesn't this disclaimer effectively render this draft useless?  The draft also
> does not define how the node that initially signaled the LSP finds the 'node
> calculating or expanding the route'  nor how it delivers the signaled LSP
> request to that node.
> 
> As an aside, the draft:  http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-
> te-include-route/?include_text=1 would be subject to the same criticism
> "The above-mentioned use cases require relevant path inclusion
> requirements to be communicated to the route expanding nodes.  This
> document addresses  these requirements and defines procedures to
> address them."
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 8 Oct 2013 17:47:23 +0000

Fatai and all- 

In a stateless PCE, Path Keys are transient and they expire. For this
solution to work you need a PCE that can keep Paths associated with a Path
Key around (a stateful PCE where states are path computed by the PCE).

Thanks

Regards Š Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Tuesday, October 8, 2013 3:01 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>

>Subject: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
>I was reading:   
>http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include_te
>xt=1, and I happened to notice the following paragraph:
>
>Doesn't this disclaimer effectively render this draft useless?  The draft
>also does not define how the node that initially signaled the LSP finds
>the 'node calculating
>As an aside, the draft:
>http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/?inc
>lude_text=1 would be subject to the same criticism
>document addresses

---

From: John E Drake <[email-masked]>
Date: Tue, 8 Oct 2013 22:26:13 +0000

Zafar,

So, is your assertion that RFC5553 is broken?

Yours Irrespectively,

John

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 10:47 AM
> To: Fatai Zhang; John E Drake; CCAMP ([email-masked])
> In a stateless PCE, Path Keys are transient and they expire. For this solution
> to work you need a PCE that can keep Paths associated with a Path Key
> around (a stateful PCE where states are path computed by the PCE).
> 
> Thanks
> 
> Regards Š Zafar
> 
> 
> >http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion-p
> >ath
> >key-00.txt
> >
> >
> >
> >
> >Best Regards
> >
> >Fatai
> >
> >
> >Of John E Drake
> >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?include
> >_te xt=1, and I happened to notice the following paragraph:
> >
> >signaled LSP discovers the route of the path(s) from which the signaled
> >LSP  requires diversity are beyond the scope of this document. "
> >
> >Doesn't this disclaimer effectively render this draft useless?  The
> >draft also does not define how the node that initially signaled the LSP
> >finds the 'node calculating or expanding the route'  nor how it
> >delivers the signaled LSP request to that node.
> >
> >As an aside, the draft:
> >lude_text=1 would be subject to the same criticism except that the
> >above quoted paragraph is replaced with:
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 8 Oct 2013 22:38:47 +0000

Daniele and Fatai,

I have been thinking some more about Zafar's Exclude/Include drafts and I have the following observations.

Let's assume that the ingress node has the RSVP-TE explicit route and identifier for a given LSP from which it wishes to have a subsequent LSP be disjointly routed (exclude route) or be identically routed (include route).

For either full or partial exclude route, where partial exclude route means a disjoint route across one or more abstract nodes, the ingress node can compute a route that is disjoint from the route of the given LSP.  (However, it is not guaranteed that a disjoint route can be found.  The Suurballe algorithm computes disjoint routes *in pairs* and will find disjoint routes if they exist.) In order to allow the ingress node at the edge of an abstract node to expand the explicit route and provide a disjoint route will require that each such ingress node has complete knowledge of the RSVP-TE explicit route and identifier of every LSP transiting that abstract node.

For full include route the ingress node can simply re-use the explicit route from the selected LSP.   For partial include path, where partial include path means an identical route across one or more abstract nodes, it can simply re-use the [ingress node, abstract node] tuple for the subject abstract node.

Let's now assume that the ingress node has the RSVP-TE identifier for the given LSP but not the explicit route.  This is the UNI case, and if the ingress node is single homed then the ingress PE can act on the ingress node's behalf as described above.

If however, the ingress node is multi-homed then this will require that each of the ingress PEs know the complete set of ingress PEs serving the ingress node and each has the RSVP-TE explicit route and identifier for the given LSP.  This allows each ingress PE to act on the ingress node's behalf as described above.  

The net of all this that there needs to be a lot of distributed and coordinated state maintained in the server network and that neither Zafar nor any of his co-authors has proposed a method for accomplishing this.

Yours Irrespectively,

John

> From: Daniele Ceccarelli [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 9:32 AM
> Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> 2. The path diversity draft does not say how to collect the 5ple (which in
> some cases could not be available at all), the path key draft covers this aspect
> also
> 
> Re 1 I have a moderate preference for the path key for the security reasons
> that lead to the definition of the Path Key years ago and secondly it's simpler.
> Re 2 I don't know how the WG will manage the issue of two competing drafts
> (one wg, the other individual) but in any case it's an issue that need to be
> fixed somehow.
> 
> BR
> Daniele
> 
> > signaled LSP discovers the route of the path(s) from which the
> > signaled LSP requires diversity are beyond the scope of this document. "
> >
> > draft also does not define how the node that initially signaled the
> > LSP finds the 'node calculating or expanding the route'  nor how it
> > http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-
> > te-include-route/?include_text=1 would be subject to the same
> > criticism except that the above quoted paragraph is replaced with:
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 8 Oct 2013 22:40:26 +0000

And a very nice draft it is.

Yours Irrespectively,

John

> From: Fatai Zhang [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 12:02 AM

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 9 Oct 2013 01:17:55 +0000

Hi Daniele,

I don't think your point 2 is an issue. 

If the WG realize that a WG document is *useless*, I think the WG document should stop there and let it die (ie., I don't think a WG document have preference to lead the WG to the wrong direction if this WG document is nothing but wrong). 

Best Regards

Fatai

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 12:32 AM
To: Fatai Zhang; John E Drake; CCAMP ([email-masked])
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

BR
Daniele

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 05:26:06 +0000

Hi John: 

No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed by
draft-zhang-ccamp-route-exclusion-pathkey-00.txt forces customers to
deploy a stateful PCE where PCE need to remember path it has served for
indefinite time. 

Thanks

Regards ... Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, October 8, 2013 6:26 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>>solution

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 05:37:21 +0000

Daniele: 

The main difference between the drafts is that one is RSVP-TE signaling
based solution, while the other forces customers to deploy stateful PCE.
Calling a RSVP-TE based signaling solution that is a WG document "useless"
to force a "stateful" PCE based solution/ architecture to service
providers is very inappropriate.

Thanks

Regards Š Zafar

-----Original Message-----
From: Daniele Ceccarelli <[email-masked]>
Date: Tuesday, October 8, 2013 12:32 PM
To: Fatai Zhang <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>2. The path diversity draft does not say how to collect the 5ple (which
>in some cases could not be available at all), the path key draft covers
>this aspect also
>
>Re 1 I have a moderate preference for the path key for the security
>reasons that lead to the definition of the Path Key years ago and
>secondly it's simpler.
>Re 2 I don't know how the WG will manage the issue of two competing
>drafts (one wg, the other individual) but in any case it's an issue that
>need to be fixed somehow.
>
>BR
>Daniele
>
>> This is why we made a new draft (very simple and useful) and put our
>>feet on
>> the ground.
>> 
>>LSP
>>draft also

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 9 Oct 2013 06:02:05 +0000

Hi, Zafar, 
    
    Thank you for sharing the thoughts. But I cannot agree with what you said below. 

    Path key solution does not necessarily need the presence of a stateful PCE. Similarly with RFC5553, the path key owner needs to retain this information so that I can interpret when used at a later time. Retaining such information does not equal to a stateful PCE which needs to know the LSP states of the whole network it serves. 

Regards,
Xian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: 2013年10月9日 13:26
To: John E Drake; Fatai Zhang; CCAMP ([email-masked])
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Hi John: 

Thanks

Regards ... Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Tuesday, October 8, 2013 6:26 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>,

>> >feet on the ground.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 06:06:43 +0000

Hi Zhangxian: 

State does not always means RSVP TE states in the network. PCE (sever)
needs to remember path information (possibly with other path attributes)
it computed for indefinite time. These are states that PCE needs to
remember. Hence, stateful PCE.

Thanks

Regards … Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Wednesday, October 9, 2013 2:02 AM
To: zali <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Fatai Zhang
<[email-masked]>

>    Path key solution does not necessarily need the presence of a
>stateful PCE. Similarly with RFC5553, the path key owner needs to retain
>this information so that I can interpret when used at a later time.
>Retaining such information does not equal to a stateful PCE which needs
>to know the LSP states of the whole network it serves.
>
>Regards,
>Xian
>
>>>signaled

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 9 Oct 2013 06:09:06 +0000

Hi, Zafar,

   What I understand is quite the opposite. In the "RSVP-TE signaling based solution" you mentioned below, which entity will be able to understand the LSP identifiers and translate it to a node/link list? IMHO, only a stateful PCE can do so. Isn't that the case?

Regards,
Xian 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: 2013年10月9日 13:37
To: Daniele Ceccarelli; Fatai Zhang; John E Drake; CCAMP ([email-masked])
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Daniele: 

Thanks

Regards Š Zafar

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 9 Oct 2013 06:12:04 +0000

Hi Zafar,

Really interesting for your assertion. 

Did you mean that RFC 5520 is specific for stateful PCE? 

In additon, please look at "Control of Function through Configuration and Policy" of RFC 5520 and RFC5553. 

Best Regards

Fatai

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 2:07 PM
To: Zhangxian (Xian); CCAMP ([email-masked])
Cc: John E Drake; Fatai Zhang
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Hi Zhangxian: 

Thanks

Regards … Zafar

-----Original Message-----
From: "Zhangxian   (Xian)" <[email-masked]>
Date: Wednesday, October 9, 2013 2:02 AM
To: zali <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Fatai Zhang
<[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 06:49:51 +0000

Fatai- 

In RFC 5520 and RFC5553, PCE is only expected to keep the (path key, Path
info) state for only a short amount of time. Time that is required to
signal an LSP provides an upper bound on the time the (path key, Path
info) state needs to be stored by the PCE. The RFC5520 specifically talks
about path key expiration and is purged. 16 bit path keys are used as
reuse of the path key is assumed.

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.

Thanks

Regards … Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Wednesday, October 9, 2013 2:12 AM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>>>>>http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-route/
>>>>>?
>>>> >inc

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Wed, 9 Oct 2013 07:21:22 +0000

Hi Zafar, 

In my understanding the PKS draft does not require any stateful PCE capability, only a PKS resolution capability.
Could you detail why you see stateful a requierement?

Mit freundlichen Grüßen / Best Regards
Cyril Margaria

> Sent: Wednesday, October 09, 2013 7:37 AM
> The main difference between the drafts is that one is RSVP-TE signaling based
> solution, while the other forces customers to deploy stateful PCE.
> to force a "stateful" PCE based solution/ architecture to service providers is
> very inappropriate.
> 
> Thanks
> 
> Regards Š Zafar
> 
> 
> >drafts (one wg, the other individual) but in any case it's an issue
> >that need to be fixed somehow.
> >
> >BR
> >Daniele
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Fatai Zhang
> >> http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-exclusion
> >> -
> >> pathkey-00.txt
> >>
> >>
> >>
> >>
> >> Best Regards
> >>
> >> Fatai
> >>
> >>
> >> "The means by which the node calculating or expanding the route of
> >>the  signaled LSP discovers the route of the path(s) from which the

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 9 Oct 2013 07:23:31 +0000

Hi Zafar,

This is operator's policy, and timer can help as what RFC5520 and RFC 5553 defined.

I really don't want to spend my time on discussing the terminology or philosophy (on what is stateful PCE), but I more care about how your draft can work. 

Could you clarify John's question below (it is also my question)? 
How does your draft work in the real implementation? Who can interpret the *LSP identifier* (5ple) defined in your draft? 

==============================================================================================================================
>>"The means by which the node calculating or expanding the route of the signaled LSP discovers the route of the path(s) from which the signaled LSP requires diversity are beyond the scope 
>>of this document. " 

>>Doesn't this disclaimer effectively render this draft useless? The draft also does not define how the node that initially signaled the LSP finds the 'node calculating or expanding the route'  
>>nor how it delivers the signaled LSP request to that node.

Best Regards

Fatai

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]] 
Sent: Wednesday, October 09, 2013 2:50 PM
To: Fatai Zhang; Zhangxian (Xian); CCAMP ([email-masked])
Cc: John E Drake
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Fatai- 

Thanks

Regards … Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Wednesday, October 9, 2013 2:12 AM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>,

>>>> Behalf
>>>>the

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 07:53:34 +0000

Fatai and John: 

In most of the cases, when the UNI-N node computing the path is also
hosting the RSVP-TE FEC against which exclusion is required, it knows the
path take by the other LSP. For the other cases, please note that just
because optical network is running GMPLS UNI for client interface does not
mean that it is running RSVP-TE for the optical trail management. E.g.,
optical trail management can still using an already deployed proprietary
mechanisms or an NMS based scheme. The draft is addressing schemes that
are capable of this functionality.

Fatai: 

Need for the path keys in XRO scheme requiring PCE to remember the (path
key, path info) "states" for "indefinite" time and scaling restriction of
the solution I mentioned in my email is not a matter of terminology or
philosophy. You are introducing new permanent states at PCE.

Thanks

Regards … Zafar

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Wednesday, October 9, 2013 3:23 AM
To: zali <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>,

>I really don't want to spend my time on discussing the terminology or
>philosophy (on what is stateful PCE), but I more care about how your
>draft can work. 
>
>How does your draft work in the real implementation? Who can interpret
>the *LSP identifier* (5ple) defined in your draft?
>
>==========================================================================
>====================================================
>>>finds the 'node calculating or expanding the route'
>>>Of
>>>Zafar Ali (zali)
>>>>>>p
>>>>>>http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?inclu
>>>>>>d
>>>>>>e

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 9 Oct 2013 15:13:51 +0000

Hi Zafar,

That's one of the reasons why I prefer the path key approach with the path stateful PCE (or whatever we call it, I don't care).
In this example, where R are the routers and O the optical nodes how does the LSP diversity mechanisms work?

                   UNI                                  UNI
R1 --- R2 -------O1----O2----O3-----R4----R5
      \                       |          |           |                  /
        \ R3 -------O4-----O5----O6-----R6 /
                  UNI                                   UNI

In the case of LSP diversity the only way i understand things can work is.
1. I setup a working path R1-R2-O1-O2-O3-R4-R5. 
2. R1 somehow collects the 5ple of LSP O1-O2-O3
3. R1 wants to setup a protection path in diversity and asks R3 to ask O4 for a path in diversity re the 5ple of O1-02-03
4. how can O4 resolve that the nodes/link corresponding to the 5ple are O1-O2-O3? It is not possible. The only way is a hop by hop check with cranckback if the signaling generated from O4 goes through a node among O1-O2-O3.

If there are no RSVP states in the nodes, how can it work? The path key should work in that case.

Please correct any mistake in the procedure I wrote above (btw a procedure, even in example or appendix, in your draft could be helpful)

Thanks
Daniele

> Of Zafar Ali (zali)
> Sent: mercoledì 9 ottobre 2013 09:54
> mean that it is running RSVP-TE for the optical trail management. E.g., optical
> trail management can still using an already deployed proprietary mechanisms
> or an NMS based scheme. The draft is addressing schemes that are capable
> of this functionality.
> 
> Fatai:
> 
> key, path info) "states" for "indefinite" time and scaling restriction of the
> solution I mentioned in my email is not a matter of terminology or
> >=========================================================
> ==============
> >=== ====================================================
> >>>LSP finds the 'node calculating or expanding the route'
> >info) state needs to be stored by the PCE. The RFC5520 specifically
> >talks about path key expiration and is purged. 16 bit path keys are
> >used as reuse of the path key is assumed.
> >
> >but it is stateful. Also, the solution is not scalable as a PCE can
> >only hold 64K of (path key, path info) states.
> >
> >Thanks
> >
> >Regards … Zafar
> >
> >
> >>needs to remember path information (possibly with other path
> >>attributes) it computed for indefinite time. These are states that PCE
> >>needs to remember. Hence, stateful PCE.
> >>
> >>Thanks
> >>
> >>Regards … Zafar
> >>
> >>
> >>>stateful PCE. Similarly with RFC5553, the path key owner needs to
> >>>retain this information so that I can interpret when used at a later time.
> >>>Retaining such information does not equal to a stateful PCE which
> >>>needs to know the LSP states of the whole network it serves.
> >>>
> >>>Regards,
> >>>Xian
> >>>
> >>>Behalf Of Zafar Ali (zali)
> >>>Sent: 2013年10月9日 13:26
> >>>No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed
> >>>by draft-zhang-ccamp-route-exclusion-pathkey-00.txt forces customers
> >>>to deploy a stateful PCE where PCE need to remember path it has
> >>>served for indefinite time.
> >>>
> >>>Thanks
> >>>
> >>>Regards ... Zafar
> >>>
> >>>
> >>>>> In a stateless PCE, Path Keys are transient and they expire. For
> >>>>>this solution  to work you need a PCE that can keep Paths
> >>>>>associated with a Path Key  around (a stateful PCE where states are
> >>>>>path computed by the PCE).
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Regards Š Zafar
> >>>>>
> >>>>>
> >>>>>>http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-
> exclus
> >>>>>>ion
> >>>>>>-
> >>>>>>p
> >>>>> >ath
> >>>>> >key-00.txt
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >Best Regards
> >>>>> >
> >>>>> >Fatai
> >>>>> >
> >>>>> >
> >>>>> >Doesn't this disclaimer effectively render this draft useless?
> >>>>> >The draft also does not define how the node that initially
> >>>>> >signaled the
> >>>>>LSP
> >>>>>>http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-ro
> >>>>>>ute
> >>>>>>/
> >>>>>>?
> >>>>> >inc
> >>>>> >lude_text=1 would be subject to the same criticism except that
> >>>>> >the above quoted paragraph is replaced with:
> >>>>> >
> >>>>> >requirements to be communicated to the route expanding nodes.
> >>>>> >This document addresses  these requirements and defines
> >>>>> >procedures to address them."
> >>>>> >

---

From: John E Drake <[email-masked]>
Date: Wed, 9 Oct 2013 19:05:21 +0000

Zafar,

This sounds like nonsense.

Yours Irrespectively,

John

> Sent: Tuesday, October 08, 2013 10:26 PM
> No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed by draft-
> zhang-ccamp-route-exclusion-pathkey-00.txt forces customers to deploy a
> stateful PCE where PCE need to remember path it has served for indefinite
> time.
> 
> Thanks
> 
> Regards ... Zafar
> 
> 
> >>solution  to work you need a PCE that can keep Paths associated with a
> >>Path Key  around (a stateful PCE where states are path computed by the
> >>PCE).
> >>
> >> Thanks
> >>
> >> Regards Š Zafar
> >>
> >>
> >> >http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?incl
> >> >ude _te xt=1, and I happened to notice the following paragraph:
> >> >

---

From: John E Drake <[email-masked]>
Date: Wed, 9 Oct 2013 19:06:35 +0000

Exactly.

Yours Irrespectively,

John

> From: Zhangxian (Xian) [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2013 11:02 PM
> To: Zafar Ali (zali); CCAMP ([email-masked])
>     Path key solution does not necessarily need the presence of a stateful PCE.
> Similarly with RFC5553, the path key owner needs to retain this information
> so that I can interpret when used at a later time. Retaining such information
> does not equal to a stateful PCE which needs to know the LSP states of the
> whole network it serves.
> 
> Regards,
> Xian
>

---

From: John E Drake <[email-masked]>
Date: Wed, 9 Oct 2013 19:14:03 +0000

Zafar,

Snipped, comment inline.

Yours Irrespectively,

John

> Sent: Wednesday, October 09, 2013 12:54 AM

[JD]  So, you are finally admitting that despite what your draft currently states, your draft only works
If the server network is controlled by a single omniscient entity.  As I said before, this is useless.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 9 Oct 2013 22:04:18 +0000

John: 

Scope of the draft is to define UNI-C and the problem you are hanged on
beyond the scope of UNI-C and that aspect is clear stated in the draft.
Furthermore, I cited two deployment use cases one of which is based on
distributed path computation and other does not require single omniscient
entity.  

Thanks

Regards Š Zafar

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, October 9, 2013 3:14 PM
To: zali <[email-masked]>, Fatai Zhang <[email-masked]>, "Zhangxian
(Xian)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Path Diversity using Exclude Routes

>>optical

---

From: John E Drake <[email-masked]>
Date: Thu, 10 Oct 2013 16:58:17 +0000

Zafar,

Comments inline.

Yours Irrespectively,

John

> Sent: Wednesday, October 09, 2013 3:04 PM
> To: John E Drake; Fatai Zhang; Zhangxian (Xian); CCAMP ([email-masked])

[JD]  This is incorrect.  You go to great pains to claim that your draft has general applicability and is not restricted only to UNI.

> distributed path computation and other does not require single omniscient

[JD]  As I noted in the email I sent on Tuesday:  "In order to allow the ingress node at the edge of an abstract node to expand the explicit route and provide a disjoint route will require that each such ingress node has complete knowledge of the RSVP-TE explicit route and identifier of every LSP transiting that abstract node."

For you consideration:

Com.nis.cient (m-nshnt)
adj.
Having total knowledge; knowing everything: an omniscient deity; the omniscient narrator.
n.
1. One having total knowledge.

> "Zhangxian (Xian)" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> >>hosting the RSVP-TE FEC against which exclusion is required, it knows
> >>the  path take by the other LSP. For the other cases, please note that
> >>just  because optical network is running GMPLS UNI for client
> >>interface does not  mean that it is running RSVP-TE for the optical
> >>trail management. E.g., optical  trail management can still using an
> >>already deployed proprietary mechanisms  or an NMS based scheme. The
> >>draft is addressing schemes that are capable  of this functionality.
> >
> >[JD]  So, you are finally admitting that despite what your draft
> >currently states, your draft only works If the server network is
> >controlled by a single omniscient entity.  As I said before, this is
> >useless.
> >
> 
>