RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

["Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>]

Hi Adrian,

Some more questions in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Sunday, July 23, 2006 10:19 AM
> To: Mack-Crane, T. Benjamin
> Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
> 
> Hi Ben,
> 
> Thanks. These questions give us something to chew on.
> 
...snip...
>> Do the ingress and egress nodes terminate the LSP to be setup?
>
> Yes, indeed. Rooted in RFC3031, section 3.15.

Does the "link between the network and the egress node" connect directly
to the egress node?

> > How is the "link between the network and the egress node"
> > determined?
> 
> Good question. Clearly if there is only one such link, we are done. In
the
> case of a "dual-homed" egress, the Link Capability object may report
on
> more than one link. 

From your answer it is still not clear HOW the link is determined.  Is
it assumed that the link (or set of links) is directly identified by the
destination of the call? 

> This is, perhaps not abundantly clear, but it is covered by
> the final paragraph of section 5.3.
> 
>    This object MAY also be used to exchange more than one bundled link
>    capability. In this case, the following ordering MUST be followed:
>    one identifier subobject (Type 1, 2 or 4) MUST be inserted before
any
>    capability subobject (Type 64 or 65) to which it refers.

Does the term "bundled link" used here have any relation to the term
"bundled link" defined in RFC 4201?

> 
> >   This information may allow the ingress node to tailor its LSP
request
> >   to fit those capabilities and to better utilize network resources
> >   with regard to those capabilities.
> >
> > Generally an LSP setup request is generated by a network operator,
who
> > has a particular purpose in mind.  What leeway does the ingress LSR
have
> > to modify this request?
> 
> I think that this is the difference between LSPs under the parentage
of a
> Call, and LSPs directly controlled by the operator.
> When an operator requests an LSP directly, you are quite right that
there
> is
> no scope for the LSR (i.e. the connection controller) to vary the
request
> for the LSP.
> However, when an operator requests a service, the service is converted
> into
> one or more LSP requests. A good example of this might be VCAT.
> So, when an operator requests a service and a Call is used to
coordinate
> the
> end points, the Call Controller has some leeway about what Connections
> (LSPs) it instantiates to satisfy the call.
> 
> > Generally networks work best when there are uniform means of
> > providing connectivity between clients of the network.  What
> > kinds of "tailoring" are envisioned?
> 
> I think that the VCAT example is the best. The ingress may have the
> ability
> to generate a whole pile of signals, but the egress may only have the
> ability to terminate a limited set of signals.
> You might regard this as choosing between sub-layers, I suppose.

A functional model would help here.  Are you saying that the ingress (i)
can generate different LSP types (i.e., different layer network
technologies) or (ii) can generate a different number of signals (e.g.,
as in VCAT) or (iii) that the ingress offers different adaptations from
a client to the LSP(s)?

> 
> >  In particular, this may be used to achieve end-to-end spectral
> >  routing attribute negotiation for signal quality negotiation (such
as
> >  BER) in photonic environments where network edges are signal
> >  regeneration capable. Similarly, it may be used to provide
end-to-end
> >  spatial routing attribute negotiation in multi-area routing
> >  environments, in particular, when TE links have been bundled based
on
> >  technology specific attributes.
> >
> >What is "end-to-end spectral routing attribute negotiation"?
> 
> It is a completely ridiculous and over-florid way of saying
"end-to-end
> lambda negotiation for use in transparent optical networks".

OK, but what egress link information is used by the ingress in this
case?

> 
> >What is "end-to-end spatial routing attribute negotiation"?
> 
> Similarly poor choice of words for "end-to-end port negotiation for
use in
> fiber switching networks".

OK, again what egress link information is used by the ingress in this
case?

> 
> Thanks for flagging these.
> 
> >  Call setup may provide a suitable mechanism to exchange information
> >   for this purpose, although several other possibilities exist.
> >
> > Just because a mechanism can be defined does not mean that it should
be.
> > Why is it necessary to define this mechanism, and add complexity to
call
> > control, if another mechanism is required to do the same thing in
cases
> > where call control is not used?
> 
> Hmmm.
> Well that is a good question.
> 
> I guess the answer is:
> Because the Call control mechanism a good one where this type of
> information
> (i.e. access connectivity information such as access addressing) is
often
> exchanged.

What is "access addressing"?  Can you give an example use case?

> Maybe more important are:
> - this mechanism is one that several implementers want to /  have
>   implemented.

OK, but why?  There ought to be an explainable technical reason.

> - no-one raised any concerns about this mechanism during a
>   couple of years of discussion of this process and during WG
>   last call.

Was there discussion of the technical reasons for this feature on the
mailing list?  If you can provide a pointer I can look at the reasons
put forth there.  (BTW, I raised this concern during working group last
call;-)

> It is possible that this is not the best way of achieving this
(although
> it
> is my favourite), but if other mechanisms exist then (as Yakov fondly
> says)
> the market will decide which is the best mechanism.

If other mechanisms must exist, and these can also be used in the cases
covered by this draft, then adding this mechanism doesn't really help.

If you could give an example showing where this mechanism is needed,
that might be enlightening.

> 
> Cheers,
> Adrian
> 
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================