Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: John Drake <[email-masked]>
Date: Mon, 3 Mar 2003 17:54:54 -0800

Comments in line. 
 
 A general comment is that it occurs to me that MBB and the RSVP path
protection I-D (
<http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sig
naling-00.txt>
http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sign
aling-00.txt) both take advantage of the fact that RSVP-TE already has a a
version of call/connection separation.  It might be prudent to examine its
capabilities before inventing a new mechanism
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Monday, March 03, 2003 4:28 PM
To: John Drake; 'Zhi-Wei Lin'; [email-masked]
Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi John,

Thanks for the clarification. Some more comments below...

Keeping a connection alive while attempting to reroute it after outage.
(This is basic RSVP and  MBB allows you to reuse links on the failed path.) 
[Zhi-Wei Lin]  I don't think the intent of the call is simply to allow to
keep connections alive.  

============================================================================
============================

JD:  Are you saying that the above is not a requirement?

============================================================================
============================

 A call is much more related to the concept of providing service to the
end-user. One of the services is the ability to keep a connection alive for,
e.g., billing purposes, and having a single call ID for a call makes
tracking of the service much easier as well. 

============================================================================
============================

JD:  This sounds like an assertion.

============================================================================
============================  

Establishing a new path for an existing connection so that links along its
current path may be taken out of service for maintenance.  (This sounds like
a definition of MBB.)
[Zhi-Wei Lin]  Same comment as above.
 
Keeping track of the circuits in a virtual concatenation group.  (I think
this is covered with the SDH/SONET signalling draft.)
[Zhi-Wei Lin] This is really not covered in full in the SONET/SDH signaling
draft. The current signaling draft puts a limitation on the virtual
concatenation by requiring that all component members of the virtual
concatenated signal travel along the same path. The general virtual
concatenation mechanism allows for each component of the virtual
concatenation group to travel along different paths. This is really where
the call concept comes in handy. Again note that call is not designed
specifially for the virtual concatenation, but it provides a nice way of
supporting the multiple routings for each component virtual concatenated
signal. 
 
============================================================================
============================
JD:  I don't think that multiple connections per call, especially
connections that take different paths, is supported in either G.8080 or
G.7713.x.  Furthermore the existing RSVP-TE mechanisms could be used to
support the general case 
============================================================================
============================
 
The other requirement I've heard is a need to have the ingress and egress
nodes perform a capabilities exchange prior to establishing a connection,
and that sounds like something Notify should be used for.
[Zhi-Wei Lin] Right, but this also means extending the Notify message. So
it's a matter of choosing one method for support versus another. Also using
the Notify to support this is just solving one part of the puzzle. It could
be done, but the call mechanism gives you all the above, plus the "service"
concept (whatever that is... ;-)  
 
============================================================================
=============================
JD:  It is not at all obvious from your draft whether you are:
 
 a) piggybacking a call ID on normal RSVP LSP setup 
 
or
 
 b) using a hacked up version of RSVP LSP setup to instantiate call state in
all of the nodes along a path from ingress node to egress node.
 
If it is the former, then using Notify is better because it allows a
capabilities exchange prior to the allocation of any network resources.  If
it is the latter, then using Notify is better because you are creating
severe interoperability problems with nodes that understand GMPLS signalling
but don't understand this hacked up version of RSVP setup, in support of
something which is supposed to be an ingress/egress node function.    
============================================================================
==============================
 
 For folks who wants to understand call, you can read G.8080 (that ITU-T G.
stuff again! ) or (*gasp!*) some of the ATM documents on call (Q.2981 I
think).  
 
============================================================================
==============================
JD:  As I've said before, during my tenure at the ATM Forum, we could not
get call/connection separation to work in PNNI.
============================================================================
==============================
 
 Of course those of you who still uses your telephone or even your cellphone
are everyday making a "call" (but only always one connection within the call
-- very limited, huh??) 
 
Thanks,
 
John
 
-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Sunday, March 02, 2003 11:21 AM
To: [email-masked]
Cc: John Drake
Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

Hi John, 

I was wondering about the statements you've made below, especially the one
about "all of them can be handled with the existing Make Before Break
component of RSVP-TE". I'm a little slow, so could you elaborate a little
more as to how this is related to the call/connection concept, and how the
make-before-break actually handles the call service concept? 

