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

["Adrian Farrel" <[e-mail]>]

Hi Ben,

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

I believe that is the model we are building.
Actually, I can see ways to use the same mechanism to solve wider
connectivity pictures (e.g. C-to-C LSPs), but that would be an extended
application, and if it turned out to need additional encodings and
procedures, i think it would be fine.

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

I, in my turn, am not quite sure what you mean by "determined" :-)
There are two steps:
1. The call responder can return information on one or more "links
  between the network and the egress"
  To do this, the call responder must determine such appropriate
  links. It would certainly require knowledge of the destination of
  the call, and would need to understand how that call destination
  can be mapped to real connection end-points.
  Now, it could simply return a full list of the available links with
  information about the link capabilities, or it could filter the list
  based on the information on the call request to supply a list of
  links that it knows are suitable. Implementation choice.
2. On receiving a call response, the initiator must determine paths
  for the connections (LSPs) that it will set up. The way that it
  does this is (obviously?) out of scope since it is an algorithmic
  process. However, it can take as input the information about
  the available final links as supplied in the call response.

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

Yes. But we should not imply that it only applies to bundled links, so we
need to tidy this up a bit.

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

Well, from my own personal point of view, while I think functional modeling
can be a useful tool, I do not see the need for it here.

However, if I put on the CCAMP co-chair hat (for the first time in this
discussion) I would say that if someone wants to produce a functional model
for GMPLS then the working group would be pleased to look at it.

> Are you saying that the ingress (i) can generate different LSP types
> (i.e., different layer network technologies)

Yup. The ingress can choose which adaptation functions to use.

(Note that this is NOT saying that it can mix and match different LSP types
to carry one payload signal.)

> or (ii) can generate a different number of signals (e.g., as in VCAT)

Absolutely, yes.

> or (iii) that the ingress offers different adaptations from
> a client to the LSP(s)?

Yes, again.

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

I guess it would need to exchange the available lambdas that it can
terminate.

And, yes, this is not specified at the moment. All the I-D is doing is
providing the tool kit, not the details of applicability.

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

I think that adaptation and switching capabilities would be important here.

But, again, the detailed information awaits someone who is implementing
this. We are just providing the object in which it can be encoded.

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

It is the address of an access point (such as an egress outside the network)
where the address is taken from a different address space. You can read more
on this in RFC4208.

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

If you accept that the information needs to be exchanged, then the
discussion is about which mechanism to use. The choice can be between many
mechanisms, but this is the only one that has been put forward. Other
proposals would be welcomed, but in the presence of only one proposal and
the clear support from implementers, the request for technical reasoning for
adopting the solution seems a bit odd to me.

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

Why do you believe there should be a discussion of the technical reasons for
a feature on the mailing list/ What is wrong with presenting the solution in
an I-D and allowing those with concerns (for example, those who are
implementing in this area and who believe there is a better solution) to
raise the concerns?

> (BTW, I raised this concern during working group last call;-)

Did you?
Are we still talking about the same thing? That is, the necessity and value
of carrying Link Capabilities on a Call set-up or response message?
I don't see any mention of this in your email of 19th June. In that email
you questioned:
1) Why use a notification message for Call control?
2) Were other (existing) call control protocols considered?
3) The network boundaries and models in sections 4.3 and 7
4) The exclusion of Simultaneous Call and connection establishment.
5) The address model in use.

What exactly are you saying that you raised in the last call discussion? I
assume that you are saying that your concerns with the network boundaries
described in section 4.3 amount to a concern about the mechanisms used to
exchange information about the links that cross those boundaries.

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

If other mechanisms exist that you believe are better, and if your
implementation has shown that they are suitably functional, then I recommend
you bring them forward quickly. In fact, I would go as far as saying that
you have a responsiblity to bring them forward.

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

Yes?

Let's take a PSC example and use the language of RFC4208.
Suppose that an EN is dual-homed to the network as in the case of the EN in 
the bottom left hand corner of Figure 1 of RFC4208.
Let's suppose that the links to the network have very different delay 
characteristics.
Let's assume that a connection is required to carry delay-sensitive traffic 
across the network to this EN.
A call can be used to coordinate between the end points and to convey the 
service requirements.
The call response can be used to convey a list of suitable links, or the 
link capabilities of all links.
The connection can be routed to achieve the required service level.

Adrian