[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
Arthi,
I think we are in complete agreement here.
Igor
----- Original Message -----
From: "Arthi Ayyangar" <arthi@juniper.net>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>; <jpv@cisco.com>;
<ccamp@ops.ietf.org>
Sent: Tuesday, October 25, 2005 10:47 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
> Hi Igor,
>
> Just to reiterate what Adrian said, this ID is only intended to cover the
> case where you do not have a PCE.
>
> I do, however, agree with what you say below in "The bottom line".
>
> thanks,
> -arthi
>
>
> > 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.
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >