Subject: [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

From: Loa Andersson <[email-masked]>
Date: Tue, 09 Feb 2010 17:06:06 +0100

All,

This is to start two week poll on making
draft-fbb-mpls-tp-data-plane-00.txt
an mpls working group document.

Send a mail to the [email-masked] mailing list,
indicating "yes/support" or "no/do not support".

Note that this ID is a starting point for what needs to
be documented on the MPLS data plane for the MPLS-TP
project. The ID is largely based on the data plane specific
text from the framework, together with some notes concerning
how the Transport Profile of MPLS might operate over Ethernet.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Feb 2010 18:26:58 +0200

Loa,
I think that such a draft is absolutely required.
At the same time I think the -00 revision is somewhat problematic.
In particular, the proposal to use a well-known multicast MAC address for encapsulation of MPLS-TP
packets over Ethernet *simply will not work* together with the combination of:
(a) LAN interfaces between MPLS-TP routers (quite a common case for Ethernet) and 
(b) Downstream label assignment (which presumably is going to be used for P2P LSPs in MPLS-TP).

I've already sent my comments on this (and some other points) to the authors and the mailing lists (attached).

IMHO at least the problem of Ethernet encapsulation should be acknowledged (and resolved?) before the draft is accepted as a WG document.

Regards,
	Sasha

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, February 09, 2010 6:06 PM
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; Adrian Farrel
> Subject: [mpls-tp] poll on making 
> draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document
> 
> All,
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 

Subject: Comments on draft-fbb-mpls-tp-data-plane-00
From: Alexander Vainshtein <[email-masked]>
To: "[email-masked]" <[email-masked]>, 'Dan Frost' <[email-masked]>, 'BOCCI Matthew' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 1 Feb 2010 18:59:57 +0200

Stewart, Dan, Matthew and all,
First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me.
The draft is clearly the necessary first step in the right direction, and I thank you for producing it.

That said, I think that quite a few issues have been left undecided in this -00 version of the draft.

I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification.

 1.  LSP Merge:
    *   In MPLS, nothing prevents LSPs from merging at some point:
       *   One well-known usage of LSP merge is FRR
       *   PHP can be considered as a special case of LSP merge
    *   One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.
    *   It is not clear (at least, to me):
       *   Whether this limitation has to be respected at the data plane level, and if yes, then how
       *   Whether it means that FRR cannot be used in MPLS-TP
    *   Status of this topic in the -00 draft: not mentioned at all
 2.  Per-Interface Label Space:
    *   The draft states that per-interface label space MAY be used in MPLS-TP
    *   AFAIK, in MPLS:
       *   This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low
       *   This has been only allowed on P2P links
    *   One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031).
    *   Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.
 3.  Sections:
    *   The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections).
    *   The following is not clear to me:
       *   Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses)
       *   Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.).
       *   If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional?
       *   Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)?
    *   Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links
 4.  Label Allocation Schemes:
    *   MPLS recognizes two label allocation schemes, each with its own area of applicability:
       *   Downstream label allocation as per RFC 3031
       *   Upstream label allocation as per RFC 5331
    *   IMHO the label allocation scheme is essentially a data plane issue:
       *   Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc.
       *   Packets with invalid labels must be silently discarded etc.
    *   It is not clear to me, which label allocation schemes can be used in MPLS-TP.
       *   This includes applicability of these schemes, e.g., can we use upstream label allocation
       *   This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs)
    *   Status of this topic in the -00 draft: requires clarification
 5.  MAC addresses on Ethernet data links in MPLS-TP:
    *   The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs
    *   IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of  well-known multicast DA is not compatible with the downstream label allocation scheme.
    *   Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution.

Hopefully, these notes will be useful.

Regards,
     Sasha

    *

---

From: Dan Frost <[email-masked]>
Date: Tue, 9 Feb 2010 16:53:18 +0000

Hi Sasha,

Many thanks for your comments!  The authors will review them in detail
when we next sit down to work on the document.  Several of your points
relate to open issues which we're aware need to be resolved, like the
use of multipoint Ethernet interfaces and the definition and scope of
MPLS-TP Sections.  Your input is very helpful as always.

-d

On Tue, Feb 09, 2010 at 06:26:58PM +0200, Alexander Vainshtein wrote:
> To: "[email-masked]" <[email-masked]>, 'Dan Frost'
> 	<[email-masked]>, 'BOCCI Matthew' <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>

---

From: [email-masked]
Date: Wed, 10 Feb 2010 17:44:41 +0800 (SGT)

Hi Loa and the authors,

>From what I read, the main key aspect of this draft defines a new ethernet MAC discovery through the use of multicast MAC. The rest of the drafts discuss about specific dataplane implementation that is align with draft-ietf-mpls-tp-framework-10, which calls it profiling.

Suggestion, why not put profile details into the framework draft? This improves readability? Or unless there can other type of profiling.

/Max

---

From: Elisa Bellagamba <[email-masked]>
Date: Fri, 12 Feb 2010 12:28:23 +0100

Hello,

Yes/support

I'll provide comments soon.

Elisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: den 9 februari 2010 17:06
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Adrian Farrel
Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

All,

/Loa

-- 

CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 12 Feb 2010 09:56:38 -0500

Hi,

Yes/support

Cheers,
Jeff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: den 9 februari 2010 17:06
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Adrian Farrel
Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

All,

/Loa

--

---

From: Eric Gray <[email-masked]>
Date: Wed, 17 Feb 2010 09:39:09 -0500

Yes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, February 09, 2010 11:06 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Adrian Farrel
Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

All,

/Loa

--

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Sun, 21 Feb 2010 21:42:13 -0600

yes/support.

Thanks,
Luyuan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Loa Andersson
Sent: 09 February 2010 11:06
To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
Adrian Farrel
Subject: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a
mpls working group document

All,

Send a mail to the [email-masked] mailing list, indicating
"yes/support" or "no/do not support".

Note that this ID is a starting point for what needs to be documented on
the MPLS data plane for the MPLS-TP project. The ID is largely based on
the data plane specific text from the framework, together with some
notes concerning how the Transport Profile of MPLS might operate over
Ethernet.

/Loa

--

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 24 Feb 2010 11:53:28 +0100

All,

this poll has ended.

We have accepted draft-fbb-mpls-tp-data-plane as an MPLS
wroking group document.

Could the authors please re-publish the document
(without any othr changes than name and date) as
draft-ietf-mpls-tp-data-plane-00.txt.

And in the -01 version address both the comments that we recieved
before the poll started and the commetns we received as response to
the poll.

/Loa

> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///
   phone:  +46 10 717 52 13
           +46 767 72 92 13

   email:  [email-masked]
           [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Feb 2010 13:48:42 +0200

Loa,

One of my early comments on the data plane draft proposed moving all data plane-related issues 
from the MPLS-TP Framework draft to this one. To the best of my recollection, several people  
have supported this proposal during the poll.

When you ask the authors to address "both the comments that we received before the poll started and the comments we received as response to the poll" in the -01 version, do you include this comment as well?

I am asking because the LC on draft-ietf-mpls-tp-framework-10 was expected to end on February 19.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Wednesday, February 24, 2010 12:53 PM
To: Loa Andersson
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

All,

this poll has ended.

/Loa

Loa Andersson

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3