Re: LCAS and GMPLS

["Diego Caviglia" <Diego.Caviglia@marconi.com>]

If I've correctly understood the ASSOCIATION obj it should work in the same
way as the Call_ID (operator spec) obj.

Wataru if you're familiar with ITU I'll try to make a corrispondence
between the two objects.
The corrispondeces are the following:
Call_ID (RCF 3473)                        ASSOCIATION (
draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
Source LSR Address <--------------------> IPv4 Association Source
Type 1 = 4 bytes                          Type 1 = 4 bytes
Type 2 = 16 bytes                         Type 2 = 16 bytes
Type 3 = 30 bytes                         na
Type 4 = 6 bytes                          na

Local Identifier   <--------------------> Association ID
8 bytes                                   2 bytes

So a part from the maximum number of associations/Calls that a source can
originate seems to me that the two objects solve well the problem.

IMHO Call_ID is better but I'm not going to stress this point, if the
feeling of the group is to use ASSOCIATION obj for me it is fine.

Regards

Diego



Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp>@ops.ietf.org on 20/06/2005
02.52.41

Sent by:    owner-ccamp@ops.ietf.org


To:    "Adrian Farrel" <adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>
cc:

Subject:    Re: LCAS and GMPLS

Hi, Adrian

  Thank you for your comment.
  I should have explain my thought more in detail.


> > >see anything that forces this limitation. In fact, it would be hard to
> > >offer 1:n protection with such a scheme.
> >
> > In my understanding, the ASSOCIATION ID of ASSOCIATION Object only
> > relates protected LSP and protecting LSPs.
>
>Then I am sorry to say that your understanding is wrong.
>
>The Association object is used to associate LSPs.
>Clearly, in its use in a protection ID it describes the association for
>the purposes of protection. However, the text is carefully worded to
>ensure that the object is more widely applicable.
>To quote from section 16...
>    The ASSOCIATION object is used to associate LSPs with each other.

>You originally said...
> > > > Current ASSOCIATION objects relates only two connections.
>...but you now seem to accept that the Association object can relate more
>than one LSP since you say...
> > It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.
>
>Thus, I presume that you accept that the Association object could handle
>VCAT groups with more than two LSPs.

  Yes.
  In the case of 1:n protection scheme, all of n back up paths set the
primary LSP ID
for their Association IDs.  It seems OK the use of association ID.

> >   Now, consider the LCAS.
> >   Does the LCAS define or have primary connetion ?
> >   I think all of conections in LCAS should be equivalent.

>Why is primary conneciton valid? LCAS has nothing to do with protection.
>The Association object provides an *arbitrary* association ID that is
>common across all LSPs in the same group, and unique within the context of
>the association source. There is no concept of a primary connection in the
>process of association.

  But, my concern is the value of Association ID in VCAT.
  Different from 1:n protection, generic VCAT group does not have primary
connection.
  In the case of 1:n protection, we define "primary" connection.

  But, in the case of generic VCAT, the Association ID of second and third
connection
should be first connection of LSP ID ?
  My answer is no.

  The first connection in VCAT group can be torn down before the tear down
of secondary or third connection.
  If the second and third connection use LSP ID of first connection for
their Association ID,
the second and third connection of the VCAT group use non-existing LSP ID
for their Association ID
in some state.
  Do we accept this kind of state ?

Thanks,
Wataru

---------------------------------
Wataru Imajuku
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541