Thanks
Zhi 

 From: John Drake [mailto:[email-masked]]
Sent: Friday, February 28, 2003 4:15 PM
To: [email-masked]'; Varma, Eve L (Eve)
Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
Andersson; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

I agree with Eric.

As an example, we have call/connection separation, which has been kicking
around since the early days of ISDN. In discussions as to why it is needed,
the first reason is always "because". Once past that, I have consistently
heard four or five examples cited. What is interesting is that all of them
can be handled with the existing Make Before Break component of RSVP-TE. 

Thanks,

John

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
> Andersson; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> Eve> For individual contributor drafts coming in, it's quite 
> appropriate to
> Eve> evaluate requirements and determine if they are 
> legitimate. It's a
> Eve> different case when another SDO, responsible for a 
> non-IP applications
> Eve> domain, has established a set of requirements related to 
> that domain.
> 
> I'd certainly disagree with that. Many of the 
> "requirements" I see from
> other organizations are not requirements at all, but 
> just dogmatic
> statements of connection-oriented religion. If the IETF 
> were to accept
> requirements from other organizations, it would quickly be 
> inundated with
> "requirements" to make IP behave exactly like ATM. In 
> fact, anyone who
> works in the PWE3 group can testify that such "requirements" 
> come in all the
> time. 
> 
> 
> 

  _____  

Do you Yahoo!?
Yahoo!  <http://rd.yahoo.com/finance/mailtagline/*http://taxes.yahoo.com/>
Tax Center - forms, calculators, tips, and more

---

From: Zhi-Wei Lin <[email-masked]>
Date: Mon, 03 Mar 2003 21:43:53 -0500

Hi John,

What you said is probably all true, but then that just gets to the fact that
there are multiple ways to skin a carrot. What you've specified using the
Notify probably works just as well. As for your other comments, as I said
keeping a connection alive is not the only call property, but just one. That
doesn't mean it's not a requirement anymore, just one of them. As for the
assertion, you're probably referring to this statement: "having a single
call ID for a call makes tracking of the service much easier as well". Well,
yes it is an assertion I guess, but I think it's an understandable
assertion, no? How many IDs do you want to be used to represent a single
service offered to a customer?

As for the virtual concat support, you're right again that G.7713.x does not
support the general case either. This is because not all technical issues
have been resolved. But the call ID provides the method for enabling tying
the different virtual concat connections together as a single call service.
Again there are multiple ways to do this, and we've chosen one.

Thanks for your comments! Definitely helps to identify what different
methods there are to solve the same problem.

Zhi

  -----Original Message-----
  From: John Drake [mailto:[email-masked]]
  Sent: Monday, March 03, 2003 8:55 PM
  To: 'Zhi-Wei Lin'; 'Zhi-Wei Lin'; [email-masked]
  Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

  Comments in line.

   A general comment is that it occurs to me that MBB and the RSVP path
protection I-D
(http://www.ietf.org/internet-drafts/draft-lang-ccamp-gmpls-recovery-e2e-sig
naling-00.txt) both take advantage of the fact that RSVP-TE already has a a
version of call/connection separation.  It might be prudent to examine its
capabilities before inventing a new mechanism

  Thanks,

  John

  -----Original Message-----
  From: Zhi-Wei Lin [mailto:[email-masked]]
  Sent: Monday, March 03, 2003 4:28 PM
  To: John Drake; 'Zhi-Wei Lin'; [email-masked]
  Subject: RE: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

    Hi John,

    Keeping a connection alive while attempting to reroute it after outage.
(This is basic RSVP and  MBB allows you to reuse links on the failed path.)
    [Zhi-Wei Lin]  I don't think the intent of the call is simply to allow
to keep connections alive.

      Establishing a new path for an existing connection so that links along
its current path may be taken out of service for maintenance.  (This sounds
like a definition of MBB.)
      [Zhi-Wei Lin]  Same comment as above.

      Keeping track of the circuits in a virtual concatenation group.  (I
think this is covered with the SDH/SONET signalling draft.)
      [Zhi-Wei Lin] This is really not covered in full in the SONET/SDH
