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

[John Drake <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, January 22, 2003 4:19 PM
To: John Drake; Kireeti Kompella
Cc: Bob Braden; [e-mail]; [e-mail]
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational


Inline

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

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

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:


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.  

I don't see any reason to use the Generalized UNI object to identify
the RSVP session endpoints and the parameters of the LSP.

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.

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.

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.
end JD: 

Bert
> Thanks,
> 
> John