Hi,
Please see below for some responses...
-----Original Message-----
From: John Drake [mailto:jdrake(_at_)calient(_dot_)net]
Sent: donderdag 23 januari 2003 3:49
To: 'Wijnen, Bert (Bert)'; Kireeti Kompella
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
In spite of the subject line my comments are primarily on
draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen(_at_)lucent(_dot_)com]
Sent: Wednesday, January 22, 2003 4:19 PM
To: John Drake; Kireeti Kompella
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Inline
-----Original Message-----
From: John Drake [mailto:jdrake(_at_)calient(_dot_)net]
Sent: woensdag 22 januari 2003 22:28
To: 'Wijnen, Bert (Bert)'; Kireeti Kompella
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Bert,
I don't recall a SG15 Liason of the form 'Btw, we're planning
to change a couple of your protocols (CR-LDP, RSVP-TE),
and we hope you don't mind".
Well... they did not word it as you are doing, but... the LIASON
statements that have been sent to CCAMP and that have been available
on the IETF web pages DO point to documents where that is described.
Also... I believe that an ITU SG-15 person was speakeing at every
CCAMP WG meeting since London or so to talk about the things they
were doing.
So don't give me the crap that the CCAMP WG members are not aware
of this for quite a long time. If you are not aware, then I can
only conclude that you have payed no attention.
JD: The last liason statement on this topic that I've seen on the
IETF liason web page is: http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
end JD:
<zhi>Kam sent out an email that points to the liaisons. Also Wesam and Steve
provides an update at many meetings. Let's not dwell on this issue
anymore...</zhi>
More importantly, do you really think it's a good idea to allow
other organizations to change the IETF's protocols?
Now... the question is: are they indeed CHANGING an IETF protocol?
JD: They wish to deprecate ResvErr and ResvTear, as well as the FILTER_SPEC
and LABEL objects. They wish to use the Generalized UNI object to identify
the RSVP session endpoints and the parameters of the LSP.
end JD:
<zhi> Where do you see that we deprecate ResvErr and ResvTear? (for the record:
these are not deprecated)
Where do you see that we deprecate FILTER_SPEC and LABEL objects? (for the
record: these are not deprecated)
Also, where do you see that we wish to identify the RSVP session endpoints with
GENERALIZED_UNI? (for the record: the RSVP session is still SESSION object)
</zhi>
First, we have defined a few namespaces (for RSVP and for LDP)
so that the protocols are extensible. We have split up those
name spaces, such that people or organisations can ask for
code points in IETF-consensus-required section or in a FCFS section
(First Come First Served, formally no documentation required I think)
As you can see, in the RSVP space, there is a lot of FCFS code points.
For the RSVP solution, they (ITU/OIF) are mainly asking for code
points in the FCFS space. So what was our intention for that namespace
when we defined it?
My feeling is from all the discussions, that the biggest problem
is not so much on how RSVP or CR-LDP code points are added (the
protocol is still the same, there are just more Objects and/or TLVs).
JD: See my comment above.
I'll admit that some comments have been received on if the way the
TLVs and Objects/Classes have been organized is very clean or ideal,
but that seems also a bit of a detail to me.
Rather the problem is that they talk about and want to provide:
- call and connection separation
- that they add NSAP addresses
- that they define a UNI interface (which we, IETF forcefully
rejected to be worked on in IETF a few years back)
Now... if those are the 3 issues, then I think we have only seen
a few people object. But the objections are more of the form
that people don't like this (which is OK, this is one of the
reasons why we did not want to do this work in IETF), but I
still fail to see any mention of the real technical problems
of what they are doing. But then, I am not a control-plabe
or data-plane (or MPLS or GMPLS for that matter) expert.
As Jerry Ash pointed out, that's the same as having the IETF
develop its own version of G.709. I think it would have been
a much better idea for the ITU to send G.7713 to the IETF
(CCAMP) and ask them to develop protocols to support it.
I believe that at least for teh UNI, they have done so in
the past and we told them to go away.
I believe that NSAP was also disliked and we did send them away.
I am not 100% clear on call and connection separation.
JD: You're confusing a couple of different 'theys'. UNI and NSAP
were OIF, and they're back:
http://www.ietf.org/internet-drafts/draft-bala-uni-ldp-rsvp-extensions-04.tx
t
What you're calling call and connection separation is actually a bit more
than just that, as described in G.7713, and that 'they' is ITU. You didn't
actually address my point, which is why is it okay for ITU to change RSVP
when
it's not okay for the IETF to change G.709.
end JD:
<zhi>The statement above about G.709 is irrelevant to the discussion. In terms
of sending G.7713 to IETF and asking to develop protocol...that's what was
done. Back on 2001 discussions were started on what requirements and
architectures are needed to support G.8080. Individuals (who happens to
participate in both IETF and ITU) then started submitting protocol extensions.
People either choose to ignore these or expressed opposition to making these
extensions simply because it went beyond the traditional IP services.</zhi>
Hope this can help to bring the discussion to either consensus
to approve, or to show us what the real technical issues are
by those who have raised objections sofar.
JD: I don't see any reason to deprecate ResvErr and ResvTear, or
FILTER_SPEC
and LABEL objects.
<zhi>See above</zhi>
I don't see any reason to use the Generalized UNI object to identify
the RSVP session endpoints and the parameters of the LSP.
<zhi>see above</zhi>
I don't see any reason to use the Generalized UNI object to
support Soft Permanent Connections, since as the draft acknowledges,
GMPLS signalling has an existing mechanism.
<zhi>Existing mechanisms we mentioned may be used, but the preference would be
to use GEN_UNI for SPC (and this is in fact what we use for the ASON
specification). This is because (again) of the architecture assumptions made in
G.8080. An ASON network is assumed to be composed of multiple domains. In the
vision of a global ASON network you might have multiple carriers connecting
together (but also multiple domains within a single carrier network). The
interfaces defined for these inter-domain signaling is the E-NNI interface.
However, across an E-NNI the ERO object is an optional object, and in certain
instances the information may not be passed due to policies that carriers may
impose on the inter-domain interface.
If we were to use the ERO to carry the SPC information, then conceivably there
are cases where this information would not pass the interface.</zhi>
As the draft acknowledges, the details of call/connection separation
have not been completely thought out, so why is a call identifier introduced
when we don't know if it is either necessary or sufficient? I also think
its format is unnessarilly complex.
<zhi>The reason the draft does not include explanations of the call/connection
separation is because when the initial version of the draft was submitted, I
was told to break the document into two documents: one on requirements and one
on just the protocol extensions. So if you want more explanations, G.8080 and
G.7713 has much architectural descriptions and requirements for ASON. Also, the
companion document (draft-lin-ccamp-gmpls-ason-rqts-00.txt) should still be
available (it expires in Feb. 2003). This document was created as a result of
breaking up an earlier version of the protocol extension document to a "just
protocol extension" and a "requirements" document. This action was SUGGESTED by
the members of the ccamp group in one of the earlier meetings, and that's what
I did...
In terms of just explaining what is the call and connection separation, I
believe most people should understand what the difference is between call and
connection. After all in telecom this concept is not new (ATM and ISDN both
have these concepts). Now to give a brief explanation, section 3.4 of the above
mentioned document has this to say:
A call may be simply described as: "An association between endpoints
that supports an instance of a service" [G8080]. Thus a call can be
considered as a service provided to the user endpoints, where
multiple calls may exist between any two endpoints. Each call may
have multiple connections. The call concept provides an abstract
relationship between two users, where this relationship describes (or
verifies) the extent to which the users are willing to offer (or
accept) service to each other. A call therefore does not provide the
actual connectivity for transmitting user traffic, but only builds a
relationship by which future connections may be made.
A property of a call is its ability to contain multiple connections,
where each connection may be of a different type and where each
connection may exist independently of other connections within the
call, i.e., each connection is setup and released with separate
Path/Resv messages. For example, a call may contain a mix of basic
connection, virtual concatenated connections and contiguous
concatenated connections (see [GMPLS-SDHSONET] for corresponding
connection signaling extensions).
The concept of the call allows for a better flexibility in how users
set up connections and how network offers services to users. In
essence, a call allows:
- Support for virtual concatenation where each connection can
travel on different diverse paths
- allows the use of a public and private addressing space (hosts
using public space while network using only internal private
addressing space)
- Better upgrading strategy for service provider control plane
operation, where a call control (service provisioning) may be
separate from switches and connections (where the connection
control may reside)
- Verification and authentication of a call (with both network
call controller as well as destination user) prior to
connection, which may result in less wasted resources
- General treatment of multiple connections which may be
associated for the purpose of recovery; for example a pair of
primary and backup connections may belong to the same call.
</zhi>
The processing of a call is said to be different than that of a connection,
but these differences are not detailed.
And by the way, if you read G.7713.2, it doesn't have any more explanation
for
how these TLVs are used than draft-lin-ccamp-gmpls-ason-rsvpte-04.txt does,
and
I think that is my primary objection to both.
<zhi>The explanations for the protocol extensions are in G.7713, which is the
protocol neutral document. Yes, there is some indirection and pointers, but
that's true for many documents structured in a hierarchical manner, i.e.,
G.807 is the "base" requirements document
G.8080 builds on the G.807 requirements and adds the architectural components
associated with control plane
G.7713 builds on the G.807 requirements and G.8080 architectures, and specifies
a protocol neutral way of supporting the call and connection controller (this
is the signaling part)
G.7715 builds on the G.807 requirements and G.8080 architectures, and specifies
a protocol neutral way of supporting the routing controller (this is the
routing part)
After these "framework" documents are in place, the "dot" series of
Recommendations are specified for the protocol specific support of ASON control
plane (below are just signaling):
G.7713.1 is the PNNI extensions to support the G.7713 protocol neutral
signaling specification
G.7713.2 is the RSVP-TE extensions to support the G.7713 protocol neutral
signaling specification
G.7713.3 is the CR-LDP extensions to support the G.7713 protocol neutral
signaling specification
</zhi>
I hope this helps to explain the issues expressed by John (of course I expected
John to understand call/connection as he was a member of ATM Forum in
developing the PNNI specification...)
Zhi