Re: [CCAMP] IETF 89 Draft Agenda Posted

[Daniele Ceccarelli <[e-mail]>]

Hi Gert,

Please see inline

Ciao
Daniele

> -----Original Message-----
> From: Gert Grammel [mailto:[e-mail]]
> Sent: martedì 25 febbraio 2014 01:19
> To: Daniele Ceccarelli; John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas
> Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Hi Daniele,
> 
> see below with GGR>
> 
> Gert
> 
> -----Original Message-----
> From: Daniele Ceccarelli [mailto:[e-mail]]
> Sent: 24 February 2014 23:17
> To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas
> Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Gert, (all)
> 
> You're right, and that's why a good planning of the network is fundamental.
> However a "fine tuning" of the network is needed, in all of those cases that
> were not included in the planning phase (e.g. some additional service
> requests that are not enough to justify another planning iteration, e.g.
> extremely dynamic networks where the traffic matrix highly changes in time
> and it is not possible to perform a good planning).
> GGR> Of course a good planning of the Network is fundamental and never
> perfect. Being adaptive is critical, but so far we seem to be in agreement
> anyhow.
> 
> This is why I tend to think that:
> 1. the perfect overlay network both implements the a priori planning of the
> network with potential server layer LSPs *and* the UNI with "steroids".
> GGR> although Olympics are over, I suggest to abstain from steroids
> altogether.

[[DC]] ahahah...right! :)

> 
> 2. The "steroids" are useful, but too many are detrimental: I think that the
> UNI should be augmented with just some path computation constraints (OF ,
> TE bounds and diversity) and the capability of collecting some TE metrics.
> The rest is "gilding the lily" (cit. John). If some many features are needed in
> an overlay network, that the a priori topological info approach is more
> suitable.
> GGR> (OF , TE bounds and diversity) are TE-parameters already available in
> GMPLS. Why do you need to add anything if they are already there and can
> be used?

[[DC]] Well, this is a bit in contradiction with the statement that "UNI is adequate when no TE is needed". If we say that the UNI inherits all the RSVP-TE functionalities (UNI with a lot of steroids), then we say that the UNI widely manages TE. 

> 
> 3. The statement ". If there is no TE needed, UNI/overlay is adequate." Is not
> fully correct for what said above
> GGR> your statements 1+2  seem to support this statement as they are both
> asking for TE extensions - hence they do not fulfil the necessary condition ...
> 
[[DC]] What I'm saying is that TE in the overlay is needed. It can be achieved both with pre-computation of potential paths with TE and with a UNI where the client domain can ask the server domain for the computation and provisioning of a path which meets some TE constraints/requirements.

> 
> BR
> Daniele
> 
> > -----Original Message-----
> > From: CCAMP [mailto:[e-mail]] On Behalf Of Gert
> Grammel
> > Sent: lunedì 24 febbraio 2014 20:38
> > To: John E Drake; Lou Berger; Fatai Zhang; CCAMP
> > Cc: Alia Atlas
> > Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> >
> > Hi John,
> >
> > The real difficulty of those requests starts even earlier, since the
> > requestor (aka. client) doesn't have visibility about what's possible
> > and hence needs to narrow-down in a request-response manner the best
> choice for himself.
> > Imagine a requestor would request 4 connections between A and B. the
> > default choice are: all co-routed or all diverse. If neither of both
> > works, what's next? Asking for 3 diverse routed or joint path and then
> > for a third free routed? Go for two requests with 2 path each? ...
> >
> > An overlay network works well if it is reasonable that the request can
> > be serviced. In a Telephony network with 1:1 connections, good
> > statistics and lots of over-provisioning this can be fulfilled. *If*
> > the network is designed in an A/B structure even a 1+1 protection
> > connectivity can be reasonably requested. However in a client/server
> > network that is not A/B and needs to cover different diversity and
> > resource constraints that's not realistic. It is just like with other
> > TE constraint parameters like Latency. If a client needs to dream up a
> > latency requirement he would probably select the geographic distance,
> > multiply it by speed of light and a rule-of-thumb parameter and ask for it.
> What else could he do?
> >
> > UNI/Overlay is not made for traffic engineering or client controlled
> > redundancy. If TE is important, a-priori topological information is
> > required. If there is no TE needed, UNI/overlay is adequate.
> >
> > Best
> >
> > Gert
> >
> > -----Original Message-----
> > From: CCAMP [mailto:[e-mail]] On Behalf Of John E
> Drake
> > Sent: 24 February 2014 17:08
> > To: Lou Berger; Fatai Zhang; CCAMP
> > Cc: Alia Atlas
> > 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
> > >
> >
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> 
>