signaling draft. The current signaling draft puts a limitation on the
virtual concatenation by requiring that all component members of the virtual
concatenated signal travel along the same path. The general virtual
concatenation mechanism allows for each component of the virtual
concatenation group to travel along different paths. This is really where
the call concept comes in handy. Again note that call is not designed
specifially for the virtual concatenation, but it provides a nice way of
supporting the multiple routings for each component virtual concatenated
signal.

      The other requirement I've heard is a need to have the ingress and
egress nodes perform a capabilities exchange prior to establishing a
connection, and that sounds like something Notify should be used for.
      [Zhi-Wei Lin] Right, but this also means extending the Notify message.
So it's a matter of choosing one method for support versus another. Also
using the Notify to support this is just solving one part of the puzzle. It
could be done, but the call mechanism gives you all the above, plus the
"service" concept (whatever that is... ;-)

      or

       b) using a hacked up version of RSVP LSP setup to instantiate call
state in all of the nodes along a path from ingress node to egress node.

       For folks who wants to understand call, you can read G.8080 (that
ITU-T G. stuff again! ) or (*gasp!*) some of the ATM documents on call
(Q.2981 I think).

============================================================================
==============================
      JD:  As I've said before, during my tenure at the ATM Forum, we could
not get call/connection separation to work in PNNI.

       Of course those of you who still uses your telephone or even your
cellphone are everyday making a "call" (but only always one connection
within the call -- very limited, huh??)

      Thanks,

      John

      -----Original Message-----
      From: Zhi-Wei Lin [mailto:[email-masked]]
      Sent: Sunday, March 02, 2003 11:21 AM
      To: [email-masked]
      Cc: John Drake
      Subject: Re: FW: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

        Hi John,

        I was wondering about the statements you've made below, especially
the one about "all of them can be handled with the existing Make Before
Break component of RSVP-TE". I'm a little slow, so could you elaborate a
little more as to how this is related to the call/connection concept, and
how the make-before-break actually handles the call service concept?

        Thanks
        Zhi

        I agree with Eric.

        As an example, we have call/connection separation, which has been
kicking
        around since the early days of ISDN. In discussions as to why it is
needed,
        the first reason is always "because". Once past that, I have
consistently
        heard four or five examples cited. What is interesting is that all
of them
        can be handled with the existing Make Before Break component of
RSVP-TE.

        Thanks,

        John

        > works in the PWE3 group can testify that such "requirements"

------------------------------------------------------------------------
        Do you Yahoo!?
        Yahoo! Tax Center - forms, calculators, tips, and more

---

From: [email-masked]
Date: Tue, 04 Mar 2003 11:07:04 +0100

zhi,

see in-line with [DP]

Hi John,
 
What you said is probably all true, but then that just gets to the fact
that there are multiple ways to skin a carrot.

[DP] the same kind of arguments you're using since day one
     and i am not sure it has help in progressing the debate
     ... i should probably say they are many ways to cook it
     and for the time being your carrot is crude

What you've specified using the Notify probably works just as well. As
for your other comments, as I said keeping a connection alive is not the
only call property, but just one. That doesn't
mean it's not a requirement anymore, just one of them. As for the
assertion, you're probably referring to this statement: "having a single
call ID for a call makes tracking of the service much easier as well".
Well, yes it is an assertion I guess, but I think it's an understandable
assertion, no? How many IDs do you want to be used to represent a single
service offered to a customer?
 
As for the virtual concat support, you're right again that G.7713.x does
not support the general case either. 
[DP] so if i well understand what's today in the info rfc
     doesn't deliver what it claims to do ?

This is because not all technical issues have been resolved. 

[DP] and this is why a discussion with the wg is always better
     than going alone with a partial solution

But the call ID provides the method for enabling tying the different
virtual concat connections together as a single call service. Again
there are multiple ways to do this, and we've chosen one. 

[DP] as usual you escape the problem instead of solving it
you are using a hacked up version of RSVP LSP setup for 
instantiating the call state in all of the nodes along a
path from ingress node to egress node before establishing
the connection clearly what happens if one of the nodes
in between doesn't support your info rfc ?

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491