Subject: [CCAMP] subject lines-take note

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

Please, please use appropriate subject lines - this one has totally gone off-track:-)

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Tuesday, February 25, 2014 9:30 AM
To: Daniele Ceccarelli; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

Daniele

Ehm... is defining interfaces in the charter of CCAMP? It seems to me that TE is already in the protocol toolset defined by CCAMP isn't it?

Gert

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]] 
Sent: 25 February 2014 14:23
To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
Cc: Alia Atlas
Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted

First of all I would suggest John to change the name of the interface into PONI (with Igor's authorization) :-)

Secondly, if the FUNI is a CCAMP interface and adding signaling to it makes sense, why not? I think the situation we are facing is a little bit difference.
What we already have is a tool, called UNI, which allows the client domain to blindly ask for a path in server layer.

What we want to do is to have a toolset to make TE in that scenario. 
The good planning plus routing over the interface to advertise precomputed potential paths is great and perfectly works, but we also have use cases that need something more (e.g. diversity re an existing path or adding a path with delay constraints).
Is the other existing tool (i.e. plain UNI) enough? No, we need to add some capabilities to it (already existing in RSVP-TE), this is the UNI with steroids.

Daniele

> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: martedì 25 febbraio 2014 12:07
> To: Daniele Ceccarelli; John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas
> Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Hi Daniele,
> 
> For the sake of the discussion: imagine John Smith would define a FUNI 
> requiring OSPF-TE but disallowing RSVP-TE because he can do 
> provisioning with other means.
> -> From a GMPLS perspective, there is no issue with that FUNI.
> 
> However after few years he comes back and wants extensions to add 
> basic signaling to his routing only approach. Yet he still doesn't 
> like to use RSVP-TE for signaling.
> -> Should that be a good reason for CCAMP to work on signalling 
> -> extensions
> for IGP?
> 
> I'd suggest John to think about whether  his past choice for FUNI is 
> adequate to address his present use case. What would be your 
> suggestion to John?
> 
> Gert
> 
> P.S: my apologies to John Smith who will now be identified as inventor 
> of FUNI, a humble abbreviation of the word FUNnI.
> 
> ________________________________________
> From: Daniele Ceccarelli <[email-masked]>
> Sent: Tuesday, February 25, 2014 10:41:54 AM
> To: Gert Grammel; John E Drake; Lou Berger; Fatai Zhang; CCAMP
> Cc: Alia Atlas
> Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted
> 
> Hi Gert,
> 
> Please see inline
> 
> Ciao
> Daniele
> 
> > -----Original Message-----
> > From: Gert Grammel [mailto:[email-masked]]
> > 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:[email-masked]]
> > 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 
> > GGR> 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 
> > GGR> 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 
> > GGR> 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:[email-masked]] 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:[email-masked]] 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:[email-masked]] 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:[email-masked]] 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
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/ccamp
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > CCAMP mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/ccamp
> > > >
> > >
> > >
> > > _______________________________________________
> > > CCAMP mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
> 
> 
> 

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