Issues with Link Bundling Draft

1
Issues with Link Bundling Draft
Zafar Ali (zali_at_cisco.com)
2
Background Why Bundling Draft is Pulled from
RFC Editor Queue?

• A team of contributors, which includes authors of
  the Bundling Draft, had identified and discussed
  some issues with bundling draft coupled with
  RFC3471/ 73
• List of Contributors (Ordered Alphabetically)
  Zafar Ali, Arthi Ayyangar, Lou Berger, Igor
  Bryskin, John Drake, Adrian Farrel, Kireeti
  Kompella, Dimitri Papadimitriou, Yakov Rekhter,
  Anca Zamfir, et al.
• These issues concerns text in bundling draft and
  in RFC 3471/73 and hence concerns MPLS and CCAMP
  WGs.
• It seems logical to extend bundling draft to
  contain solutions to the issues presented here.

3
Scope of This Presentation

• The Scope of this Presentation is to outline
  Issues.
• At present, we would like to focus on the
  required functionality and avoid discussions on
  the solutions.
• We would like to request WG to close on these
  issues (i.e., the required functionality).

4
List of Issues

• Scoping of Component Link ID
• Node vs. Bundled TE link Scoped.
• Equivalents of Type 4/5 TLVs for IPv4 and IPv6
  IF_ID RSVP_HOP and IF_ID ERROR_SPEC Objects.
• Recording (and explicit control) of the Component
  Link ID.

5
Issue 1 Scope of Unnumbered Component Link ID

• TE Link Scope
• Component link ID is unique within the bundled TE
  link.

• LSR Scope
• Component link ID is unique within the scope of a
  node.

6
Arguments for LSR Scoped Component Identifier

• This is how bundling draft defines it,
• Link local identifiers for all unnumbered links
  of a given LSR (whether component links,
  Forwarding Adjacencies or bundled links) MUST be
  unique in the context of that LSR Bundling
  Draft.
• When component links are numbered, they are LSR
  Scoped.
• Management plane (e.g., SNMP IF Index) has notion
  of unique ID for each component link, so why not
  control plane.
• The ID comes from the same 32 bit space as
  bundled TE links.
• The LSP Scoped uniqueness of ID does simplifies
  some protocol constructs.
• E.g., the Figure shows an example of Egress
  Resource Control LSP Splicing in bundled TE Link
  Case.

10.4.4.4
10.3.1.1
10.2.1.1
1
10.1.1.1
7
Arguments for Bundled TE Link Scoped Component
Identifier

• The way type 3/4/5 TLVs for IF_ID RSVP_HOP and
  IF_ID ERROR_SPEC Objects are defined in RFC
  3473/71, allows us to associate component link ID
  within the scope of TE link ID.
• IP address field for type 3/4/5 TLVs is defined
  as The IP address field may carry either an IP
  address of a link or an IP address associated
  with the router, where associated address is the
  value carried in a router address TLV of
  routing.
• If component IF ID are LSR Scoped this RFC
  should have define this IP address field as the
  router-id.
• A node may be managing ports (component links)
  at the line card and not at the box level.
• Notion of component link is more close to the
  notion of label then the notion of links. From
  the links perspective component looks like a
  label.

8
Issue 2Equivalents of Type 4/5 TLVs for IPv4
and IPv6
RFC3471 defines the following TLVs for IF_ID
RSVP_HOP and IF_ID ERROR_SPEC Objects

• RFC3473 specifies In the special case where a
  bidirectional LSP that traverses a bundled link,
  it is possible to specify a downstream data
  channel that differs from the upstream data
  channel.
• Type 1, 2 3 could not be used to specify
  different component links in forward and reverse
  directions.
• Type 4 5 are defined to cover the case of
  bundled TE links, where one would like to use
  different component links in forward and reverse
  directions.
• Bundling draft does NOT refer to the use of type
  4 5 TLVs!
• The above definition (type 4/5 TLVs) does NOT
  cover the case of numbered (IPv4 and IPv6)
  component links (for selecting different
  component links in forward and reverse
  directions).

9
Issue 3 Recording (and explicit control) of the
Component Link ID

• Resource within a bundled TE link is specified by
  (TE Link ID, Component interface ID, Label value)
  tuple.
• Label recoding and control is possible via Label
  RRO and ERO defined in RFC3473.
• In addition of ability of recording Label values,
  Service Provider also like to record component
  link selected by remote nodes for diagnostics
  purposes.
• Similarly, in addition of ability of explicitly
  controlling the label resource, Service Providers
  would also like to enforce component link
  selection for applications like LSP splicing.
• There is a fair interest in pursing this work in
  CCAMP.

10
Next Step

• We would like to request MPLS WGs to close of the
  issues related to bundling draft, especially the
  issue of scope of component link IDs.
• Based on the closure of these issues, we can have
  more discussion on the solution space and decide
  on how bundling draft or new draft(s) should
  address the required functionality.

Thank You