[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-vasseur-mpls-ospf-pcsd-discovery-00.txt
Hi,
NAME OF I-D:
OSPF Path Computation Server discovery
SUMMARY
This draft proposes an OSPF extension for a router to announce its
Path Computation Server capability used in the context of MPLS
Traffic Engineering. This draft defines a new opaque LSA called PCSD
(Path Computation Server Discovery). The PCSD LSA has a variable
length and is made of a set of TLVs.
RELATED DOCUMENTS:
None
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK:
This document specifies OSPF extensions in support of MPLS Traffic
Engineering. It relates to the work on off-load computation of
Traffic Engineering Label Switch Path covered by CCAMP.
This document fits into CCAMP WG.
WHY IS IT TARGETED AT THIS WG
This addresses specific items of the CCAMP WG charter.
From the CCAMP WG Charter:
"- Define signalling protocols and measurement protocols such that they
support multiple physical path and tunnel technologies (e.g. O-O and O-E-O
optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from
technology-specific working groups such as MPLS, IPO, etc.
- Define signalling and measurement protocols that are independent of each
other. This allows applications other than the signalling protocol to use
the measurement protocol; it also allows the signalling protocol to use
knowledge obtained by means other than the measurement protocol.
..."
JUSTIFICATION
The draft directly addresses items of the charter.
Many thanks in advance.
Best regards.
JP.
Internet draft draft-vasseur-mpls-ospf-pcsd-discovery-00.txt June 2002
Network Working Group JP Vasseur
Internet Draft Peter Psenak
Document: draft-vasseur-mpls-ospf-pcsd-discovery- Cisco Systems, Inc
00.txt
IETF Internet Draft
Expires: December, 2002
June 2002
OSPF Path Computation Server discovery
draft-vasseur-mpls-ospf-pcsd-discovery-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft proposes an OSPF extension for a router to announce its
Path Computation Server capability used in the context of MPLS
Traffic Engineering. This draft defines a new opaque LSA called PCSD
(Path Computation Server Discovery). The PCSD LSA has a variable
length and is made of a set of TLVs.
1. Where does this draft fit in the picture of the Sub-IP work
This document specifies OSPF extensions in support of MPLS Traffic
Engineering. It relates to the work on off-load computation of
Traffic Engineering Label Switch Path covered by CCAMP.
Vasseur and Psenak 1
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
2. Terminology
Terminology used in this draft
LSR: Label Switch Router
PCS: Path Computation Server (may be an LSR (ABR, ASBR, ...) or a
dedicated path computation server (typically a UNIX machine) not
forwarding packet.
PCC: Path Computation Client (any head-end LSR) requesting a path
computation to the Path Computation Server.
TE LSP: Traffic Engineering Label Switched Path
Head-end TE LSP: head/source of the TE LSP
Tail-end TE LSP: tail/destination of the TE LSP
Intra-area TE LSP: TE LSP whose head-end and tail-end reside in the
same area
Inter-area TE LSP: TE LSP whose head-end and tail-end reside in
different areas (the TE LSP spans areas)
Inter-AS TE LSP: TE LSP whose head-end and tail-end reside in
different Autonomous Systems (the TE LSP spans AS)
3. Introduction
This draft specifies a new OSPF opaque LSA called PCSD LSA for the
Auto-discovery of one or more Path Computation Server(s). In various
situations, an LSR may send a request to a Path Computation Server
(PCS) to compute one or more Traffic Engineering LSP paths obeying a
set of specified constraints.
[4] specifies RSVP extensions:
- for a PCC to send path computation requests to a PCS to
compute TE LSP(s) obeying a set of specified constraints,
- for the PCS to provide to the PCC one or more computed paths
obeying the set of constraints (or to return an indication
mentioning no path obeying the constraints could be found).
The scope of this document is to define a new OSPF opaque LSA such
that a LSR/centralized path computation tool may announce its
capability to be a Path Computation Server within an area or an
Autonomous System.
This allows every LSR in the network to automatically discover the
Path Computation Server(s), which substantially simplifies the head-
Vasseur et Psenak 2
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
end LSR configuration. Moreover, this allows to detect dynamically
any new PCS or that a PCS is no longer active.
4. PCSD LSA Packet format
4.1 PCSD LSA Header
The OSPF PCSD LSA is an opaque LSA (type 10 or type 11). As defined
in RFC2370, an opaque LSA header has the following form:
Header format of the PCSD LSA:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opaque type TBD| Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCSD LSA uses opaque type [TBD by IANA].
The Opaque ID is used for LSA instantiation and allows a single
system to generate multiple PCSD LSA. It has no particular
significance.
4.2 PCSD LSA payload
The PCSD LSA payload is made of a set of non ordered TLVs each
having the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Vasseur et Psenak 3
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
Type: identifies the TLV type
Length: length of the value field in octets
The TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of
three, but the total size of the TLV would be eight octets). Nested
TLVs are also 32-bit aligned. Unrecognized types are ignored. All
types between 32768 and 65535 are reserved for vendor-specific
extensions. All other undefined type codes are reserved for future
assignment by IANA.
A TLV may itself contain one or more sub-TLVs.
Note that a sub-TLV is similar to a TLV: TLV are carried within an
LSA as sub-TLVs are carried within TLVs. Each sub-TLV describes a
particular Path Computation Server capability. In the rest of this
document both terms will be used interchangeably.
4.3 PCSD TLVs format
This section defines the PCSD TLVs carried within the OSPF PCSD LSA
payload.
The PCSD LSA is made of various non ordered TLVs defined bellow:
TLV type Length Name
1 4 Path computation server scope TLV
2 variable Path computation server address TLV
3 8 Path computation server capability TLV
4 8 AS-domain TLV
Any non recognized TLV must be silently ignored.
4.3.1 Path computation server scope TLV
The path computation server scope TLV specifies the zone for which
the path computation server is capable of performing TE LSP path
computation.
The path computation server scope TLV type is 1, its length is 4, and
the value is a set of flags:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vasseur et Psenak 4
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
| 1 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | |A|I|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path computation server scope TLV format
Flags: no flags are currently defined.
Scope
L (local scope). When set, this flag indicates that the PCS can
compute paths for the area the LSP is flooded into (i.e the PCS can
compute TE LSP path for intra-area TE LSPs).
I (inter-area scope). When set, the PCS can perform TE LSP path
computation for inter-area TE LSPs (i.e TE LSP whose destination IP
address belongs to another area of the head-end LSR) but within the
same AS.
A (multi-domain scope). When set, the PCS can perform path
computation for inter-domain TE LSP. In this case, the PCSD LSA must
contain one or more AS-domain TLV(s) each describing the domain for
which the PCS can compute TE LSPs paths having their destination
address in this domain.
Note that a PCS may set one or more flags.
See section 4 for a detailed description of the elements of
procedure.
4.3.2 Path Computation Server address TLV
The PCS address TLV specifies the IP address to be used to reach the
PCS described by this PCSD LSA. This address will typically be a
loop-back address, always reachable, provided the router is not
isolated. This TLV is required.
The PCS address TLV type is 2, length is 4 octets for an IPv4
address and 16 octets for an IPv6 address, and the value is the PCS
IPv4 or IPv6 address.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | variable (4 or 16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCS IP address //
Vasseur et Psenak 5
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path Computation Server address TLV format
Address-type:
1 IPv4
2 IPv6
The Path Computation Server address TLV MUST appear exactly once in
the PCSD LSA originated by a router. The only exception is when the
PCS has both an IPv4 and IPv6 address; in this case, two path
computation server address TLVs might be inserted: one for the IPv4
address, one for the IPv6 address.
4.3.3 Path Computation Server capability TLV
The PCS capability TLV is used by the PCS to signal its path
computation server capabilities. This TLV is optional.
The PCS capability TLV type is 3 and the length is 8 octets.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|M|D|E|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCS capability TLV format
P bit
The notion of request priority allows a PCC to specify how urgent is
the request setting a flag in the REQUEST_ID object of the Path
computation request message. See [4] for more details.
P=1: the PCS takes into account the "request priority" in its
scheduling of the various requests.
P=0: the PCS does not take the request priority into account
M bit
M=1: the PCS is capable of computing more than one paths obeying a
set of specified constraints, provided that they exist.
M=0: the PCS cannot compute more than one path obeying a set of
specified constraints.
D bit
The PCC may request the PCS to compute N diversely routed paths
obeying a set of specified constraints.
Vasseur et Psenak 6
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
Such N paths may not exist of course depending on the current state
of the network. See [4] for more details.
D=1: the PCS is capable of computing diversely (link, node, SRLG)
routed paths.
D=0: the PCS is not capable of computing diversely routed paths.
The D bit is relevant if and only if the M bit has been set to 1. It
must be set to 0 if the M bit is set to 0.
E bit
The PCC may request the PCS the computation of a path obeying a set
of constraints one of those constraints being that one or more
specified network element object must not be traversed by the LSP (a
network element may be a link, an LSR or an Autonomous System). See
[4] for more details.
E=1: the PCS is capable of computing TE LSP paths excluding some
network elements.
E=0: the PCS is not capable of computing paths excluding network
elements.
G bit
As defined in [4], the PCC may send a request specifying the metric
to be used by the PCS when computing the shortest path during the
CSPF.
G=1: the PCS supports the computation of CSPF with various metrics
G=0: the PCS just computes the CSPF based on the TE metric
Note that for future capability, it may be desirable to introduce
new flags or may be new TLV to be carried in the PCSD LSA if the
capability needs more than just a single flag to be described.
4.3.4 AS-domain TLV
When the PCS can perform path computation for inter-domain TE LSP,
the A bit of the path computation server scope TLV must be set.
Moreover, one or more TLVs MUST included within the PCSD TLV, each
TLV identifying an AS number. Each TLV will have the following form:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-domain TLV format
The AS-domain TLV type is 4, length is 4 octets, and the value is the
AS number identifying the AS for which the PCS can compute inter-
domain TE LSP paths (TE LSP having their destination address in this
domain). When coded on two bytes (which is the current defined format
Vasseur et Psenak 7
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
as the time of writing), the AS Number field must have its left two
bytes set to 0.
The set of AS-domain TLVs specifies a list of ASes (AS1, ... , ASn).
This means that the PCS can compute TE LSP path such that the
destination address of the TE LSP belong to this set of ASes.
5. Elements of procedure
A router must originate its PCSD opaque LSA whenever its content
change or whenever required by the regular OSPF procedure (LSA
refresh (every LSRefreshTime, new OSPF adjacency, ...).
As defined in RFC2370, an opaque LSA has a flooding scope determined
by its LSA type:
- link-local (type 9),
- area-local (type 10)
- entire OSPF routing domain (type 11). In this case, the
flooding scope is equivalent to the Type 5 LSA flooding scope.
A PCSD LSA may be generated as a type 10 or 11 depending on the path
computation server scope.
- If the PCS can compute intra-area TE LSP the L bit of the path
computation server scope sub-TLV must be set,
- If the PCS can compute inter-area TE LSP the I bit of the path
computation server scope sub-TLV must be set,
- If the PCS can compute inter-AS TE LSP the A bit of the path
computation server scope sub-TLV must be set,
Note: if the PCS can both compute intra and inter-area TE LSP paths,
both the L and I bits of the path computation server scope TLV must
be set. The flags are not exclusive.
Type of PCSD opaque LSA
If a PCS can only compute intra-area TE LSP path computation, it
MUST originate a unique PCSD LSA of type 10 with the S, I and A
flags of its Path Computation Server scope TLV set as described
above.
If a PCS can only compute inter-area or inter-AS TE LSP path, it
MUST originate a unique PCSD LSA of type 11 with the S, I and A
flags of its Path Computation Server scope TLV set as described
above.
If a PCS can compute intra-area TE LSP and inter-area or inter-AS TE
LSP path, it must originate:
- a type 10 PCSD LSA with L=1 and the I and A flags of its Path
Computation Server scope TLV set as described above,
Vasseur et Psenak 8
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
- a type 11 PCSD LSA with L=0 and the I and A flags of its Path
Computation Server scope TLV set as described above.
Example
<-----------------AS1----------------->
<---area 1--><----area 0-----><-area 2->
R1---------ABR1*------------ABR3*-----| ------------
| | | | | |
| S1 | S2 | ASBR1*--eBGP--ASBR2-| AS2 |
| | | | | |
R2---------ABR2*------------ABR4------| ------------
The areas contents are not detailed.
Assumptions:
- area 1 and area 2 are regular areas
- the * indicates a Path computation server capability
- ABR1 is a PCS for area 1 only
- ABR2 is a PCS for intra and inter-area TE LSP path computation in
area 0 and 1
- ABR3 is a PCS for only inter-area TE LSP path computation in areas
0 and 2
- S1 is a PCS for area 1 only
- S2 is a PCS for the whole AS
- ASBR1 is a PCS for inter-AS TE LSP only whose destination resides
in AS2 (not for intra or inter-area area TE LSPs).
In the example above:
- S1 originates a type 10 PCSD LSA with:
o The L bit of the path computation server scope TLV set,
o The I and A bits of the path computation server scope TLV
cleared.
- ABR1 originates in area 1 a type 10 PCSD LSA with:
o The L bit of the path computation server scope TLV set,
o The I and A bits of the path computation server scope TLV
cleared,
- ABR2 originates:
- in both area 0 and 1 a type 10 PCSD LSA with:
o The L and I bits of the path computation server scope
TLV set,
o The A bit of the path computation server scope TLV
cleared,
- a type 11 PCSD LSA with:
o The L bit of the path computation server scope TLV
cleared,
Vasseur et Psenak 9
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
o The I bit of the path computation server scope TLV
set,
o The A bit of the path computation server scope TLV
cleared,
- ABR3 originates a type 11 PCSD LSA with:
o The L bit of the path computation server scope TLV cleared,
o The I bit of the path computation server scope TLV set,
o The A bit of the path computation server scope TLV cleared,
- S2 originates:
- in area 0 a type 10 PCSD LSA with:
o The L and I bits of the path computation server scope
TLV set,
o The A bit of the path computation server scope TLV
cleared,
- a type 11 PCSD LSA with:
o The L bit of the path computation server scope TLV
cleared,
o The I bit of the path computation server scope TLV
set,
o The A bit of the path computation server scope TLV
cleared,
- ASBR1 originates a type 11 PCSD LSA with:
o The L bit of the path computation server scope TLV cleared,
o The I bit of the path computation server scope TLV cleared,
o The A bit of the path computation server scope TLV set,
o One AS-domain TLV within the PCSD TLV with AS number = AS2
The receipt of a new PCSD LSA never triggers an SPF calculation.
When an LSR or a dedicated path computation server is newly
configured as a PCS, the corresponding PCSD LSA must be immediately
flooded.
When a PCS capability changes, the corresponding PCSD LSA must be
immediately flooded.
When an LSR or a dedicated path computation server looses its path
computation server capability, the corresponding PCSD LSA must be
immediately flooded with LS age = MaxAge.
5. Interoperability with routers non supporting this capability
There is no interoperability issue as a router non-supporting the
OSPF PCSD opaque LSA should just silently discard any received OSPF
PCSD LSA as specified in RFC2370.
6. Security Considerations
Vasseur et Psenak 10
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
No new security issues are raised in this document.
7. Acknowledgments
The authors would like to thank Abhay Roy, Dan Tappan and Robert
Raszuk for their comments.
8. References
[1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[2] Awduche, D., et al, "Requirements for Traffic Engineering Over
MPLS," RFC 2702, September 1999.
[3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.
[4] Vasseur et al, "RSVP Path computation request and reply
messages ", draft-vasseur-mpls-computation-rsvp-te-03.txt, work in
progress.
[5] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF",
draft-katz-yeung-ospf-traffic-04.txt
[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
draft-ietf-isis-traffic-03.txt, work in progress.
[7] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS TE",
Internet Draft, draft-ietf-mpls-lsp-hierarchy-02.txt, Feb., 2001.
[8] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in RSVP-
TE", Internet Draft, draft-ietf-mpls-rsvp-unnum-01.txt, February 2001
[9] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-
ospf-gmpls-extensions-06.txt (work in progress)
[10] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP
Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp-
01.txt, February 2001.
[11] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling
Functional Description", Internet Draft, draft-ietf-mpls-generalized-
signaling-02.txt,
February 2001.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119.
Vasseur et Psenak 11
Internet draft draft-vasseur-ospf-pcsd-discovery-00.txt June 2002
[13] Braden, R. Ed. et al, "Resource ReserVation Protocol-- Version 1
Functional Specification", RFC 2205, September 1997.
[14] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[15] Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S.,
"RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[16] Le faucheur, "Use of IGP Metric as a second TE Metric",
Internet draft, draft-lefaucheur-te-metric-igp-00.txt.
[17] Fedyk D., Ghanwani A., Ash J., Vedrenne A. "Multiple Metrics
for Traffic Engineering with IS-IS and OSPF", Internet draft,
draft-fedyk-isis-ospf-te-metrics-01.txt
8. Author's Addresses
JP Vasseur
CISCO Systems, Inc.
11, rue Camille Desmoulins
92782 Issy les Moulineaux Cedex 9
FRANCE
Email: jpv@cisco.com
Peter Psenak
CISCO Systems, Inc.
Pegasus Parc
De Kleetlaan 6A
1831, Diegem
BELGIUM
Email: ppsenak@cisco.com
Vasseur et Psenak 12