Subject: Extensions to IS-IS and OSPF for Advertising Optional Capabilities

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Dec 2002 16:24:45 -0500

This draft was presented at the 55th IETF OSPF WG. At the meeting,
it was concluded that more discussion was needed prior to deciding
whether or not to accept it as a WG document (and we're currently
trying to finish up at least some items on the charter before accepting
new items). At this time, I'd like to initiate that discussion.

[Speaking as WG member]

As one of the draft authors, I believe the draft is the natural way to
overcome the limitation that we have exhausted the available OSPFv2
LSA options bits. While we can't require existing OSPF features to
use this mechanism, it can be very useful for advertising support
of new features. OSPF PCS (Path Computation Server) discovery will be
the first of the new features using the mechanism.

[End Speaking as WG member]

http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
--
Acee

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 18 Dec 2002 18:25:21 -0500

Hi Acee,

>Date: Wed, 18 Dec 2002 18:09:58 -0500
>To: [email-masked]
>From: Jean Philippe Vasseur <[email-masked]>
>Subject: Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional
>Capabilities
>Cc: Acee Lindem <[email-masked]>
>
>
>>Date: Fri, 13 Dec 2002 18:17:22 -0500
>>To: Mailing List <[email-masked]>
>>From: Jean Philippe Vasseur <[email-masked]>
>>Subject: Re: Extensions to IS-IS and OSPF for Advertising Optional
>>Capabilities
>>Cc: [email-masked]
>>
>>Hi Acee,
>>
>>At 16:24 13/12/2002 -0500, Acee Lindem wrote:
>>I'd like to mention two other applications making use of this draft:
>>
>>1) Auto-mesh TE.
>>
>>The related TLV carried within the OSFP router information LSA defined in
>>draft-raggarwa-igp-cap-01.txt is described in
>>http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt
>>
>>3.2 Mesh-group TLV
>>
>>    As of today, there are different approaches in deploying MPLS
>>    Traffic Engineering:
>>         (1) the systematic approach consisting of setting up a full
>>         mesh of tunnels between P or PE routers, with the objective of
>>         optimizing the bandwidth usage in the core,
>>         (2) the "by exception" approach where a set TE LSPs are set up
>>         on hot spots to alleviate a congestion resulting in an
>>         unexpected traffic growth in some part of the network.
>>
>>    The systematic approach requires setting up a full mesh of TE LSPs,
>>    which implies the configuration of a large number of tunnels on
>>    every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires
>>    the set up of O(n^2) TE LSPs. Furthermore, the addition of any new
>>    LSR in the mesh implies to configure n TE LSPs on the new LSR and to
>>    add a new TE LSP on every LSR ending to this new LSR, which gives a
>>    total of 2*n TE LSPs. This is not only time consuming but also not a
>>    low risk operation for Service Providers. So a more automatic way of
>>    setting up full mesh of TE LSP might be desirable. This requires to
>>    define a new TE capability TLV (called the Mesh-group TLV) such that
>>    an LSR can announce its desire to join a particular TE LSP mesh,
>>    identified by a mesh-group number.
>>
>>I'll publish an informational draft soon detailing some possible
>>deployment scenarios.
>>
>>2) It might also be useful to announce some NSF node property. This will
>>be detailed in another draft.
>>
>>Those two applications, in addition to the Path computation Server
>>discovery mentioned above, make use of draft-raggarwa-igp-cap-01.txt
>>
>>JP.
>>