Subject: TRIP

From: [email-masked]
Date: Fri, 14 Jan 2000 11:09:30 -0500

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.

---

From: "Hussein F. Salama" <[email-masked]>
Date: Fri, 14 Jan 2000 11:31:17 -0800

Spencer, 

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

Hussein

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

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

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

> features, why not use this one as well?

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

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

> it to be used more often?

What limitations are you referring to?

> to "call" routes _and_ IP routes?

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

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

---------

---

From: "Matt Squire" <[email-masked]>
Date: Wed, 19 Jan 2000 20:07:31 -0500

A couple additional comments...

> > address that. Would TRIP's specification seem incomplete without security

We couldn't come up with any reason why IPSEC couldn't be relied on for
security, except of course if an implentation that didn't support it. 
In the upcoming draft, we've removed references to bgp authentication
mechanisms, added some text for signing individual attributes (what we
called 'next-hop security' at the last ietf), but have yet to really
address the use of IPSEC with regards to the keying issues.  That should
come in the next round I hope.  

> > However, I do think that next hop ITAD should be included, as filtering, etc

This is pretty much what we went with in the upcoming version.  

- Matt

---------