Subject: Re: LCAS and GMPLS

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 20 Jun 2005 10:16:18 +0200

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 <[email-masked]>@ops.ietf.org on 20/06/2005
02.52.41

Sent by:    [email-masked]

To:    "Adrian Farrel" <[email-masked]>, "ccamp" <[email-masked]>
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Jun 2005 14:25:06 +0100

Hi Diego,

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

If you MUST make the comparison :-)

> Call_ID (RCF 3473)    ASSOCIATION (draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
> Source LSR Address <--> IPv4 Association Source
> Local Identifier   <--> Association ID
> 8 bytes                 2 bytes
> 
> So apart from the maximum number of associations/Calls that a source can

So, something that might be useful would be if the requirements I-D made some statement about the number of VCAT groups likely to be originated by a single sender.

It is my *guess* that the number of such groups is likely to be smaller than the number of LSPs associated by the same sender. Thus, the size of the group ID does not need to be larger than the size of the LSP-ID.

If there is a need to overload the semanitc of the group ID for correlation with LCAS or something, then we should discuss the point, but so far we have only discussed it in the context of grouping together a set of LSPs.

Cheers,
Adrian