Subject: [IPTEL] Re: TRIP

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

Spencer,

Thanks for your comments. Below are responses to some of your questions.

Hussein

[email-masked] wrote:
>
> 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)?

Currently, TRIP's design focuses on only on address family: E.164.
However, TRIP is generic enough to support multiple address families in
the future. Different address families may be used by different
applications. Each application/address family may have different
requirements with respect to:
 - which LSs to peer with
 - defining the ITAD topology and boundaries
Permitting the same LS to use different LS-IDs with different peers
makes the above requirements possible. The effect will be like having
multiple logical LSs in the same box.

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

Such capabilities will be very difficult to aggregate, and I prefer to
keep them out of TRIP. Or, if there is real need for such capabilities,
they can be defined as optional attributes in separate drafts, similar
to what has been decided for the cost and capacity attributes.

>
> 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?

I don't think TRIP should address this issue. In some networks TRIP will
be configured to set a new next hop at every intermediate ITAD along the
advertisement route while in other networks TRIP LSs will only when call
routes are aggregated.

>
> 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?

The consensus at the last meeting was to add the community attribute to
TRIP.

>
> 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?

The advertisement path is definitely needed to prevent advertisement
loops. The routed path is useful, because it tracks the actual signaling
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?

What limitations are you referring to?

>
> 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?

Agreed, we'll revise this in a future revision of the draft.

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

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

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

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