Hi David, At 10:01 10/03/2003 -0500, David Charlap wrote:
This is just one of the aspects of inter-AS, there are many others listed in the inter-AS requirements drafts. The point that Kenji wanted to make was that the current set of protocols for intra-AS TE does not allow to address all the requirements listed in the requirements drafts. I just dropped on the TE WG mailing list another email mentioning some of the required protocol extensions.Kenji Kumaki wrote:What makes you say that?I think the latter is correct. We need to extend a existing protocol(e.g. RSVP-TE) because a current RSVP-TE can't cover an inter-AS TE.
I don't think current implementations can support this. But RFC 3209 includes inter-AS provisions.
See section 7.4.
One of the EXPLICIT_ROUTE subtypes is an AS number. If one of these is present in an EXPLICIT_ROUTE object, then the abstract node represented is the entirity of the specified ASN.
Implementations should treat this in a similar fashion to how they treat an IP subnet ERO subobejct. If it's the first subobject, then the router must be in that ASN. If it's the subobject corresponding to the next-hop, then it should use that ASN to determine the next hop along the path to that ASN. If the node is strict, then the next-hop address should be a part of that ASN.
I'm not sure if BGP provides sufficient information for generating a topology of ASNs (needed for generating an AS-hop-path). An extension of some form might be necessary for this to work. But that would be a routing extension, not an RSVP extension. And it would only be necessary if you want to dynamically generate inter-AS explicit routes - a feature of dubious utility to begin with.Similarly to the inter-area TE case, there are several possible solutions there: we proposed some two of them in the following drat:draft-vasseur-inter-as-te-00.txt
-- David