Jean Philippe Vasseur | 1 Aug 2004 07:07
Picon
Favicon

PCE BOF - Thursday August 5, 13:00 to 15:00

Hi,

Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin <at> psg.com),
Bill Fenner (fenner <at> research.att.com)

BOF Chairs: JP Vasseur (jvasseur <at> cisco.com), Adrian Farrel (adrian <at> olddog.co.uk)

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
Vishal Sharma | 2 Aug 2004 06:18
Picon

RE: draft-rabbat-ccamp-carrier-survey-00.txt [Was RE: Survey draft]

Thanks a lot for your email, and for your several suggestions
pertaining to the carrier survey draft.

We think that there are several good points outlined in
the note below that are worth discussing, and invite other
CCAMPers to provide their inputs, and hope we can have a good
discussion about them.

As we mentioned, we already plan to update the carrier
survey with all of the feedback we have received thus far,
and make the revised survey available.

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk]
> Sent: Saturday, July 24, 2004 10:40 AM
> To: v.sharma <at> ieee.org
> Cc: 'Kireeti Kompella'; Richard Rabbat; Takeo Hamada; k.shindome <at> ntt.com
> Subject: Re: Survey draft
>
>
> OK,
>
> Following your links to extract the specific items for discussion.
>
> [Richard] The purpose is to get feedback on the content, format,
> etc of the
> survey and how to interpret the results.
>
> [Kensuke] I'm interested in not only GMPLS technical aspects but
> SP's deployment examples
> and motivation.
>
> [Vishal] The purpose of a face-to-face discussion will be
> to: discuss the specific points that Kensuke and others have
> raised, to evaluate what further aspects should be covered
> in the survey, and discuss how to interpret the current results.
>
> And your email...
>
> > Basically, the idea is to get feedback from WG discussion (especially
> > from carriers) that is not possible on the ML: focusing on
> > the extent and scope of the survey,  on interpreting its results, and
> > on its usefulness for understanding GMPLS use in carrier networks,
> > which should be of high interest to the WG.
>
>
> So I can construct a list of issues you would like to discuss...
>
> a. (future) content of the survey
> b. format of the survey
> c. how to interpret results
> d. SP deployment examples
> e. SP deployment motivation
> f. usefulness of the survey.
>
> Is this the definitive list, or are there other points?
>
> While I agree that items d and e are fascinating and valuable,
> this is not information
> that will easily be shared in a few moments at the mic. Nor, I
> suspect, is it something
> that SPs would want to share without a lot of careful gloss
> except, perhaps, in a private,
> one-on-one way.
>
> Item c, of course, is premature since we have neither a full set
> of results nor the
> correlation information necessary to interpret them. I'm sure we
> will return to this
> discussion once the survey has been updated, more results have
> been collected, and the
> full responses published.
>
> This leaves us with a, b and f which are all somewhat
> intertwined. Probably b lags behind
> a and f.
>
> So, not unexpectedly, we have two main points of debate: is there
> value in such a survey
> and what should it cover.
>
> The title of the draft is pretty specific about the intent of the
> survey: GMPLS-based
> Shared-Mesh Transport Restoration Strategies. It seems there may
> be some value in
> understanding what the desires and wishes of the SP community is
> in this respect, and at
> least two people on the mailing list agree with you. Others, I'm
> sure, will say that such
> a survey has limited value because it does not expose whether the
> respondent understands
> the trade-offs and practical issues that lurk behind the
> buzz-words (the customer always
> wants a God-box for a very low price).
>
> There has been some discussion that tends to open the survey up
> to the "entirety" of GMPLS
> including all of the functions and features that one might want
> in a network. IMHO such a
> survey is too large and is way out of the scope of what the IETF
> can hope to achieve.
> Ultimately, the IETF is contribution-driven within the scope of
> the WG charters -
> individuals have an opportunity to convene/request new working
> groups, shape the charters,
> and contribute to the work to reach the charter milestones. The
> IESG must be convinced of
> the validity of new work items before they can be accepted. That
> is how the IETF takes the
> measure of what needs to be done and in what order.
>
> Detailed and far-reaching surveys are more the province of
> magazines, but are sometimes
> produced and submitted to the RFC editor as private informational drafts.
>
> One counter-example is the implementation survey which is
> fundamental to the IETF to
> determine how a protocol is working, whether it is accepted, and
> whether the RFC can move
> forward.
>
> The questions you might ask, therefore, are:
>
> 1. Is it helpful to conduct a survey about requirements and expectations
>    for shared mesh recovery?
> 2. What changes/additions are needed to the current questions to
>     achieve this?
> 3. Would it be valuable/meaningful to extend the survey to attempt
>    to understand the plans/desires/expectations of SPs with regard
>    to the whole of GMPLS?
>
> With regard to questions 2 and 3, you might also ask:
>
> 4. Who is prepared to help construct/refine the survey and what
>    form of review of the survey questions would the WG like before
>    the survey is issued?
>
> Now we come to whether this is material for the meeting or the
> mailing list.
>
> I asked...
>
> > > ... and how these issues are well served by a debate in an
> > > open forum.
>
> ...and you have said...
>
> > ... there are specific inputs that can
> > be obtained in a WG meeting discussion that are simply not possible
> > on a ML.
>
> But you omit to say what they are.
>
> You do, however, add...
> > if that was not so, we wouldn't need any IETF meetings!
>
> I am inclined to agree with you on many fronts, but that is just
> my view. It seems to me
> that the value of IETF meetings is vested almost entirely in the
> fact that the authors are
> gathered together in one place for a week and can have
> discussions and debates to forward
> their drafts.
>
> The value of WG meetings seems to be two-fold:
> - It allows quick and rough (non-scientific) polls to be taken with a
>   captive audience. These can be used to give an indication of what
>   questions should be pursued on the mailing list and to gauge a
>   feeling of the WG's opinion. It should be obvious that if the chairs
>   continually sent questions to the list the already poor response
>   would dwindle to nothing.
> - It offers an opportunity for aggrieved or concerned individuals to
>    be sure that they are heard by a large chunk of the WG. It doesn't
>    offer redress or resolution, but it is a better forum for being certain
>    that someone is heard than the mailing list where people are too
>    busy to read all of the emails.
>
> It may also be true and useful that the approach of a meeting
> acts as a spur to an editor
> responsible for a milestone or a WG draft. This is especially
> true if the author knows
> that she will be required to stand up in front of the WG and
> justify why nothing has
> happened for four months.
>
> I originally offered...
>
> > A better way to handle this, I think, is that the draft is
> > mentioned from the chair (as shown in the draft agenda) and
> > that discussions are taken to the list. Hopefully by doing
> > this we can build on your work to produce a survey that helps
> > us understand the deployment desires and motivations of
> > GMPLS-using providers.
>
> It is certainly true that the current debate about the agenda has
> served to raise the
> profile of your draft, although many may have failed to pick up
> on it amidst the noise.
> Nevertheless, it is surely valuable to have the draft brought to
> everyone's attention. I
> would be more than happy to re-state the four questions above and
> direct participants to
> you and/or the mailing list.
>
> With respect to the debate, however, I don't think you have made
> a case for taking up
> meeting time. It would still be my advice to raise the specific
> questions on the mail
> list, instead. I would be happy to raise the questions if you like.
>
> Thanks,
> Adrian
>
> PS. I will be travelling from Sunday until San Diego, and my
> email access may be patchy.
> Please follow up with Kireeti if necessary. (His views are not
> necessarily my views.)
>
> > Hi Adrian,
> >
> > I think some of the important issues to discuss were pointed out
> > in a couple of emails to CCAMP by my co-authors and Kensuke Shindome
> > of NTT.
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00742.html
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00744.html
> >
> > http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00758.html
> >
> > Basically, the idea is to get feedback from WG discussion (especially
> > from carriers) that is not possible on the ML: focusing on
> > the extent and scope of the survey,  on interpreting its results, and
> > on its usefulness for understanding GMPLS use in carrier networks,
> > which should be of high interest to the WG.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:adrian <at> olddog.co.uk]
> > > Sent: Friday, July 23, 2004 5:37 AM
> > > To: Vishal Sharma (E-mail 2)
> > > Cc: 'Kireeti Kompella'
> > > Subject: Survey draft
> > >
> > >
> > > You might forward your cause by sending us a very brief summary
> > > of the issues you want to raise if you had an agenda slot and how
> > > these issues are well served by a debate in an open forum.
> > >
> > > Then we could at least see whether you have a valid point or
> > > explain to you why that is not a good idea.
> > >
> > > Adrian
> > >
> >
> >
>

Adrian Farrel | 2 Aug 2004 22:48
Picon

Agenda and slides

Hi,

Nearly all of the slides are in.
Please browse and plan your questions.

http://www.olddog.co.uk/ccamp-60.htm

Adrian

Adrian Farrel | 2 Aug 2004 22:56
Picon

Agenda and slides for PCE BOF

Hi,

The agenda and slides are on line.
http://www.olddog.co.uk/60/pce/pce.ppt

Please browse.

Adrian

Alessio D'Achille | 2 Aug 2004 23:11
Picon

Diverse inter-region path setup

Dear all,

 

with this mail we would like to focus the attention on the disjoint path computation issue, within the context of inter-area/AS TE.

 

We believe that not addressing the disjoint path computation issue from the start (when looking at inter-area/AS TE) would be quite problematic, since an approach that works for a single inter-area/AS path may not be easily applicable/extendible for diverse path

computation. This observation has been made earlier on ML discussions after the Seoul meeting, but there was no definitive conclusion at that time (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html

and follows). In fact, in our view, the right way to approach this issue would be to develop an approach that that does not provide a solution to setup a single path and then attempts to extend that solution for the diverse path setup case.Rather, a solution

must provide a mechanism to setup disjoint paths, with the single path setup being a

particular case. This is because disjoint path setup is quite likely one of the

more important aspects of inter-region TE, that is important for a no. of applications,

as pointed out in the requirements drafts.

 

We defined such an approach in our draftdraft-dachille-inter-area-path-protection-

00.txt”, discussed in Seoul (59th IETF) and it received many positive comments (see the

minute of the meeting): in many comments it has been marked as an important work, since it addressed a hot issue within the Inter-area/AS topic. Following, the draft has been discussed on the CCAMP ML for about two months Recently we have reviewed our draft (namely draft-dachille-diverse-inter- region-path-setup-00), incorporating the feedbacks received at Seoul and via the CCAMP discussions that followed. Since there are significative changes, we recently asked for a slot during the 60th IETF, just to discuss the new version (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html).

 

We would like to address two main themes:

 

i) clarifing why an approach to achieve diverse path setup from the

start is now not considered in the inter-region TE solutions,

notwithstanding it seems to be the right approach to the issue, as

observed in prior ML discussion and in requirement drafts.

 

ii) Since we believe that draft-dachille satisfies all the

requirements for work to be discussed at a WG meeting

(http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html),

we would appreciate clarification about the reasons that led to the

exclusion of this work from the SD agenda.

 

Thank you for your kind attention; we hope that the discussion about

this issue could continue in a productive manner, just as usual.

 

Best Regards,

 

Alessio D’Achille

 

Adrian Farrel | 3 Aug 2004 02:58
Picon

Re: Diverse inter-region path setup

Hi,

Kireeti plans to spend ten minutes discussing the strategy for inter-domain TE work within
CCAMP. This is on the agenda at:
- Inter-Area/AS
   - Strategy (Kireeti) (10 minutes)

We hope that he will answer your questions at that time and outline the way forward.
Of course, we will welcome a brief discussion of the right way to proceed at that time.

Thanks,
Adrian

----- Original Message ----- 
From: "Alessio D'Achille" <alessiored <at> fastwebnet.it>
To: <ccamp <at> ops.ietf.org>
Cc: <adrian <at> olddog.co.uk>; "Kireeti Kompella" <kireeti <at> juniper.net>; "Vishal Sharma"
<v.sharma <at> ieee.org>; "Ugo Monaco" <monaco <at> infocom.uniroma1.it>; "Fabio Ricciato"
<ricciato <at> coritel.it>; "Marco Listanti" <marco <at> infocom.uniroma1.it>
Sent: Monday, August 02, 2004 10:11 PM
Subject: Diverse inter-region path setup

