Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

From: "Lin, Zhi-Wei (Zhi)" <[email-masked]>
Date: Thu, 23 Jan 2003 03:24:04 -0500

Hi,

Please see below for some responses...

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: donderdag 23 januari 2003 3:49
To: 'Wijnen, Bert (Bert)'; Kireeti Kompella
Cc: Bob Braden; [email-masked]; [email-masked]
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:[email-masked]]
Sent: Wednesday, January 22, 2003 4:19 PM
To: John Drake; Kireeti Kompella
Cc: Bob Braden; [email-masked]; [email-masked]
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational

Inline

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: woensdag 22 januari 2003 22:28
> To: 'Wijnen, Bert (Bert)'; Kireeti Kompella
> Cc: Bob Braden; [email-masked]; [email-masked]
> 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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Jan 2003 12:59:13 +0100

All,

taking a step back - I think we are discussing several issues in a mix
that makes it very hard to sort this out.

1. What other organizations may do to IETF (in this context (G)MPLS)
    protocols

    This won't be sorted out in this thread - and the only opinion so far
    is that it is a bad idea to let anyone else change or extend IETF
    protocols.

    This will require at statement from involved wg chairs and ADs and an
    approval from the IESG. I will push for such a statement.

2. Have the IETF protocols been changed

    This is is a matter of how "changed" is defined. Clearly the OIF
    UNI signaling spec extends the LDP protocol, message and new TLV.
    This is referenced by a normative reference in the three drafts
    discussed here

       draft-lin-ccamp-gmpls-ason-rsvpte-04.txt
       draft-aboulmagd-ccamp-crldp-ason-ext-02.txt
       draft-bala-uni-ldp-rsvp-extensions-04.txt

    I understand that the IESG wants to treat those as a packet, and that
    the last call on the CR-LDP Extensions for ASON to Informational in
    fact is a last call on all three of them. Further this could be
    construed to be seen as an "last call" on normative references -
    after all normative references are considered to necessary for
    implementing a spec.

    Also, the ITU work extends the IETF protocols, new objects, new TLVs
    and new error codes, that is why the drafts were written - to make it
    possible for IANA to approve the needed code points.

    In our normal use of terms change includes extends, but we should
    probably make that clear.

    The consequence of approving the drafts will be that the extensions
    by OIF and ITU will be approved by the IETF. I'm not sure that this
    has been in the open.

    However, not having a change process that relates to these protocols
    I'm not sure if the IESG can do anything else than approving that the
    IANA allocate the code points.

3. The quality of the drafts

    In my opinion (if I were to review them as a wg chair, but I'm not
    sure that those criteria apply to informational documents) we have a
    problem here.

    The draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and the
    draft-bala-uni-ldp-rsvp-extensions-04.txt is an a shape such that I
    would (reluctantly) request publishing.

    But the draft-aboulmagd-ccamp-crldp-ason-ext-02.txt is not, there is
    a long series of points that needs to be updated. References, TLV
    description, un-expanded acronyms, etc. Would have returned this to
    the author for further work. Aside from that I have a couple of
    technical issues.

    Now, if the IESG considers them to be a package, this would effect
    all of them. I guess that it would be possible to weed the draft
    after it has been approved, but it deviates from normal practice.

My belief is that we should try to separate these issues from each
other.

/Loa

-- 
Loa Andersson

Mobile          +46 739 81 21 64
Email           [email-masked]