Re: OSPF IGP Capabilities Draft

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

Hi Abbay,

See in line,

At 17:26 01/02/2003 -0500, Acee Lindem wrote:
>Abhay Roy wrote:
>>Acee,
>
>Hi Abhay,
>
>>
>>One of the questions raised was, why do we need to advertise these
>>capabilities? I am glad to see that, there is at least one useful
>>application (as in PCSD).
>
>Yes and I think there will be others in the future.

Right, just to mention another one (also related to TE): the mesh-group ID,
used to determine to set of LSRs belonging to a common TE mesh.

See 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 try to publish a informational draft detailing the applicability.


>>I still have those reservations about the usefulness of many other
>>'capabilities' this document describes. IMHO, if the receivers of
>>these capabilities are just going to display it in a 'show'
>>command, we should NOT specify them in this document.
>
>Since these are existing mechanisms we really can't make the
>receivers have any dependence on them. However, I'm not sure
>that is a reason not to allow the bits to be advertised with
>other router capabilities which are dependent on the
>IGP capabilities mechanism.

Agree.

JP.


>>Regards,
>>-Roy-
>>
>>On 01/30/03-0500 at 9:28pm, Acee Lindem writes:
>>
>>
>>>As many of you recall, we've discussed this draft at both
>>>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama
>>>but apparently there were some present who voiced reservations
>>>with the draft. In Atlanta, there wasn't a lot of discussion (other
>>>than strong support from the authors ;^). We agreed to discuss this
>>>draft further on the OSPF list.
>>>
>>>Are there still people who have reservations with the draft?
>>>
>>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt
>>>
>>>[Speaking as a WG member]
>>>
>>>I think the draft is a natural mechanism for advertising new OSPF
>>>capabilities now that the LSA option bits have been exhausted.
>>>We've already extended OSPF to support traffic engineering (TE)
>>>information and this mechanism is slated to be used for propagating
>>>an OSPF router's ability to act as an MPLS TE path computation
>>>server (PCS).
>>>
>>>Thanks,
>>>--
>>>Acee
>>
>
>
>--
>Acee