Re: Route Exclusion

[Jean Philippe Vasseur <[e-mail]>]

Hi Adrian,

At 03:16 PM 6/10/2003 -0400, Adrian Farrel wrote:
>All,
>
>Ron has asked me to post a summary of where this work fits into the WG and,
>unless there are objections within the next couple of days, to post the 
>existing
>draft
>(http://www.ietf.org/internet-drafts/draft-lee-ccamp-rsvp-te-exclude-route-02.tx
>t) without revisions, as a WG draft.
>
>This is a third last chance to object :-)
>
>The draft specifies ways to communicate route exclusions during path setup 
>using
>RSVP-TE.
>Route exclusions are useful when full path computation is not performed at the
>head of an LSP. This happens when
>- an external route server is used (see
>draft-vasseur-mpls-path-computation-rsvp-te)

note that the PCS is always external ;-) Anyway, this gives me the 
opportunity to mention something that I told you off-line: the draft 
mentioned above does specify an EXCLUDE-ELEMENT object which has the same 
objective as your draft. I'll remove it from the next revision and I agree 
to support your draft.

JP.

>- there are domains of computation (such as, but not limited to, areas and 
>ASs)
>- loose hops or non-specific abstract nodes are used.
>
>Route exclusion allows the LSP requester to communicate the requirement to 
>avoid
>nodes, links, resources or SRLGs. This may result from
>- user requests in the MPLS-TE-MIB (see draft-ietf-mpls-te-mib)
>- protection diversity requirements (see
>draft-ietf-ccamp-gmpls-recovery-analysis etc.)
>- crankback and local repair avoidance of errored or blocked resources (see
>draft-iwata-mpls-crankback)
>
>Applicability is to packet and non-packet networks. MPLS and GMPLS.
>
>Requirements also come from
>- the ITU-T's ASON architecture (see draft-ietf-ccamp-gmpls-ason-reqts)
>
>Value is present in single area/AS systems. The concept is also applicable to
>multi-area/multi-AS TE.
>
>With regard to the *existing* CCAMP charter, this work is covered by many 
>of the
>charter items, but best by:
>- Define signalling protocols and measurement protocols such that they
>   support multiple physical path and tunnel technologies
>- Abstract link and path properties needed for link and path
>   protection.
>   Define signalling mechanisms for path protection, diverse routing and
>   fast path restoration.  Ensure that multi-layer path protection and
>   restoration functions are achievable using the defined signalling and
>   measurement protocols, either separately or in combination.
>
>It is possible that the revised charter will include
>- multi-area/multi-AS
>- explicit recognition of the ASON requirements
>
>Further details can be found in the draft.
>The authors would be happy (sic) to answer any questions, preferably on the
>list.
>
>Adrian
>
>----- Original Message -----
>From: "Ron Bonica" <[e-mail]>
>To: "Adrian Farrel" <[e-mail]>; "'Kireeti Kompella'"
><[e-mail]>; <[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>
>Sent: Thursday, May 29, 2003 11:06 AM
>Subject: RE: Route Exclusion
>
>
> > Folks,
> >
> > Are there any objections to adopting the route exclusion draft as a WG 
> item?
> > If so, please post them to the mailing list by June 5. If not, CCAMP will
> > adopt the draft as a WG item.
> >
> >                                                  Ron
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Tuesday, May 27, 2003 3:57 PM
> > > To: 'Kireeti Kompella'; Ron Bonica; [e-mail]
> > > Cc: [e-mail]; [e-mail]; Adrian
> > > Farrel
> > > Subject: Route Exclusion
> > >
> > >
> > > Kireeti, Ron,
> > >
> > > You may recall that at SF there was a surprisingly large number
> > > of people (30+)
> > > who had read this draft and expressed an interest. (In today's
> > > climate, it seems
> > > unusual if all of the authors have read a draft!)
> > >
> > > We (the authors) are also seeing a fair bit of interest expressed
> > > to us from
> > > people who need the function and want to go ahead and start
> > > implementing - they
> > > want to know what the future of the draft is. At the same time,
> > > the ASON work
> > > seems to be pulling in this requirement, and I shouldn't be surprised if
> > > multi-area/multi-domain/multi-AS decides it is a requirement, too.
> > >
> > > So the question for you is, what do we do with this draft?
> > >
> > > There appear to be three possibilies:
> > >
> > > 1. The draft becomes a WG draft in the near future, and continues
> > > to develop
> > > with input from the WG.
> > >
> > > 2. The authors continue to spend their efforts on the draft with
> > > no particular
> > > IETF target in sight and without the GMPLS community having any realistic
> > > expectation of the draft going anywhere. Other standards bodies,
> > > needing the
> > > function, develop their own alternatives and so on...
> > >
> > >  3. The authors bring the draft forward as an individual
> > > submission to the IESG.
> > >
> > >  Well, you can guess which I think is the best idea.
> > >
> > > What do you think?
> > >
> > > Cheers,
> > > Adrian
> > >
> > >
> > >
> >