[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MRN ext. doc
Hello again,
Section 4 appears to consider only the mapped server model
(allowing a many to one mapping), but not the multiplexed
server model. Is it the intention to defer this to Section 5?
i don't understand the question.
Hmm. I'm using ITU terminology.
[SNIP]
can u please use the ietf terminology at least to make the point
understandable to me (excuse my ignorance). what is a mapped
server ?
OK. Well, I did try to explain in my previous response.
[SNIP]
ok, i think i barely understood where you are heading at. now what is
the issue with the doc. ? honnestly, i do not catch the point you are
trying to make: section 4 addresses purely signaling procedure issue
(complements existing FA triggering/selection rules) and section 5 a
well-known TE problem that is how to attract traffic when no bearer is
setup (it is a particular case of the generic unknown adjcacency
problem).
I didn't actually say there was anything wrong with the document :-)
I just asked what I hoped was a simple question.
From our discussion it looks like the answer to my question was "yes". Let's
move on.
===
The Call-Attributes object C-Num is picked from the 11bbbbbb
class. Why?
Surely if any node that processes the Notify message does not
understand the object, you want the Call to fail.
this what has been agreed from last meeting. see Lou's preso.
It doesn't make sense to use 11bbbbbb.
[SNIP]
not sure. at the end the question is an attribute object class a
criteria for which rejection is expected. going one step
further one can mandate support of the class but it is the
support of the associated capability that matters.. one would
be still blocking on the latter anyway if that capability would
not be supported independently of the object class. so it is
the "mandatory or optional" nature of the attribute that induce
support of the object not the other way around.
I spoke to Lou.
He had suggested 11bbbbbb because he thought the object might
end up on a Path message. However, we don't think this would
actually be the case because the call request message is a Notify.
So he is more relaxed about this changing to 0bbbbbbb
are call attributes mandatorily associated to calls (and which case
one could simply mandate support of the related attribute) and their
messaging/processing a must have feature of the protocol ? ... just to
be clear 0bbbbbbb does not solve the former.
No, the Call_Attributes object is not mandatory on a Call request message
(as currently defined). And yes, you are right, using 0bbbbbbb would not
make it mandatory anyway.
I am *only* concerned by how the call recipient will process the Notify, how
(if?) they will respond, and whether this will waste processing in the
network, especially at the call recipient.
===
I'm puzzled that the Call described in section 5.1 does not
indicate to the intended LSP egress in which layer or
region the soon-to-be-set-up LSP will be required to
operate.
[SNIP]
I meant...
Suppose the head and tail of the planned virtual TE link are
present in three regions (or layers, don't forget layers). One
is the client, and two are potential servers.
Shouldn't the call indicate which server the caller
wishes/intends to use?
assume a base virtual TE link [PSC,PSC] and the two link
sequence that can be followed by the FA-LSP are either
[PSC,LSC]..[LSC,LSC]..[LSC,PSC] or [PSC,TDM..[TDM,
TDM]..[TDM,PSC] it is the association between the TE
link and LSP that determines to which FA that TE link is
now related to
I agree completely.
And that was my point.
The call is a negotiation between end points about what
connection will be set up, what adaptions will be applied,
and what TE link will be created.
This effectively requires the call request to state the set
of potential adaptations, and the call response to identify
the subset of acceptable adaptations. The connection can
then be signaled in the correct switching type, and the
resulting LSP can be associated to the TE link.
per 4974, the LINK_CAPABILITY object can be used for
this purpose with subobject Type 65.
i did not mention it for two reasons a) it is implicit in the
context (a Virtual Link by definition addresses the lowest SC
value) and b) part of the procedure referenced by this doc.
Weeeeell...
That use of Link Capability is not particularly clear in RFC 4974.
According to section 4.3.3. of RFC 4974 this function allows the call
initiator to list a set of switching capablities for links that connect it
"to the network", and for the responder to reduce the list to those
switching capablities that it supports.
That is only half the function required.
We also need to let the call responder know that we intend using the LSP to
support a connection in a particular client layer/region. In other words, we
have to specify what adaptation function we want the responder to support.
It would be enough to add to the information already carried in the
Link_Capablity object the link capability we intend to create. This could go
in either the Link_Capablity object or in the Call_Attributes object.
Oh, by the way, Link_Capability uses a CNum of type 0bbbbbb
A