unsubscribe

["Patricia macedo (NC)" <[e-mail]>]

  -----Original Message-----
  From: Mailing List [mailto:[e-mail]]On Behalf Of Jean
Philippe Vasseur
  Sent: quinta-feira, 6 de Fevereiro de 2003 7:46
  To: [e-mail]
  Subject: Re: OSPF IGP Capabilities Draft


  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