Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 6 Feb 2014 20:05:48 +0000

All,

This starts a two-week working group last call on draft-ietf-ccamp-lsp-diversity-03.

This working group last call ends Feb. 20th. Please send your comments to the CCAMP mailing list.

Deborah and Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 6 Feb 2014 20:46:11 +0000

Deborah,

I don't want to see this draft progressed.  Technically, I think the path key approach (http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00) is far superior and as I noted in an email sent on 10/8/13 and copied below for your convenience, this draft has significant technical issues in that it does not specify how a GMPLS network would perform the functions specified in the draft.

Ironically, the authors of the draft explicitly acknowledge this:

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

Yours Irrespectively,

John

=======================================================================================================================================================

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: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, February 06, 2014 12:06 PM
To: [email-masked]
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

Deborah and Lou

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 7 Feb 2014 06:50:34 +0000

Hi Deborah and all，

I think you might have noticed that there is another draft (http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00), which describe a simple solution to address the same requirement as draft-ietf-ccamp-lsp-diversity and there were lots of discussion on the both drafts in the WG list.

In my understanding from the WG discussion, I think many people prefer draft-zhang because it is more straightforward and simple.

The authors of draft-zhang tried to contact the authors of draft-ietf-ccamp-lsp-diversity to discuss how to move forward these drafts, but nothing happened.

Therefore, the guidance from the WG chairs on how to move forward the both drafts (e.g, pick up one of them to go or any other suggestions) would be appreciated.

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, February 07, 2014 4:06 AM
To: [email-masked]
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 7 Feb 2014 15:04:56 +0000

Hi Fatai, John-

We had a long discussion and agreement that draft-zhang-ccamp-route-exclusion-pathkey-00<http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00> requires a PCE that needs to keep state of ALL LSPs it has served (as long as they exists in the network). There is also a scaling issue as it limits number of LSPs PCE can serve. So calling it is "simple" is NOT a correct statement. You solution requires a path-stateful PCE.

Also to note from last IETF meeting minutes: http://www.ietf.org/proceedings/88/minutes/minutes-88-ccamp
Lou Berger: "PCE: operating without the PCE is still in the scope of this WG." Our solution is without the use of PCE (signaling based).

Thanks

Regards … Zafar

From: Fatai Zhang <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2014 1:50 AM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi Deborah and all，

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Friday, February 07, 2014 4:06 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

Deborah and Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 7 Feb 2014 15:51:11 +0000

Zafar,

The conclusion of the long discussion was that your claims, repeated in your email below, regarding the path key draft were simply incorrect.

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 07, 2014 7:05 AM
To: Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 7 Feb 2014 16:47:23 +0000

Hi John-

Only if you deploy a 100-s of PCE (PCE node ID-es) so scaling really becomes a function of number of PCE in the network (this does not fly). Also fact remains the  draft-zhang-ccamp-route-exclusion-pathkey-00<http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00> requires a PCE that needs to keep state of ALL LSPs it has served (as long as they exists in the network). Most of the recent requirements are to deploy a single PCE, which mean the NETWORK can only serve 64K LSPs (PCE Path key is 16 bit), which also does not fly, either.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2014 10:51 AM
To: zali <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Zafar,

Yours Irrespectively,

John

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 07, 2014 7:05 AM
To: Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: John E Drake <[email-masked]>
Date: Fri, 7 Feb 2014 17:12:00 +0000

Zafar,

I don’t feel like rehashing all of this, but as was pointed out to you repeatedly, the reason the key is called a ‘path key’ is that it refers to a path and a path can be used by more than one LSP.  This means that the persistence of a path and its associated path key is not tied to the persistence of an individual LSP.

More importantly, the discussion of the path key draft is beside the point.  It is your draft that is under discussion and it is your draft with which I have problems.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Friday, February 07, 2014 8:47 AM
To: John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: Gert Grammel <[email-masked]>
Date: Sat, 8 Feb 2014 00:08:21 +0000

Hi Deborah,

I don't think we should progress this draft at this point. The WG decided that "operating without the PCE is still in the scope of this WG." .Yet the document doesn't look into this aspect: "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."
How can the WG know that a network operated without a PCE is able to process the signaling and whether the proposed extensions are complete?

