[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,
I understand and agree with what you are saying. My point was that a) when
PCE is available, the PCE service could be a better way for determining the
outgoing domain border node, and b) per-domain path computation could be
useful even when you have PCE service available.
In other words I was just suggesting an alternative method for per-domain
path computation, that's all.
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.
> > >
> >
> >
> >
> >
>