Re: Prefix attribute

Hi Rick,

Please refer inline -

"Rick W. Porter" wrote:

> I have a couple issues with the Prefix Attribute.
>
> 1) I have concerns regarding the Prefix attribute being conditionally
> mandatory.
>
> It is logical from a route advertisement standpoint to express a list of
> prefixes along with ReachableRoutes containing the TrunkGroup and/or Carrier
> address family.  If we use Carrier or TrunkGroup families inside
> ReachableRoutes to change statistics (i.e. AvailableCircuits), we then need
> to list all Prefixes for a Carrier/TrunkGroup plus other mandatory
> attributes each time statistics are sent. This may be a fair amount of
> "worthless" data sent for each message, especially if the TrunkGroup or
> Carrier contains many prefixes.  More importantly, the LS that receives the
> message needs to check the entire Prefix list because it may change--it
> seems like a lot of overhead to update statistics.
>

The issue that you bring up is more fundamental. What you are talking about is
the ability to advertise routing information in an incremental fashion, that is
only the attributes
that changed since the most recent update message. This form of advertising is
not currently
supported in TRIP.

In TRIP, whenever an UPDATE message is received for a route destination, the
existing
attribute set for that destination is thrown away, and the newly received
attribute set takes
its place. There is no selective retaining of attributes from an earlier UPDATE.
As a result, all the
attributes that apply to a route destination are required to be included in
every UPDATE. I do
agree that is not the most optimal, but supporting incremental updates brings
its own set
of problems, having to deal with synchronizing pieces of routing information
received over multiple
updates in a consistent manner.

For the specific issue about updating resource changes on the gateway in a
periodic manner,
wherein only the resource attributes are the only ones constantly changing, I
agree that this problem
assumes greater proportions. Currently, UPDATE message is the only vehicle to
advertise routing
information; to alleviate this problem, one approach would be to introduce a new
message type (RSRC UPDATE?) for updating only the resource information
associated with route destinations. This requires
much more detailed thought and discussions. Maybe we should wait for people's
experiences
with TRIP before we consider such bigger changes. But nonetheless, would like to
hear people's thoughts
on this.

>
> 2) Do the address families in the Prefix attribute need to be negotiated in
> the Open exchange?
>

I guess you are refering to the different prefix attribute types - E.164,
Decimal, and PentaDecimal?
Each of these three prefix types has its own attribute type code. The prefix
attribute types are
currently not included in the OPEN message caps exchange.

Let me state the problem you mention, correct me if I am wrong. When a Gateway
advertising routes
using the Trunkgroup address family, for instance, is reporting all the three
prefix attribute types, but the
TRIP LS processing these gateway routes, has the capability for handling only
the E.164 prefix type, it
could run into trouble, when it receives Decimal and Pentadecimal Prefixes.

I see your point, maybe we need to introduce a PrefixCapability in the OPEN
message caps. negotiation.
Will write back on this issue after further thought.

Thanks,
-Manjax

>
> If not, the GW has a "backdoor" to insert routes with any address family!
> The GW may send TrunkGroup routes with POTS prefixes, and the LS may only
> want, or know how, to convert E164 prefixes.
>
> If so, the LS may be forced to accept routes of an address family it may not
> want to support.  The LS may not want individual E164 routes, but says E164
> to support TrunkGroup routes with E164 prefixes.
>
> Thanks,
> Rick
>
> _______________________________________________
> IPTEL mailing list
> [email protected]
> http://lists.bell-labs.com/mailman/listinfo/iptel