> Dear all,
>
> with this mail we would like to focus the attention on the disjoint path
> computation issue, within the context of inter-area/AS TE.
>
> We believe that not addressing the disjoint path computation issue from
> the start (when looking at inter-area/AS TE) would be quite problematic,
> since an approach that works for a single inter-area/AS path may not be
> easily applicable/extendible for diverse path
> computation. This observation has been made earlier on ML discussions
> after the Seoul meeting, but there was no definitive conclusion at that
> time ( <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
> http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> and
> follows). In fact, in our view, the right way to approach this issue
> would be to develop an approach that that does not provide a solution to
> setup a single path and then attempts to extend that solution for the
> diverse path setup case.Rather, a solution
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> must provide
> a mechanism to setup disjoint paths, with the single path setup being a
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> particular
> case. This is because disjoint path setup is quite likely one of the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> more
> important aspects of inter-region TE, that is important for a no. of
> applications,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> as pointed
> out in the requirements drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> We defined
> such an approach in our draft
> "draft-dachille-inter-area-path-protection-
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> 00.txt",
> discussed in Seoul (59th IETF) and it received many positive comments
> (see the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00336.html> minute of
> the meeting): in many comments it has been marked as an important work,
> since it addressed a hot issue within the Inter-area/AS topic.
> Following, the draft has been discussed on the CCAMP ML for about two
> months Recently we have reviewed our draft (namely
> draft-dachille-diverse-inter- region-path-setup-00), incorporating the
> feedbacks received at Seoul and via the CCAMP discussions that followed.
> Since there are significative changes, we recently asked for a slot
> during the 60th IETF, just to discuss the new version
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html).
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> We would
> like to address two main themes:
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> i) clarifing
> why an approach to achieve diverse path setup from the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> start is now
> not considered in the inter-region TE solutions,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> notwithstanding it seems to be the right approach to the issue, as
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> observed in
> prior ML discussion and in requirement drafts.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> ii) Since we
> believe that draft-dachille satisfies all the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html> requirements
> for work to be discussed at a WG meeting
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00720.html>
> (http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html),
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> we would
> appreciate clarification about the reasons that led to the
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> exclusion of
> this work from the SD agenda.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Thank you
> for your kind attention; we hope that the discussion about
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> this issue
> could continue in a productive manner, just as usual.
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Best
> Regards,
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html> Alessio
> D'Achille
>  <http://ops.ietf.org/lists/ccamp/ccamp.2004/msg00746.html>
>

Sergio.Belotti | 3 Aug 2004 10:19
Picon
Picon

Re: Agenda and slides

Adrian,
I do not know whether someone in the ccamp community has the same problem,
but I wasn't be able neither yesterday nor today to retrieve the slides
since I cannot reach the web site indicated (www.olddog.co.uk)
Can you help  me somehow to solve the problem ?

Thanks in advance

Sergio
_________________________________________________
Sergio Belotti
ALCATEL OND  Product Strategy

E-mail: sergio.belotti <at> alcatel.it
tel : +39 039 686 3033
fax: +39 039 686 3590

                                                                                                                                
                      "Adrian Farrel"                                                                                           
                      <adrian <at> olddog.c         To:      <ccamp <at> ops.ietf.org>                                                    
                      o.uk>                    cc:                                                                              
                      Sent by:                 Subject: Agenda and slides                                                       
                      owner-ccamp <at> ops.                                                                                          
                      ietf.org                                                                                                  

                                                                                                                                
                      02/08/2004 22.48                                                                                          
                      Please respond                                                                                            
                      to "Adrian                                                                                                
                      Farrel"                                                                                                   

Hi,

Nearly all of the slides are in.
Please browse and plan your questions.

http://www.olddog.co.uk/ccamp-60.htm

Adrian

Greg Bernstein | 3 Aug 2004 20:57
Picon
Favicon

Agenda, LMP for Transport

Adrian thank for posting all the presentations and
drafts to be discussed. This really helps those of us
who are short on time and can't be in beautiful San
Diego this August.

It also brought the "LMP for transport" draft to my
attention.  I worked a lot on discovery and had lots
of arguments with folks on what LMP does and does not
do.

This draft clears things up very well. In particular
the fact that G.7714 is concerned with "data plane"
and not control plane discovery and that both are
extremely important for a functioning GMPLS control
plane.  

In a move toward more "plug and play" it would nice to
see a procedure that bootstraps from the data plane
discovery (which should be available once equipment is
turned on and lasers are shining) to the control plane
procedure (e.g., furnishes IP addresses for use in
control plane "channel" set up). 

Small nit to the authors, remove the reference to the
OC-3c in one of the examples and replace with either
an OC-3 or STS-3c.   

Greg B.

Dr. Greg M. Bernstein
Grotto Networking

		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Nagao Ogino | 4 Aug 2004 16:55
Picon
Favicon

draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt

Hi Arthi and Jean Philippe,

I have read your important draft titled "Inter domain MPLS Traffic 
Engineering- RSVP-TE extensions".
Your draft mentions MPLS-TE Fast Reroute for the inter-domain TE LSPs, and 
I have a question on the Fast Reroute in the inter-provider environment.

In the inter-provider case, each provider may confide the Route Record 
information of the inter-provider TE LSP established through the provider.
That is to say, each provider may not desire to disclose the route 
information within the provider.
(This may also need an extension of the RRO processing in the inter-domain 
RSVP-TE signaling.)

If so, the PLR  cannot recognize the NNHOP (MP) in the protection of the 
boundary LSR at the entry to a domain.
In your example topology, ASBR1 cannot recognize R3 and ASBR7 in the 
protection of ASBR4.
Thus, the PLR cannot establish the detour LSP because it has no information 
on the destination address of the detuor LSP.
In the same way, the PLR cannot find the bypass tunnel terminating at the 
NNHOP because it has no information on the NNHOP.

