Subject: New Internet Draft: TE over Unnumbered Links

From: Kireeti Kompella <[email-masked]>
Date: Fri, 21 Jul 2000 02:12:04 -0700 (PDT)

Hi,

FYI: we have a new Internet draft for doing TE over unnumbered links.
This draft will shortly be sent to the IETF, but may not be posted
prior to the coming IETF, so the text follows.

Kireeti.
-------

Network Working Group                             Kireeti Kompella
Internet Draft                                    Juniper Networks
Expiration Date: January 2001                        Yakov Rekhter
                                                     Cisco Systems

               Traffic Engineering with Unnumbered Links

                    draft-kompella-mpls-unnum-00.txt

1. 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.

2. Abstract

   Traffic Engineering currently does not take into account unnumbered
   links.  There are two issues: carrying information about unnumbered
   links in IS-IS and OSPF; and including unnumbered links when
   signalling.  This document addresses these two issues.

draft-kompella-mpls-unnum-00.txt                                [Page 1]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000

3. Overview

   Traffic Engineering currently does not take into account unnumbered
   links (i.e., links that do not have IP addresses).  However, not
   numbering links is useful, if not critical, in many environments; the
   reasons include conserving IP addresses, and reducing management
   overhead.  This document only covers point-to-point links that are
   unnumbered.

   There are two issues: carrying Traffic Engineering information about
   unnumbered links in IS-IS and OSPF (see [ISIS-TE] and [OSPF-TE]); and
   including unnumbered links when signalling (see [RSVP-TE]).  This
   document proposes a simple means of solving the former (modeled on
   how OSPF carries unnumbered link information for router link
   advertisements), and a simple extension to the RSVP Explicit Route
   Object for the latter.

4. Interface Identifiers

   If links are not identified by an IP address, they need some other
   identifier.  We assume that each unnumbered link on a Label Switched
   Router (LSR) is given a unique 16-bit identifier.  The scope of this
   identifier is the LSR to which the link belongs; moreover, the
   ISIS/OSPF and RSVP modules on an LSR must agree on interface
   identifiers.  A good candidate for the interface identifier is the
   SNMP IfIndex of the interface.

5. Carrying Unnumbered Links in IS-IS and OSPF

   In IS-IS, the extended IS reachability TLV contains an IPv4 Interface
   Address, which normally identifies an IPv4 address for an interface.
   If the interface being advertised for Traffic Engineering purposes is
   unnumbered, the IPv4 Interface Address is set to the router ID of the
   advertising LSR.  The extended IS reachability TLV also contains an
   IPv4 Neighbor Address, which normally identifies an IPv4 address of
   the neighboring LSR on a link.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the first two octets of
   the IPv4 Neighbor Address are set to zero, and the next two octets
   are set to the Interface ID of the unnumbered interface.  The rest of
   the Traffic Engineering information remains unchanged.

   In OSPF, the Link sub-TLV of the Opaque Traffic Engineering TLV
   contains a Local Interface IP Address, which normally identifies the
   IPv4 address for an interface.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the Local Interface
   Address is set to the router ID of the advertising LSR.  The Link

draft-kompella-mpls-unnum-00.txt                                [Page 2]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000

   sub-TLV of the Opaque Traffic Engineering TLV also contains a Remote
   Interface IP Address, which normally identifies the neighbor's IPv4
   address for the interface.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the first two octets of
   the Remote Interface IP Address are set to zero, and the next two
   octets are set to the Interface ID of the unnumbered interface.  The
   rest of the Traffic Engineering information remains unchanged.

6. Signalling Unnumbered Links in EROs

   A new subobject of the Explicit Route Object (ERO) is used to signal
   unnumbered links.  This subobject has 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |     Interface ID (16 bits)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This subobject MUST be strict (i.e., the L bit MUST be 0).  The Type
   is 3 (Unnumbered Interface ID).  The Length is 4.  The Interface ID
   is interpreted in the context of the previous node in the path (i.e.,
   the node identified by the previous subobject in the ERO, which MUST
   identify a unique node), or, if this is the first subobject in the
   ERO, in the context of the start of the path.  The next node in the
   path is the node at the other end of the interface identified by the
   Interface ID.

7. Security Considerations

   This document raises no new security concerns for IS-IS, OSPF or
   RSVP.

8. References

   [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic
   Engineering", draft-ietf-isis-traffic-01.txt (work in progress)

   [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to
   OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress)

   [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
   V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
   draft-ietf-mpls-rsvp-lsp-tunnel-06.txt (work in progress)

draft-kompella-mpls-unnum-00.txt                                [Page 3]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000

9. Author Information

Kireeti Kompella
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
e-mail: [email-masked]

Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: [email-masked]

draft-kompella-mpls-unnum-00.txt                                [Page 4]

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 21 Jul 2000 10:50:24 -0700

Kireeti,
A couple of comments:

1. Maybe there is a need to enhance the semantics of the RSVP_HOP object
to work over unnumbered links. The ip address of the previous hop
could be set to the router id of the previous hop. 

2. This is more of a clarification. Consider:
A----------B-----------C
 Ia     Ib          Ic

The link from B to C is unnumbered. My understanding from the draft is 
that B will generate the interface id for Ic. (and C for Ib) Is that correct? 
The ero could be <Ib, Ic>. Since B generated the id for Ic, it will know the
outgoing interface to send the path msg to C. 

C will receive the ero as <Ic>. Now C needs to check the ero to see if 
it belongs to the first subobject i.e. Ic. How should this check be done?
This goes back to (1) above.

thanks,
rahul

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Fri, 21 Jul 2000 16:01:34 -0400

Kireeti,

I had a few questions/comments on the TE over Unnumbered Links draft

1) At the ingress, when a node uses the unnumbered link for ERO computation,
   how does it know about the tail-end of the link. It seems the local
address
   and a local index passed in OSPF/ISIS would be insufficient in path
computation.
   Don't we need the
   router Id of the remote end of the link, in addition to some sort of
index for the
   outgoing interface (like the SNMP IFIndex suggested) at the head-end of
the link.

   Your document says in section 6
    "The next node in the path is the node at the other end of the
interface"
   At the ingress of the LSP, how would one compute the next node with the
available
   igp information.

2) Shouldn't the length field value be 2 instead of 4 (2 octets).

3) And what would the RSVP HOP object look like on the RESV/PATH message
sent on
   the unnumbered link?
thanks
ganesh

---

From: Markus Jork <[email-masked]>
Date: Fri, 21 Jul 2000 08:52:50 -0400

Kireeti,

you have picked the value 3 for the new "Unnumbered Interface ID"
ERO subobject type. Can you please make that some other value.
draft-ietf-mpls-rsvp-lsp-tunnel-06.txt has just assigned
subobject type 3 to the "Label" subobject. That is only used
in RROs but we should maintain the uniqueness of subtypes across
EROs and RROs.
Speaking of RROs, shouldn't the new subobject not also be used
in there?

Markus

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Jul 2000 18:41:56 -0700

> in RROs but we should maintain the uniqueness of subtypes across

i suspect you all need iana considerations sections and have iana
assign the number space.

randy