[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
Adrian,
On a closer look:
> In the cases you raise:
> 1. Yes, an interface address may be unreachable.
> Do we lose anything by consulting IP reachability in this case?
> No.
This is not what I was talking about, which was a destination located in
some remote domain and TE reachable to the source while not IP routable
(because destination is a numbered link ID, this is a very usual case in a
multi-area GMPLS non-packet network). The only guy who would know about such
destination is a PCE with sufficient TE visibility. There is no point in
such case to consult IP routing and we do loose by doing so rather than
consulting PCE (provided, of course, that PCE is available)
> 2. Yes, the IP reachability may give us a sub-optimal TE path.
> Is this path worse than no path?
> No.
Again, the path provided by IP has nothing to do with the TE path, and PCE
is certainly in a better position to provide (albeit loose) path specifying
a list of proper border nodes or just the next border node.
The bottom line: when PCE is available one should never consult IP routing
to determine the outgoing border node when one performs per-domain path
computation. If PCE is not available, than in case of IP network, I agree,
there is a value to consult IP routing. This is because in IP world TE
resources are still tightly coupled with IP interfaces. In the non-IP world,
I'd say, consulting IP routing makes much lesser sense: it could give you a
path when no TE path exists or, more importantly, fail the request when one
or more TE paths do exist. I'd suggest in this case rather than consulting
IP (which is as useful IMO as consulting somebody's Outlook address book) to
route the LSP towards any known domain border node and hope that the latter
will crankback the request specifying the proper border node if necessary.
Cheers,
Igor
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Igor Bryskin" <ibryskin@movaz.com>; <jpv@cisco.com>; "Arthi Ayyangar"
<arthi@juniper.net>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, October 21, 2005 2:20 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> Hi Igor,
>
> I think you have to set the context of this I-D carefully, and then
> understand the limited scope that is additionally proposed.
>
> The context of the I-D is limited to the per-domain computation case.
> Hence, consulting an external PCE is out of scope. This is not to say that
> it is not valid to consult a PCE (in fact, you might expect JP and me to
> support that technique), but this I-D is demonstrating what we can do and
> how we can solve the problem without using PCE.
>
> With respect to the use of the IP reachability, you may recall that I
> raised this concern in Paris and on the list. The conclusion was that if
> you have no other way of determining an exit router for your domain, then
> attempting to use the IP reachability is no worse than giving up, and may
> be much better.
>
> In the cases you raise:
> 1. Yes, an interface address may be unreachable.
> Do we lose anything by consulting IP reachability in this case?
> No.
> 2. Yes, the IP reachability may give us a sub-optimal TE path.
> Is this path worse than no path?
> No.
>
> So I asked the authors to be clear that what they are suggesting has
> limitations, and should not be applied in some specific cases. I haven't
> looked at the text yet, but I hope they have covered this.
>
> Cheers,
> Adrian
> ----- Original Message -----
> From: "Igor Bryskin" <ibryskin@movaz.com>
> To: <jpv@cisco.com>; "Arthi Ayyangar" <arthi@juniper.net>
> Cc: <ccamp@ops.ietf.org>
> Sent: Friday, October 21, 2005 4:27 PM
> Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
>
>
> > Arthi, JP
> >
> >
> >
> > I have a problem with the auto-discovery mechanism you described in the
> > draft (one that is based on query to IGP or BGP to determine outgoing
> > ABR/ASBR).
> >
> >
> >
> > 1. Destination ID must be network unique but it does not have to be IP
> > routable, for example, it could be a numbered link ID.
> >
> > 2. Even in case when destination is IP address, the path computing node
> can
> > only obtain the ID of an ABR or ASBR that advertises IP route to the
> > destination, which would be one that knows about the shortest IP path to
> the
> > destination. However, it does not mean that properly constrained TE path
> > from this ABR/ASBR to the destination or the next ABR/ASBR exist, or is
> not
> > suboptimal compared to one from some other ABR/ASBR which knows about
> worse
> > IP path to the destination and hence will not be reported to the
> computing
> > entity by the routing sub-system.
> >
> >
> >
> > I wonder why not to use the remote PCE service for this purpose. For
> > instance a PCC may ask a PCE to determine either the ID of the outgoing
> > domain border node or entire path in terms of domain border nodes. You
> may
> > ask why not to request explicit path(s) in this case? Several reasons
> why
> > the PCC wouldn't want to do so:
> >
> >
> >
> > a) it could be easier and faster for the PCE to determine domain border
> node
> > in direction towards the destination rather than explicit path(s). For
> > instance, the latter may require cooperation of other PCEs;
> >
> >
> >
> > b) security considerations - PCE may not want to reveal remote domain
> > topology(ies)
> >
> >
> >
> > c) it may be desirable to compute and setup services on per-domain
> basis,
> > for instance, to have each domain take separate care for service
> > restoration.
> >
> >
> >
> > What do you think?
> >
> >
> >
> > Igor
> >
> >
> >
> > ----- Original Message -----
> >
> > From: <Internet-Drafts@ietf.org>
> >
> > To: <i-d-announce@ietf.org>
> >
> > Cc: <ccamp@ops.ietf.org>
> >
> > Sent: Thursday, October 20, 2005 6:50 PM
> >
> > Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> >
> >
> >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > > This draft is a work item of the Common Control and Measurement Plane
> > Working Group of the IETF.
> > >
> > > Title : A Per-domain path computation method for establishing
> > > Inter-domain Traffic Engineering (TE) Label
> > Switched Paths (LSPs)
> > > Author(s) : J. Vasseur, et al.
> > > Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> > > Pages : 18
> > > Date : 2005-10-20
> > >
> > > This document specifies a per-domain path computation technique for
> > > establishing inter-domain Traffic Engineering (TE) Multiprotocol Label
> > > Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths
> > > (LSPs). In this document a domain refers to a collection of network
> > > elements within a common sphere of address management or path
> > > computational responsibility such as IGP areas and Autonomous Systems.
> > >
> > > Per-domain computation applies where the full path of an inter-domain
> > > TE LSP cannot be or is not determined at the ingress node of the TE
> > > LSP, and is not signaled across domain boundaries. This is most likely
> > > to arise owing to TE visibility limitations. The signaling message
> > > indicates the destination and nodes up to the next domain boundary. It
> > > may also indicate further domain boundaries or domain identifiers. The
> > > path through each domain, possibly including the choice of exit point
> > > from the domain, must be determined within the domain.
> > >
> > > A URL for this Internet-Draft is:
> > >
> >
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a message to
> > > i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the
> > message.
> > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > > "get draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > > mailserv@ietf.org.
> > > In the body type:
> > > "FILE
> /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > > MIME-encoded form by using the "mpack" utility. To use this
> > > feature, insert the command "ENCODING mime" before the "FILE"
> > > command. To decode the response(s), you will need "munpack" or
> > > a MIME-compliant mail reader. Different MIME-compliant mail readers
> > > exhibit different behavior, especially when dealing with
> > > "multipart" MIME messages (i.e. documents which have been split
> > > up into multiple messages), so check your local documentation on
> > > how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> >
> >
> >
>