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: Monday, February 24, 2014 10:38 AM
> To: John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas; [e-mail]
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Hi John-
> 
> Are you suggesting that an SP shall only provide disjoint service if and only if SP
> know that it needs N disjoint paths ahead of time?

[JD]  I'm sorry but I have no idea what the above sentence means.   To what part of
my email, below, are you referring?

> Please bear in mind that
> there are use cases when a NEW service needs to be disjoint from an EXISTING
> service (without disturbing the EXISTING service).

[JD]  You raise a very good point, viz, the requirements for diversity were not written down
and approved before you started designing away.  Further, your draft says NEXT TO NOTHING
about the use cases for which it was designed.

So, I have no idea what are the required use cases beyond your EMPHATIC ASSERTION, 
above, about which I have doubts.  I.e., it sounds like you mumbling about use cases that
might match your design.

And since we are on the topic of YOUR DESIGN, I have already noted that it has serious
scalability issues, i.e., orders of magnitude more state, relative to the other diversity drafts. 

> 
> Are you also suggesting that an implementation shall only support disjoint
> service if and only if it is supporting the suurballe or similar algorithm?

[JD]  No, what I was pointing out was that it has been known for quite some time that computing
diverse paths sequentially is broken and that we should move to a service model in which diverse
paths can be computed concurrently.

 > If yes,
> may I request the mailing list how many implementations of suurballe
> algorithm exists today (and deployed)? Bear in mind the paper you cited is
> from 1974 and disjoint services are widely deployed.

[JD] It's a classic and the basis for much of the subsequent work on diverse path computation.

> 
> Thanks
> 
> Regards Š Zafar
> 
> 
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Monday, February 24, 2014 11:07 AM
> To: "[e-mail]" <[e-mail]>, Fatai Zhang
> <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: Alia Atlas <[e-mail]>
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> >Hi (and copying Alia and Adrian),
> >
> >I've included Suurballe's original paper for background reading on the
> >subject of computing N node disjoint paths through a network.  The
> >careful reader will note that the N node disjoint paths need to be
> >computed concurrently as otherwise it may not be possible to find
> >disjoint paths.
> >
> >The implication of this is that all of the current proposals, which
> >attempt to find disjoint paths sequentially are fundamentally broken.
> >
> >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.
> >
> >However, this is really a service-level request rather than an LSP
> >establishment request and the while the latter is clearly within
> >CCAMP's charter, I think the former is more in the purview of the PCE
> >working group where a stateful PCE can provide this service, if it
> >doesn't already.
> >
> >In any case, to proceed with any of the current proposals is
> >irresponsible.
> >
> >Yours Irrespectively,
> >
> >John
> >> -----Original Message-----
> >> From: CCAMP [mailto:[e-mail]] On Behalf Of Lou Berger
> >> Sent: Wednesday, February 19, 2014 7:28 AM
> >> To: Fatai Zhang; CCAMP
> >> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> >>
> >> Fatai,
> >> 	Our intent is to have the current WG draft authors propose how they
> >>think the document should move forward based on the WG LC comments.
> >> Given that we are not meeting until Thursday, I'd hope that WG draft
> >>authors  take advantage of this and work/meet with the authors of the
> >>related drafts to  come up with an approach that is inclusive of the
> >>issues and alternatives  mentioned.
> >>
> >> Lou
> >>
> >> On 2/18/2014 10:39 PM, Fatai Zhang wrote:
> >> > Hi Lou,
> >> >
> >> > Do you think if it is better to put presentation #4,#12,#13 close
> >>(ie., treat
> >> them as a group topic like diversity route)?
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Best Regards
> >> >
> >> > Fatai
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: CCAMP [mailto:[e-mail]] On Behalf Of Lou Berger
> >> > Sent: Tuesday, February 18, 2014 5:58 AM
> >> > To: CCAMP
> >> > Subject: [CCAMP] IETF 89 Draft Agenda Posted
> >> >
> >> >
> >> > All,
> >> > 	The draft agenda for London was posted earlier today at:
> >> > http://www.ietf.org/proceedings/89/agenda/agenda-89-ccamp
> >> >
> >> > Please let us (Daniele & chairs) know if you have comments or if we
> >> > missed anything.
> >> >
> >> > Authors of WG documents,
> >> >
> >> > As usual:
> >> >
> >> > If presenting, please plan to review (present) any changes that
> >> > have been recently made, any open discussions or issues, as well as
> >> > planned next steps.
> >> >
> >> > If you are not presenting, please send this information to the WG
> >> > mail list *1 week* prior to the WG meeting.
> >> >
> >> > Much thanks,
> >> > Lou, Deborah (& Daniele)
> >> >
> >> > _______________________________________________
> >> > CCAMP mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ccamp
> >> >
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> CCAMP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >>
> >
> 
>