[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LCAS and GMPLS



Hi Adrian,
           again agreed.

Diego



"Adrian Farrel" <adrian@olddog.co.uk> on 20/06/2005 15.25.06

Please respond to "Adrian Farrel" <adrian@olddog.co.uk>

To:    "Wataru Imajuku <imajuku.wataru", "Diego Caviglia"
       <Diego.Caviglia@marconi.com>
cc:    "ccamp  <ccamp"

Subject:    Re: LCAS and GMPLS

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

> 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 apart 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.
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