Subject: [mpls-tp] 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: 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: Loa Andersson <[email-masked]>
Date: Fri, 12 Feb 2010 14:23:25 +0100

Sasha,

agreed that the document is document is a bit raw (and young).

A very important part of the reasoning behind breaking it out
from the mpls-tp-framework was the need to have a document that
could be easily referenced (i.e. on the standards track).

Most of the information has earlier been "hidden" in the
framework, but has been pulled out to make it clearly visible.

We have also a set of comments received the pool started, that
is why we added the concluding paragraph to the polling mail.

Basically this last paragraph is the acknowledgment you are
asking for.

We are on the very short schedule to produce documents that can
be referenced both by IETF RFCs and ITU-T Recommendations.

That is why I issued the early poll (raw document), but in
my document it is within our charter, something we absolutely
need to solve and it is enough as a starting point. And it
is easier to drive the document if it is a wg document.

/Loa

Alexander Vainshtein wrote:
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Comments on draft-fbb-mpls-tp-data-plane-00
>> From:
>> Alexander Vainshtein <[email-masked]>
>> Date:
>> To:
>> "[email-masked]" <[email-masked]>, 'Dan Frost' 
>> To:
>> "[email-masked]" <[email-masked]>, 'Dan Frost' 
>> CC:
>> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>>
>>
>> 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.
>> I will make a (hopefully, short) list of items that IMHO require 
>> additional clarification and, eventually, codification.
>>  
>>
>>    1. *LSP Merge*:
>>                 o One well-known usage of LSP merge is FRR
>>                 o PHP can be considered as a special case of LSP merge
>>                 o Whether this limitation has to be respected at the
>>                   data plane level, and if yes, then how
>>                 o Whether it means that FRR cannot be used in MPLS-TP
>>    2. *Per-Interface Label Space*:
>>                 o This referred to data links (including bundles,
>>                   e.g., produced by LAG). As a consequence, the number
>>                   of label contexts has been reasonably low
>>                 o 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).
>>                 o Can LAN-like data links be Sections in MPLS-TP (The
>>                   Editors ask this question themselves when they
>>                   discuss MAC addresses)
>>                 o 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.).
>>                 o If associated bi-directional LSPs can be Sections,
>>                   can we treat the LSPs rumming over these Sections as
>>                   co-routed bidirectional?
>>                 o 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*:
>>                 o Downstream label allocation as per RFC 3031
>>                 o Upstream label allocation as per RFC 5331
>>                 o Label allocation scheme is reflected in the
>>                   Ethertype in the case of Ethernet encapsulation etc.
>>                 o Packets with invalid labels must be silently
>>                   discarded etc.
>>                 o This includes applicability of these schemes, e.g.,
>>                   can we use upstream label allocation
>>                 o This issue is closely related to proposed usage of a
>>                   well-known multicast MAC destination address for P2P
>>                   LSPs)
>>    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.
>>

--

---

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: Alexander Vainshtein <[email-masked]>
Date: Sat, 13 Feb 2010 21:29:59 +0200

Loa and all,
Please see a couple of comments/responses inline below (marked [[Sasha]]).

Regards,
     Sasha

________________________________________
From: Loa Andersson [[email-masked]]
Sent: Friday, February 12, 2010 3:23 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

Sasha,

A very important part of the reasoning behind breaking it out
from the mpls-tp-framework was the need to have a document that
could be easily referenced (i.e. on the standards track).
[[Sasha]] I cannot agree more. As I said, this document is absolutely required.

Most of the information has earlier been "hidden" in the
framework, but has been pulled out to make it clearly visible.
[[Sasha]] Many "hidden" points have been made visible, but some still remain.
IMHO and FWIW we should clarify as many of them as possible.

Basically this last paragraph is the acknowledgment you are
asking for.
[[Sasha]] OK, I am ready to accept that.

[[Sasha]] OK
/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: "Puneet Agarwal" <[email-masked]>
Date: Wed, 17 Feb 2010 17:30:11 -0800

I agree we need this document. I have similar concerns as Sasha on the incompleteness of this version of the doc - most important one being the MAC assignment. 

I hope the authors can do a quick rev of the doc to address the concerns expressed before we make it a WG doc.

Thanks.
 
-Puneet

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Saturday, February 13, 2010 11:30 AM
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

Loa and all,

Regards,
     Sasha

Sasha,

A very important part of the reasoning behind breaking it out from the mpls-tp-framework was the need to have a document that could be easily referenced (i.e. on the standards track).
[[Sasha]] I cannot agree more. As I said, this document is absolutely required.

Most of the information has earlier been "hidden" in the framework, but has been pulled out to make it clearly visible.
[[Sasha]] Many "hidden" points have been made visible, but some still remain.
IMHO and FWIW we should clarify as many of them as possible.

We have also a set of comments received the pool started, that is why we added the concluding paragraph to the polling mail.

Basically this last paragraph is the acknowledgment you are asking for.
[[Sasha]] OK, I am ready to accept that.

We are on the very short schedule to produce documents that can be referenced both by IETF RFCs and ITU-T Recommendations.

That is why I issued the early poll (raw document), but in my document it is within our charter, something we absolutely need to solve and it is enough as a starting point. And it is easier to drive the document if it is a wg document.
[[Sasha]] OK
/Loa

Alexander Vainshtein wrote:
> 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:
>> 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:
>> 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.

--

                                              +46 767 72 92 13 _______________________________________________

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 19 Feb 2010 00:07:53 +0100

no/do not support the 00 version to become WG draft

I agree with other commenters that a respin is required.
The purpose of this draft is not (yet) clear to me.

Regards, Huub.

====================

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

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,

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 24 Feb 2010 14:41:37 +0200

Loa,
Lots of thanks for a prompt response.

I just wanted to be sure that you do not preclude moving all the data plane issues from the FW draft 
to the data-plane draft (e.g., for procedural and/or schedule-related reasons).

Of course it is up to the authors as to how they address specific comments, and it is perfectly valid
to disagree with some comments. When resolution involves more than one draft, reaching the agreement can
become complicated, but, hopefully, not in this case (all the authors of the data-plane draft are also the authors of the FW draft:-)...

Regards,
     Sasha

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2010 2:29 PM
To: Alexander Vainshtein; Loa Andersson
Cc: [email-masked]
Subject: RE: [mpls-tp] [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document

Sasha,

the IETF interpretation of "address comments" is that the authors need
to come up with a response, this might be agreement, compromise or
disagreement with a particular comment.

It is certainly the intention that the data-plane document should 
be a stand alone document when it comes to data plane issues, but
I normally do not dictate how an issues shall be resolved, but I
try to encourage authors and people behind the comments to come to a 
resolution of each comment.

So the short answer is - yes your comments will be taken care of,
but I don't know yet what the resolution will be.

/Loa  

> Behalf Of Alexander Vainshtein
> Sent: den 24 februari 2010 12:49
> To: Loa Andersson
> Subject: Re: [mpls-tp] [PWE3] [mpls] poll on making draft-fbb-mpls-tp-
> data-plane-00.txt a mpls working group document
> 
> Loa,
> 
> 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?
>

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 24 Feb 2010 13:45:22 +0100

All,

I responded to Sasha's mail from a mail account not subscribed to the
mpls-tp list, that is why you did not see my first mail, however you
have the context here.

/Loa

PS

yes I will subscribe my other account also ;)

> become complicated, but, hopefully, not in this case (all the authors of
> the data-plane draft are also the authors of the FW draft:-)...
>
> Regards,
>      Sasha
>
>
> Subject: RE: [mpls-tp] [PWE3] [mpls] poll on making

Loa Andersson