Re: Route Exclusion

["Adrian Farrel" <[e-mail]>]

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)
- 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
> >
> >
> >
>