Subject: [IPTEL] TRIP

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:21 +0530

Group,

I read the TRIP draft, and I had some thoughts and questions:

Section 5.2 (LS-IDs)
Will TRIP use BGP "peering" statements? if not, would being able to have
different LS-IDs be confusing or cause network (config) problems?
What is the advantage of having different LS-IDs if you are not peering
Differently (using peering statements)?

Section 5.2.1.1, (IPSec)
Is there any reason TRIP _couldn't_ rely on IPSec for security? Conversely,
what about
implementations that don't support IPSec? There might be a problem with
problem re-hashing changing headers, etc, though I think the IPv6 specs
address that. Would TRIP's specification seem incomplete without security
of it's own?

Section 5.2.1.2, (Capabilities)
Might we define more "defined capabilities" around the types of service
needed by the end stations, or perhaps the throughput of the end station's
connection? The way GARP does this is interesting.

Section 5.3.3.2, (next-hop)
Being able to set the next-hop is nice, but would there be confusion
pertaining to how next-hop should be implemented? Are the current
the definition of default behaviors specific enough?

Section 5.3.4.7 (community)
Why _wouldn't_ we want the community attribute? TRIP relies on many BGP
features, why not use this one as well?

Section 6.3.1 (port addresses)
In my opinion, I it is not necessary to have a subnetwork_address_field.
However, I do think that next hop ITAD should be included, as filtering,
etc
may be based on this.

Section  6.5 (routed path)
I can see how a "routed path" might be more useful than an "advertisement
path".
Wouldn't one always prefer to know the path the _will_ be taken? Does TRIP
need both advertisement path _and_ routed path?

Would the Routed Path attribute be more useful if we relax some of the
limitations on when an LS can change it (update the path), allowing
it to be used more often?

Section 6.9
Agree with updating topology when peer sets change, not using an intra-ITAD
keepalive.

Terminology
Is it confusing for the TRIP spec use the term "route" when referring
to "call" routes _and_ IP routes?

Spencer Giacalone

---------
This message came from the IETF IPTEL Working Group Mailing List.

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel