Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional Capabilities

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

Hi Acee,

>Date: Wed, 18 Dec 2002 18:09:58 -0500
>To: [e-mail]
>From: Jean Philippe Vasseur <[e-mail]>
>Subject: Fwd: Re: Extensions to IS-IS and OSPF for Advertising Optional
>Capabilities
>Cc: Acee Lindem <[e-mail]>
>
>
>>Date: Fri, 13 Dec 2002 18:17:22 -0500
>>To: Mailing List <[e-mail]>
>>From: Jean Philippe Vasseur <[e-mail]>
>>Subject: Re: Extensions to IS-IS and OSPF for Advertising Optional
>>Capabilities
>>Cc: [e-mail]
>>
>>Hi Acee,
>>
>>At 16:24 13/12/2002 -0500, Acee Lindem wrote:
>>>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.
>>
>>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.
>>
>>>[End Speaking as WG member]
>>>
>>>
>>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
>>>--
>>>Acee