Re: [CCAMP] IETF 89 Draft Agenda Posted

[John E Drake <[e-mail]>]

Zafar,

Comments inline.

Yours Irrespectively,

John

> -----Original Message-----
> From: Zafar Ali (zali) [mailto:[e-mail]]
> Sent: Tuesday, February 25, 2014 10:01 AM
> To: John E Drake; Fatai Zhang; Daniele Ceccarelli; Gert Grammel; Lou Berger;
> CCAMP
> Cc: Alia Atlas
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Hi John-
> 
> Please see in-line.
> 
> Thanks
> 
> Regards Š Zafar
> 
> 
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Tuesday, February 25, 2014 7:14 AM
> To: Fatai Zhang <[e-mail]>, Daniele Ceccarelli
> <[e-mail]>, Gert Grammel <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> Cc: Alia Atlas <[e-mail]>
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> >Fatai,
> >
> >Comments inline.
> >
> >Yours Irrespectively,
> >
> >John
> >
> >> -----Original Message-----
> >> From: Fatai Zhang [mailto:[e-mail]]
> >> Sent: Tuesday, February 25, 2014 2:16 AM
> >> To: Daniele Ceccarelli; Gert Grammel; John E Drake; Lou Berger; CCAMP
> >> Cc: Alia Atlas
> >> Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted
> >>
> >> Hi all,
> >>
> >> I think the network planning (including N node disjoint paths
> >> computed
> >> concurrently) is very important (we all agree),
> >
> >[JD]  Concurrent disjoint path computation is not a network planning
> >function.  Rather, it is a real-time service offered by the provider
> >network
> >
> >> but it is also very important and
> >> valuable to find disjoint paths sequentially. e.g, a path without
> >>protection  needs to be upgraded to 1:1 or 1+1 protection, in this
> >>case, it needs to exclude  the existing path during path setup
> >>process. Another example from Zafar, a  new service maybe needs to be
> >>disjoint from an existing one based on the  management purpose.
> >
> >[JD]  This is the point I made yesterday.  We have a multiplicity of
> >solutions but we don't have an agreed upon set of diversity uses cases.
> 
> Daniele, et al can keep me honest here.
> 
> 
> draft-ceccadedios-ccamp-overlay-use-cases has a section on it. There is also
> some text which was not incorporated due to deadline pressure. Plan is to
> have draft-ceccadedios-ccamp-overlay-use-cases-05 published in IETF week.

[JD]  What part of "...  but we don't have an agreed upon set of diversity uses cases" do you not understand?  Generally we agree on requirements before we start on solutions.

Furthermore the discussion in this draft of LSP diversity is couched in terms of a particular solution, sequential path computation, rather than in terms of requirements.

> 
> >In your example, I could see requesting disjoint paths initially but
> >establishing them sequentially, separated by an arbitrary time interval.
> 
> Only if SP know that diversity is required at the time service(s) is(are) created.
> E.g., when service X was created at time t0, it was not known that a service Y
> will be deployed at time t1, requiring the diversity.
> Same for upgrade of unprotected service to protected service use case Fatai
> mentioned.

[JD]  No, that's not correct.  The customer would request diverse paths at t0 and instantiate one of the diverse LSPs immediately and the other some time later.      

> 
> Even when all diversity requirements are known at t0, where do you propose
> to run the concurrent Path computation? Please take your favorite example of
> remote dual homed UNI (Fig. 5 in draft-ceccadedios-ccamp-overlay-use-cases).

[JD]   From my email yesterday:  "If we want to get N node disjoint paths across, I think we need to define a new service in which the ingress CE sends the ingress PE a request containing a destination (egress) CE, the number of disjoint paths N, and a list of its attachment circuits to be considered in the request.  What it receives in exchange is a list of [attachment circuit, path keys] which it then can include in a set of Path messages that it sends to the provider network."


> 
> ><snip>
> 
>