[mpls] Updates to draft-villamizar-mpls-tp-multipath drafts

[Curtis Villamizar <[e-mail]>]

Please take a look at the draft-villamizar-mpls-tp-multipath drafts.
There are two and they are both recently revised.  The changes are
substantial.  Essentially, Entropy Label is downselected as the best
way to support LSP with strict packet ordering requirements (which
includes MPLS-TP LSP) over MPLS LSP that make use of multipath links.

draft-villamizar-mpls-tp-multipath-03 shrunk from 25 pages to 9 pages
for the following reasons:

  1.  It mainly makes a few simple points:

    a.  MPLS-TP in MPLS and MPLS in MPLS-TP are called for as
        requirements in RFC 5654 requirement 33.

    b.  Entropy Label provides a means of carrying MPLS-TP client LSP
        within a MPLS server layer LSP and offering a fully MPLS-TP
        compliant server layer.

    c.  MPLS client LSP can be carried within MPLS-TP server layer LSP
        with limitations described in the draft.

  2.  Lengthy statement of multipath requirements are no longer
      necessary if we accept that Entropy Label does something useful
      and therefore needed to become and RFC.  Large sections were
      removed from the draft.

  3.  Lengthy discussion of requirements tradeoffs and scalability
      considerations were removed from the draft.

  4.  Discussion of alternatives was removed from the draft.  Only
      using Entropy Label to carry MPLS-TP client LSP within a MPLS
      server layer LSP is considered.

Therefore draft-villamizar-mpls-tp-multipath-03 is now a short read
and should be non-controversial (I hope).

There is some mention in draft-villamizar-mpls-tp-multipath-03 of
limitations in the absense of any protocol extensions.

The update to draft-villamizar-mpls-tp-multipath-te-extn reflects the
use of ELI and EL and the elimination of some alternatives and is
simplified as a result.  The purpose of the extensions is to determine
at CSPF time where in the topology limitations exist (such as legacy
multipath with no EL support - LAG for example) and figuring out when
large microflows are going to be a problem.

The Infinera IPR statement no longer applies since Entropy Label is
being used rather than the forwarding change that I had proposed while
at Infinera.  There is no way to completely remove an IPR statement so
I will rename the drafts after the IETF meeting.  I would like the WG
to be aware of the change and why the IPR no longer applies.

I have made a request to make a presentation about the changes at the
Atlanta IETF.  I would like the work group, after the IETF meeting, to
consider at least draft-villamizar-mpls-tp-multipath-03 as a WG
document and preferabley both.

Prior to the upcoming IETF meeting, discussion on the WG list
(preferred) or private email would be greatly appreciated.

Thanks,

Curtis


------- Forwarded Messages

From: [e-mail]
To: [e-mail]
Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-03.txt


A new version of I-D, draft-villamizar-mpls-tp-multipath-03.txt
has been successfully submitted by Curtis Villamizar and posted to the
IETF repository.

Filename:	 draft-villamizar-mpls-tp-multipath
Revision:	 03
Title:		 Use of Multipath with MPLS-TP and MPLS
Creation date:	 2012-10-02
WG ID:		 Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-villamizar-mpls-tp-multipath-03.txt
Status:          http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath
Htmlized:        http://tools.ietf.org/html/draft-villamizar-mpls-tp-multipath-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-villamizar-mpls-tp-multipath-03

Abstract:
   Many MPLS implementations have supported multipath techniques and
   many MPLS deployments have used multipath techniques, particularly in
   very high bandwidth applications, such as provider IP/MPLS core
   networks.  MPLS-TP has strongly discouraged the use of multipath
   techniques.  Some degradation of MPLS-TP OAM performance cannot be
   avoided when operating over many types of multipath implementations.

   Using MPLS Entropy label, MPLS can LSP can be carried over multipath
   links while also providing a fully MPLS-TP compliant server layer for
   MPLS-TP LSP.  This document describes the means of supporting MPLS as
   a server layer for MPLS-TP.  The use of MPLS-TP LSP as a server layer
   for MPLS LSP is also discussed.

The IETF Secretariat

------- Message 2

From: [e-mail]
To: [e-mail]
Subject: New Version Notification for
	draft-villamizar-mpls-tp-multipath-te-extn-02.txt


A new version of I-D, draft-villamizar-mpls-tp-multipath-te-extn-02.txt
has been successfully submitted by Curtis Villamizar and posted to the
IETF repository.

Filename:	 draft-villamizar-mpls-tp-multipath-te-extn
Revision:	 02
Title:		 Multipath Extensions for MPLS Traffic Engineering
Creation date:	 2012-10-07
WG ID:		 Individual Submission
Number of pages: 30
URL:             http://www.ietf.org/internet-drafts/draft-villamizar-mpls-tp-multipath-te-extn-02.txt
Status:          http://datatracker.ietf.org/doc/draft-villamizar-mpls-tp-multipath-te-extn
Htmlized:        http://tools.ietf.org/html/draft-villamizar-mpls-tp-multipath-te-extn-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-villamizar-mpls-tp-multipath-te-extn-02

Abstract:
   Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of
   carrying LSP with strict packet ordering requirements over multipath
   and and carrying LSP with strict packet ordering requirements within
   LSP without violating requirements to maintain packet ordering.  LSP
   with strict packet ordering requirements include MPLS-TP LSP.

   OSPF-TE and ISIS-TE extensions defined here indicate node and link
   capability regarding support for ordered aggregates of traffic,
   multipath traffic distribution, and abilities to support multipath
   load distribution differently per LSP.

   RSVP-TE extensions either identifies an LSP as requiring strict
   packet order, or identifies an LSP as carrying one or more LSP that
   requires strict packet order further down in the label stack, or
   identifies an LSP as having no restrictions on packet ordering except
   the restriction to avoid reordering microflows.  In addition an
   extension indicates whether the first nibble of payload will reliably
   indicate whether payload is IPv4, IPv6, or other type of payload,
   most notably pseudowire using a pseudowire control word.

The IETF Secretariat

------- End of Forwarded Messages