[rfc-dist] BCP 87, RFC 3785 on Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric

rfc-editor at rfc-editor.org rfc-editor at rfc-editor.org
Fri May 28 13:45:29 PDT 2004


A new Request for Comments is now available in online RFC libraries.


        BCP 87
        RFC 3785

        Title:      Use of Interior Gateway Protocol (IGP) Metric
                    as a second MPLS Traffic Engineering (TE) Metric
        Author(s):  F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx,
                    T. Telkamp
        Status:     Best Current Practice
        Date:       May 2004
        Mailbox:    flefauch at cisco.com, ruppili at cisco.com,
                    alain.vedrenne at equant.com,
                    pierre.merckx at equant.com, telkamp at gblx.net
        Pages:      8
        Characters: 17475
        SeeAlso:    BCP 87

        I-D Tag:    draft-ietf-tewg-te-metric-igp-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3785.txt


This document describes a common practice on how the existing metric
of Interior Gateway Protocols (IGP) can be used as an alternative
metric to the Traffic Engineering (TE) metric for Constraint Based
Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering
tunnels.  This effectively results in the ability to perform
Constraint Based Routing with optimization of one metric (e.g., link
bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks)
while optimizing another metric (e.g., propagation delay) for some
other tunnels with different requirements (e.g., Voice Trunks).  No
protocol extensions or modifications are required.  This text
documents current router implementations and deployment practices.

This document is a product of the Internet Traffic Engineering Working
Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info at RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR at RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative


More information about the rfc-dist mailing list