So before rushing into protocol extensions, it would be wise to focus on a framework or applicability statement carving out what needs to be added to existing work in IETF for the use case described. This would bring clarity as to whether route calculation and expansion can be performed and how.

Best

Gert

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: 06 February 2014 21:06
To: [email-masked]
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

Deborah and Lou

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 8 Feb 2014 01:19:25 +0000

Hi all,

I agree with Gert.

It seems that the sentence ("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.") implies that something is being standardized for one company's proprietary implementation.

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Saturday, February 08, 2014 8:08 AM
To: BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi Deborah,

Best

Gert

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 8 Feb 2014 21:07:19 +0000

Hi 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. We can add specific clarification text.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 6, 2014 3:46 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Deborah,

I don’t want to see this draft progressed.  Technically, I think the path key approach (http://tools.ietf.org/html/draft-zhang-ccamp-route-exclusion-pathkey-00) is far superior and as I noted in an email sent on 10/8/13 and copied below for your convenience, this draft has significant technical issues in that it does not specify how a GMPLS network would perform the functions specified in the 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.”

Yours Irrespectively,

John

Daniele and Fatai,

Yours Irrespectively,

John

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 8 Feb 2014 22:02:13 +0000

Gert-

Your and John comments were similar. I have already responded the same and can add a scope clarification text to the document.

Thanks

Regards … Zafar

From: Gert Grammel <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2014 7:08 PM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi Deborah,

I don’t think we should progress this draft at this point. The WG decided that "operating without the PCE is still in the scope of this WG." .Yet the document doesn’t look into this aspect: “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.”
How can the WG know that a network operated without a PCE is able to process the signaling and whether the proposed extensions are complete?

Best

Gert

All,

Deborah and Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sun, 9 Feb 2014 15:16:00 +0000

Deborah, CCAMP,

I think it is too early to progress this document.

I would suggest to wait for the framework and use cases documents to be more stable and most of all I would like to see a document called LSP diversity cover all the possible diversity scenarios: with PCE vs without PCE, single homing vs dual homing, etc (this is why I was suggesting to have the fwk and use cases "more stable").

Maybe a merge with draft-fedyk-ccamp-uni-extensions<http://tools.ietf.org/id/draft-fedyk-ccamp-uni-extensions-03.txt> and draft-zhang-ccamp-route-exclusion-pathkey<http://tools.ietf.org/id/draft-zhang-ccamp-route-exclusion-pathkey-00.txt> would make the document much more useful.

BR
Daniele

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: giovedì 6 febbraio 2014 21:06
To: [email-masked]
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

All,

Deborah and Lou

---

From: John E Drake <[email-masked]>
Date: Sun, 9 Feb 2014 20:51:23 +0000

Zafar,

We still need a general solution which both draft-fedyk-ccamp-uni-extensions<http://tools.ietf.org/id/draft-fedyk-ccamp-uni-extensions-03.txt> and draft-zhang-ccamp-route-exclusion-pathkey<http://tools.ietf.org/id/draft-zhang-ccamp-route-exclusion-pathkey-00.txt> appear to provide and they both could also be used in the situation for which you are now claiming your draft was designed.  So, I don't see any reason to progress your draft.

Furthermore, your draft has a fundamental design flaw which is that it uses established LSP state to indirectly reference established path state.  Since there are orders of magnitude more established LSPs than established paths, you have to maintain orders of magnitude more state, and this state needs to be distributed to any node that might be called upon to compute a route or expand a loose route.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Saturday, February 08, 2014 1:07 PM
To: John E Drake; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John:

Thanks

Regards ... Zafar

Deborah,

Yours Irrespectively,

John

Daniele and Fatai,

Yours Irrespectively,

John

All,

Deborah and Lou

---

From: Dieter Beller <[email-masked]>
Date: Mon, 10 Feb 2014 15:16:11 +0100

Hi Daniele, all,

On 09.02.2014 16:16, Daniele Ceccarelli
wrote:

Deborah,
CCAMP,

I
think it is too early to progress this document.

I
would suggest to wait for the framework and use cases
documents to be more stable and most of all I would like to
see a document called LSP diversity cover all the possible
diversity scenarios: with PCE vs without PCE, single homing
vs dual homing, etc (this is why I was suggesting to have
the fwk and use cases “more stable”).

Maybe
a merge with
draft-fedyk-ccamp-uni-extensions
and
draft-zhang-ccamp-route-exclusion-pathkey
would make the document much more useful.

this sounds like a good approach - let's figure out whether we can
find a single solution that is applicable to all the

different lsp diversity use cases. Therefore, I have reservations
moving forward with draft-ietf-ccamp-lsp-diversity-03

independently of the other drafts.

Thanks,

Dieter

BR

Daniele

From:
CCAMP [mailto:[email-masked]]
On Behalf Of BRUNGARD, DEBORAH A

To: [email-masked]

Subject: [CCAMP] WG Last Call on
draft-ietf-ccamp-lsp-diversity-03

All,

This
starts a two-week working group last call on
draft-ietf-ccamp-lsp-diversity-03.

This
working group last call ends Feb. 20th. Please send your
comments to the CCAMP mailing list.

Deborah
and Lou

---

From: Loa Andersson <[email-masked]>
Date: Mon, 10 Feb 2014 22:54:00 +0800

Deborah, CCAMP,

On 2014-02-10 22:16, Dieter Beller wrote:
> Hi Daniele, all,
>
>
> On 09.02.2014 16:16, Daniele Ceccarelli wrote:
>>
>> Deborah, CCAMP,
>>
>> I would suggest to wait for the framework and use cases documents to
>> be more stable and most of all I would like to see a document called
>> LSP diversity cover all the possible diversity scenarios: with PCE vs
>> without PCE, single homing vs dual homing, etc (this is why I was
>> suggesting to have the fwk and use cases “more stable”).
>>
>> Maybe a merge with draft-fedyk-ccamp-uni-extensions
>> <http://tools.ietf.org/id/draft-fedyk-ccamp-uni-extensions-03.txt> and
>> <http://tools.ietf.org/id/draft-zhang-ccamp-route-exclusion-pathkey-00.txt>
> this sounds like a good approach - let's figure out whether we can find
> a single solution that is applicable to all the
> different lsp diversity use cases. Therefore, I have reservations moving
> forward with draft-ietf-ccamp-lsp-diversity-03

Yes, I agree with Daniele and Dieter, first try to figure out if we
have something that we can converge on fall cases.
It is not like draft-ietf-ccamp-lsp-diversity is independent, we should
evaluate it together with the other drafts before we go ahead.

/Loa
>
> Thanks,
> Dieter
>
>> BR
>> Daniele
>>
>> *From:*CCAMP [mailto:[email-masked]] *On Behalf Of *BRUNGARD,
>> DEBORAH A
>> *Sent:* giovedì 6 febbraio 2014 21:06
>> *To:* [email-masked]
>> *Subject:* [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03
>>
>> All,
>>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Feb 2014 15:50:17 +0000

Zafar,

                I think you are making a pretty strong assertion in stating that "recent requirements are
to deploy a single PCE"…

                I would imagine there are many cases where multiple PCEs are used exactly as implied in
using the Path Key - in order to hide details in one routing domain from other routing domains
over which a path is to be established.

                The point I think John was making is that - where it is desirable to protect routing info
about paths - the solution you are suggesting breaks the paradigm.  This is effectively an issue
the minute there is more than one PCE, crossing multiple routing domains.

                One of the reasons for hiding internal information in one routing domain from other
routing domains is about scalability.

                It becomes a scaling issue rather quickly as well, or we wouldn't bother creating routing
domains in real networks.  There is no need to hundreds of PCEs; 5 could probably be enough,
maybe even 3.

--
Eric

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 07, 2014 11:47 AM
To: John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 10 Feb 2014 16:31:35 +0000

Eric-

I was not trying to assert any requirements. I was pointing out that path key based exclusion solution has an scaling problem, which is more severe when you have 1 PCE per domain. Please note that:

1. Tunnel ID is 16 bits (any node in the network may signal 64K tunnels).
2. Path Key is also 16 bits [a given (path stateful) PCE can only keep 64K Path states].

Now as you mentioned a typical network would have 3-5 PCEs, this becomes a scaling issue for the network (e.g., 3*64 K paths for the entire network!).

Thanks

Regards … Zafar

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 10:50 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Zafar,

                I would imagine there are many cases where multiple PCEs are used exactly as implied in
using the Path Key – in order to hide details in one routing domain from other routing domains
over which a path is to be established.

                The point I think John was making is that – where it is desirable to protect routing info
about paths – the solution you are suggesting breaks the paradigm.  This is effectively an issue
the minute there is more than one PCE, crossing multiple routing domains.

--
Eric

From: CCAMP [mailto:[email-masked]] On Behalf Of Zafar Ali (zali)
Sent: Friday, February 07, 2014 11:47 AM
To: John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 10 Feb 2014 16:37:51 +0000

Hi John:

Please see in line.

Thanks

Regards … Zafar

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2014 12:12 PM
To: zali <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Zafar,

One of the attributes of the Path is its ingress and egress end-point addresses. Within a given end-points, only few routes can be used for multiple LSPs. Specifically, if path key: LSP relationship is 1:n, we are dealing with a really low value of n in a typical network. The fact remains given that Path key is 16 bit, draft-zhang-ccamp-route-exclusion-pathkey-00  has serious scaling limitations.

I did not brought draft-zhang-ccamp-route-exclusion-pathkey-00 into this email thread, it was brought in by you.

Yours Irrespectively,

John

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: Eric Gray <[email-masked]>
Date: Mon, 10 Feb 2014 16:40:09 +0000

Zafar,

                Interesting, and confusing at the same time.

                Are you saying that PCE has scalability issues because network size means
there can be more tunnels?  That would seem to be true independent of PCE use.

                Or are you saying that PCE is not scalable because it needs to retain some
state information per path?  That might be one reason to put PCE functionality on a
server, rather than a router.  And it is far better that this state information is kept to
the PCE, rather than being spread around (like goo) to path ingress points.

                Keeping Path Key information at ingress points is far less of a burden on the
ingress devices than keeping the corresponding path information there.

--
Eric

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 11:32 AM
To: Eric Gray; John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03
Importance: High

Eric-

Thanks

Regards … Zafar

Zafar,

--
Eric

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Feb 2014 16:45:37 +0000

Zafar,

I think we’re done here.

Yours Irrespectively,

John

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 8:38 AM
To: John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Hi John:

Please see in line.

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 10 Feb 2014 17:28:08 +0000

Eric-

My comments were very specific to draft-zhang-ccamp-route-exclusion-pathkey-00. What I am saying is:

  *   draft-zhang-ccamp-route-exclusion-pathkey-00 requires a PCE that needs to keep state of ALL LSPs it has served, as long as LSPs exists in the network.
  *   PCE Path key is 16 bit, which presents a scaling issue with the way draft-zhang-ccamp-route-exclusion-pathkey-00 is making the Path Key "stateful".

Thanks

Regards … Zafar

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 10, 2014 11:40 AM
To: zali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Fatai Zhang <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Zafar,

--
Eric

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 11:32 AM
To: Eric Gray; John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]<mailto:[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03
Importance: High

Eric-

Thanks

Regards … Zafar

Zafar,

--
Eric

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 10 Feb 2014 12:58:13 -0500

I also agree with Loa, Dieter, and Daniele, for all of the stated reasons.

Cheers,
Andy

On Mon, Feb 10, 2014 at 9:54 AM, Loa Andersson <[email-masked]> wrote:
>>> suggesting to have the fwk and use cases "more stable").
>>>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 10 Feb 2014 18:39:45 +0000

Dear Deborah, Lou, CCAMP,
I agree with suggestion expressed by Daniele and Dieter. CCAMP WG can ask authors of draft-ietf-ccamp-lsp-diversity , draft-fedyk-ccamp-uni-extensions, draft-zhang-ccamp-route-exclusion-pathkey, and anyone who's interested to contribute to collaborate on Use Case and Requirements document. 

	Regards,
		Greg

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Monday, February 10, 2014 9:58 AM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

Cheers,
Andy

On Mon, Feb 10, 2014 at 9:54 AM, Loa Andersson <[email-masked]> wrote:
>>> LSP diversity cover all the possible diversity scenarios: with PCE 
>>> vs without PCE, single homing vs dual homing, etc (this is why I was 
>>> <http://tools.ietf.org/id/draft-fedyk-ccamp-uni-extensions-03.txt> 
>>> and draft-zhang-ccamp-route-exclusion-pathkey
>>>
>> find a single solution that is applicable to all the different lsp 
>> diversity use cases. Therefore, I have reservations moving forward 
>> with draft-ietf-ccamp-lsp-diversity-03 independently of the other 
>> drafts.
>>
>
> It is not like draft-ietf-ccamp-lsp-diversity is independent, we 
> should evaluate it together with the other drafts before we go ahead.
>
> /Loa
>>
>>
>> Thanks,
>> Dieter
>>
>>> BR
>>> Daniele
>>>
>>> *From:*CCAMP [mailto:[email-masked]] *On Behalf Of 
>>> *BRUNGARD, DEBORAH A

---

From: Mach Chen <[email-masked]>
Date: Tue, 11 Feb 2014 01:23:34 +0000

Hi all,

Follow this thread for a while, I have to agree Daniele, Dieter, Loa, Greg's suggestion. We should postpone the progressing of draft-ietf-ccamp-lsp-diversity. 

Best regards,
Mach

> From: CCAMP [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> Sent: Tuesday, February 11, 2014 2:40 AM
> To: Andrew G. Malis; Loa Andersson
> Cc: [email-masked]
> I agree with suggestion expressed by Daniele and Dieter. CCAMP WG can ask
> authors of draft-ietf-ccamp-lsp-diversity , draft-fedyk-ccamp-uni-extensions,
> draft-zhang-ccamp-route-exclusion-pathkey, and anyone who's interested to
> contribute to collaborate on Use Case and Requirements document.
> 
> 	Regards,
> 		Greg
>

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 11 Feb 2014 02:09:46 +0000

Hi, all,

     For those two issues pointed out below, I have already replied in this thread (http://www.ietf.org/mail-archive/web/ccamp/current/msg15552.html). It is being addressed in the next update of that draft.

    As for the  Last Call on draft-ietf-ccamp-lsp-diversity-03, I have reservation to proceed it at the moment. As for the reason, I concur with Daniele: frther discussions are needed to see how to proceed relevant drafts all together.

Regards,
Xian

Sent: 2014年2月11日 1:28

Eric-

Regards … Zafar

Zafar,

--
Eric

Eric-

Thanks

Regards … Zafar

Zafar,

--
Eric

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 11 Feb 2014 17:27:53 +0000

We are planning to update the use cases draft: http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-04

Inputs on LSP diversity and any other topics of interest are more than welcome.

BR
Daniele

> Sent: lunedì 10 febbraio 2014 19:40

---

From: Eric Gray <[email-masked]>
Date: Fri, 14 Feb 2014 16:25:05 +0000

Zafar,

                I believe you need to take a closer look at the relevant PCE RFCs.

--
Eric

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Monday, February 10, 2014 12:28 PM
To: Eric Gray; John E Drake; Fatai Zhang; BRUNGARD, DEBORAH A; [email-masked]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03
Importance: High

Eric-

Regards … Zafar

Zafar,

--
Eric

Eric-

Thanks

Regards … Zafar

Zafar,

--
Eric

Hi John-

Thanks

Regards … Zafar

Zafar,

Yours Irrespectively,

John

Hi Fatai, John-

Thanks

Regards … Zafar

Hi Deborah and all，

Best Regards

Fatai

All,

Deborah and Lou

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 25 Feb 2014 16:37:52 +0000

This working group last call has ended. It was clear from the comments on the mailing list that there is not support at this time for forwarding this document. We encourage everyone to keep discussing.

Thanks,
Deborah and Lou

From: CCAMP [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A
Sent: Thursday, February 06, 2014 3:06 PM
To: [email-masked]
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lsp-diversity-03

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
All,

Deborah and Lou