Subject: Re: some questions re draft-ietf-iptel-gwloc-framework-04.txt

From: "Matt Squire" <[email-masked]>
Date: Wed, 10 Nov 1999 12:58:12 -0500

>> 
>> Yes it makes sense that LocalPref and MED shouldn't be based on the next
>> hop ITAD along the AdvertisementPath.
>> 
>> However, I don't think it is possible to compute LocalPref and MED based
>> on the next hop ITAD along the RoutedPath, because that next hop ITAD
>> may be several ITAD hops away from the current ITAD in the ITAD
>> topoplogy.
>
>Right, but it is the next hop ITAD in the topology in the
>AdvertisementPath. So, local polciies would tell you whether to use the
>RoutedPath (which Reinaldo wants), or the advertisementpath (which you
>seem to prefer).

In BGP, MED is peer-to-peer.  Changing the meaning of the multi-exit
discriminator in TRIP is needed.  Note that the text is kinda fuzzy here in
many places in the draft, referring to 'multiple connections between two
domains' - not peering connections, and not signalling connections.  

I think all we need to do is to add wording to the effect that the
MultiExitDisc parameter can be included by an LS when it inserts itself as
the next hop, and that the MultiExitDisc parameter should be used by *any*
receiver to discriminate between multiple routes to a particular
destination thru the same first hop domain.  

Is this satisfactory?  

- Matt

Matt Squire
Nortel Networks
innovations.lab
[email-masked]
(919)992-9048

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

---

From: "Hussein F. Salama" <[email-masked]>
Date: Wed, 10 Nov 1999 12:02:11 -0800

> destination thru the same first hop domain.

I think this works. It could be useful if the next (first) hop domain
advertises to the external world multiple routes to the same
destination, and each route has a different next hop signaling server.
Then the MED attribute may be used to prefer one next hop signaling
server over another.

Note also that in Section 6.8.5, the first paragraph needs to be
changed, since now the MED attribute will be propagated from one ITAD to
another without changes as long as the next hop signaling server
attribute does not change.

Hussein

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

---------