[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Hi Adrian,
> > 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.
What is "C-to-C"?
It would be helpful if the specific case (or cases) covered by this
draft were clearer. From the text in 4.3.1, 4.3.2, and 4.3.3 the form
of the protocol relationship across the link between the network and the
egress node seems to vary, but this is not explicitly described.
>
> >>> 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" :-)
I think you got it right, i.e. how the egress call controller determines
the links about which to return capability info. If I understand your
description below the determination of candidate links can take into
account more than just the destination name or address. Correct?
> 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.
>
...snip...
> >>> 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.
A functional model would be useful to show unambiguously what transport
plane configuration is being controlled by GMPLS. It would not apply to
modeling GMPLS itself (control plane technology). Throughout this
discussion I have had the feeling that only a subset of the possible
transport plane configurations are considered; however, the draft does
not clearly identify the configurations to which it applies. Of course,
there is the fact that the link capability object is optional, so one
could argue that it can be used in any situation in which it is found
useful. (Rather open ended.)
>
> > 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.
So it sounds like arbitrary flexibility is envisioned (which perhaps is
related to a lack of understanding of what flexibility is really
needed).
>
...snip...
> >>>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.
Can't this constraint be handled by the egress, with the help of the
Label Set object?
>
> 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.
Negotiation of adaptation above the layer of the LSP being setup must
also be done for LSPs that are set up using management methods. This is
something a capability exchange or link management protocol can do. Why
is it necessary to duplicate this function in the call control protocol?
>
> But, again, the detailed information awaits someone who is
implementing
> this. We are just providing the object in which it can be encoded.
So at base this seems to be an open ended mechanism, for which
particular uses may be found in the future. If the link capability
information is passed transparently between ingress and egress nodes,
this may present an issue for operators who do not wish to provide
clients an open communications channel via their signaling network.
...snip...
> >>> 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.
I would expect the technical reasoning supporting a proposed standard
should be fairly easy to provide. I also think it would be of interest
to anyone involved in standards development. (And even the need for the
information to be exchanged is still nebulous.)
>
> >> - 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.
Yes.
>
> >> 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.
It is common in transport applications for dual- (or multi-) homed
arrangements to be used for diversity and are expected to provide
equivalent service characteristics. If the links do not provide
equivalent service characteristics, then they could be given different
destination addresses (or names) and the call request could be made to
the appropriate destination for the service.
It seems that this mechanism is being offered as a new level of routing
functionality. That is, as a mechanism to choose which links would be
used to establish a connection (by selection from the set offered by the
egress call controller). It adds a dimension of flexibility, and also
complexity, but the need for this added dimension seems nebulous.
>
> Adrian
Regards,
Ben
============================================================
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
============================================================