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

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Ben,

Thanks. These questions give us something to chew on.

> > You appear to be making two comments in this paragraph.
> > 1. The problem statement for the I-D is not sufficiently clear.
>
> I did not make this comment, AFAIK.

It doesn't matter.

I read...
> Unfortunately I had sufficient difficulty understanding the
> problem statement that I did not immediately question the
> need for the object (hoping that clarification of the problem
> would shed light on this).
...as an issue with the problem statement.

I'm glad that the general problem statement is clear, and we only need to 
focus on the specifics of Link Capabilities.

> > 2. The requirements for (and use of) the Link Capabilities
> >    object are not clear.
> ... snip ...
> > With regard to the purpose and use of the Link Capabilities
> > object, this is driven mainly by the material in section 4.3.
> ... snip ...
> > What don't you understand? What are your questions?
>
> OK, here is section 4.3 with some questions:

Excellent. Thanks.

>   It is useful for the ingress node of an LSP to know the link
>  capabilities of the link between the network and the egress node.
>
> Do the ingress and egress nodes terminate the LSP to be setup?

Yes, indeed. Rooted in RFC3031, section 3.15.

> 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. 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.

>   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.

>  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".

> 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".

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.
Maybe more important are:
- this mechanism is one that several implementers want to /  have
 implemented.
- no-one raised any concerns about this mechanism during a
 couple of years of discussion of this process and during WG
 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.

Cheers,
Adrian