I thought that one of the solutions may be to establish the detour LSP in 
the reverse direction from the NNHOP to the PLR, and the NNHOP searches for 
the bypass tunnel terminating at the PLR. Those are possible because the 
NNHOP can recognize the PLR thanks to the advertisement of the 
inter-provider links.
In your example topology, R3 and ASBR7 can recognize ASBR1 thanks to the 
advertisement of the inter-provider link connecting ASBR1 and ASBR4.

In the protection of the boundary LSR at the exit of a domain, there is no 
problem because the PLR can recognize the NNHOP by the advertisement of the 
inter-provider links.

Is my understanding correct? Does my thought have a meaning?

Best regards,

Nagao Ogino
KDDI R&D Laboratories Inc. 

lidefeng | 5 Aug 2004 02:53
Favicon

Re: PCE BOF - Thursday August 5, 13:00 to 15:00

Hi,
 
I think it is very necessary to do this work in IETF, Service Providers in China also expressed such requirements during the technical exchanges.
 
I have delved into PCE.ppt in the link, however, I can't find the following drafts, If anyone can share with me? Could you please send me these drafts in e-mail, Thanks!
 
draft-mescal-pce-interas-00.txt
draft-mescal-pcp-interas-00.txt
draft-mescal-pceid-00.txt
 
Best Regards
Defeng Li 
----- Original Message -----
Sent: Sunday, August 01, 2004 1:07 PM
Subject: PCE BOF - Thursday August 5, 13:00 to 15:00

Hi,

Just to let you know that the set of slides for the PCE BOF will be available next Monday morning (http://www.olddog.co.uk/60/pce.ppt)

Cheers,

JP and Adrian.

Path Computation Element BOF (PCE BOF)
60th IETF, San Diego, August 2004

Routing Area Ads: Alex Zinin (zinin <at> psg.com),
Bill Fenner (fenner <at> research.att.com)

BOF Chairs: JP Vasseur (jvasseur <at> cisco.com), Adrian Farrel (adrian <at> olddog.co.uk)

Description:
In certain MPLS TE networks it may be beneficial or desirable to have path
computation performed by a distinct node (termed the Path Computation
Element PCE) that is not the LSR that needs to know the path. This BOF
examines the scope of such function, what extensions to existing protocols
might required, what additional protocols may need to be developed, and
whether there is cuase and support for this work within the IETF.

Proposed WG Charter

Organizational Overview
The PCE working group coordinates the work within the IETF of defining the
operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer of
such paths might be an MPLS-TE LSR. Areas of responsibility will include
the collection of attributes relevant to the computation of paths, the
discovery by LSRs of available path computation elements, the communication
with LSRs for the request of path computation, the collaboration between
path computation elements within the network, and analysis of path
computation algorithms with a view to ensuring consistency between computed
paths. The working group will work closely with many working groups in the
Routing Area including the OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

Working Group Scope

The PCE working group scope includes:
- Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the intra
IGP area, inter IGP area, inter-AS and inter-provider TE LSPs path
computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
- Definition of protocol-independent metrics and constraints defining path
quality measurement criteria, algorithm complexity and scalability criteria
related to path computation techniques.
- Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques within
an IGP area and across multiple IGP areas, ASes and Provider networks, and
including the development of new protocols or protocol extensions for
requesting path computation and supplying responses. Any protocol
extensions will developed in conjunction with the working groups in charge
of the specific protocols.
- Specification of routing (OSPF, ISIS, BGP) and signalling extensions
(RSVP-TE) required by PCE-based path computation techniques. The extensions
will developed in conjunction with the working groups in charge of the
specific protocols.
- Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path computation
techniques involving PCEs of multiple Providers.
- Definition of MIBs, management procedures related to the protocol
extensions defined by the WG
In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

Goals and Milestones
Dates for milestones to be decided later.
- Post strawman WG goals and charter.
- Submit WG document defining the framework and applicability of the
PCE model.
- Select a single candidate protocol from communication between LSRs
and PCEs.
- Submit document(s) that define various path computation models
- Submit an analysis document examining the requirements for coherent
computation techniques and the implication of cooperation between
PCEs.
- Submit a document defining the protocol for communication between
LSRs and PCEs.
- Submit document(s) defining extensions to routing and signalling
protocols necessary to support the use of a PCE model within MPLS
networks.
- Submit a document defining MIB modules for modeling and management
of PCE systems.

Gmane