Multiprotocol Label Switching (mpls)

Martin Vigoureux | 1 Feb 2010 11:46

End of poll for draft-weingarten-mpls-tp-linear-protection

all,

the poll for making draft-weingarten-mpls-tp-linear-protection-05
an MPLS WG document has ended. There was support for this.
Could the Editors please republish as:

draft-ietf-mpls-tp-linear-protection-00

and address as part of a later revision comments that would have been
expressed during the poll period.

regards,
martin
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Alexander Vainshtein | 1 Feb 2010 17:59

Comments on draft-fbb-mpls-tp-data-plane-00

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.

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

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.

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

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

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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Greg Jones | 1 Feb 2010 21:55

New Liaison Statement, "LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03)"

Title: LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03)
Submission Date: 2010-02-01
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=633 
Please reply by 2010-04-09

From: Greg Jones(ITU-T SG 15) <tsbsg15 <at> itu.int>
To: IETF MPLS WG(swallow <at> cisco.com,loa <at> pi.nu)
Cc: paf <at> cisco.com
stbryant <at> cisco.com
adrian.farrel <at> huawei.com
rcallon <at> juniper.net
mpls <at> ietf.org
yoichi.maeda <at> ntt-at.co.jp
steve.trowbridge <at> alcatel-lucent.com
Reponse Contact: tsbsg15 <at> itu.int
greg.jones <at> itu.int
hiroshi.ota <at> itu.int
Technical Contact: ghani.abbas <at> ericsson.com
hhelvoort <at> huawei.com
malcolm.betts <at> huawei.com
hklam <at> alcatel-lucent.com
Purpose: For action 
Body: Thank you for your liaison statement (ref # 010.02) providing a list of the MPLS-TP drafts that are
either completed or currently in progress.  Attached is a table indicating our current view of the
dependency between the ITU-T MPLS-TP Recommendations and these drafts.
We would appreciate an update on the status of the drafts and in particular confirmation that the drafts
identified as being required for normative references for the consent of Recommendations in June 2010
will be available.

Attachment: Dependency table, 31 January 2010
Attachment(s):
     LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03) - pdf body (https://datatracker.ietf.org/documents/LIAISON/file750.pdf)
     LS132 - Dependency between ITU-T MPLS-TP Recommendations (ref # 010.03) - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file751.pdf)

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Internet-Drafts | 2 Feb 2010 16:45

I-D Action:draft-ietf-mpls-tp-ach-tlv-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : Definition of ACH TLV Structure
	Author(s)       : S. Boutros, et al.
	Filename        : draft-ietf-mpls-tp-ach-tlv-01.txt
	Pages           : 11
	Date            : 2010-02-02

In some application of the associated channel header (ACH), it is
necessary to have the ability to include a set of TLVs to provide
additional context information for the ACH payload.  This document
defines a number of TLV types.

The following notes (up until the start of "Requirements Language"
will be deleted before Working Group Last Call

NOTE the family of Address Types is known to be incomplete.  The
authors request that members of the MPLS-TP community provide details
of their required address formats in the form of text for the
creation of an additional sections similar to Section 3.1.

NOTE other TLV types will be added in further revisions of this
document.  The authors request that members if the MPLS-TP community
requiring new TLVs to complete there MPLS-TP specifications provide
details of their required TLV in the form of text for the creation of
additional sections similar to Section 2.2.

NOTE The intension is to keep this document as a living list of TLVs
for some time.  When the Working Groups consider that we have
captured the majority of the TLVs we will close the document and
submit for publication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ach-tlv-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment (draft-ietf-mpls-tp-ach-tlv-01.txt): message/external-body, 70 bytes

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

LEVRAU, LIEVEN (LIEVEN | 3 Feb 2010 08:06

Label alloc. Schemes in data-plane-draft'

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft’

In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft.

./

Lieven

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

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant <at> cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

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.

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

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.

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

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

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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

LEVRAU, LIEVEN (LIEVEN | 3 Feb 2010 08:06

Per-interface label space in data-plane-draft'

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Per-interface label space in data-plane-draft’

I agree with the fact that the interface limitation is a bit flue in terms of the client server model.

So the question would be what is an “interface” – what relevance does it have for MPLS-TP when a server layer interface is bundled or is another LSP? I appreciate the impact on the LAG hashing algorithms potentially including more than just the MAC address fields.

I agree with your suggestion.

./

Lieven

Per-Interface Label Space:

o The draft states that per-interface label space MAY be used in MPLS-TP

o 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

o 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).

o Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant <at> cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

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.

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

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.

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

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

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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

LEVRAU, LIEVEN (LIEVEN | 3 Feb 2010 08:06

LSP merging in data-plane-draft

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> LSP merging in data-plane-draft’

On the topic of LSP merging… I think we need to define merging or elaborate on what merging is.

Afai understand the LSP are not merged continuously. But only when/if a failure has occurred.

So, for the concern when the FRR is operationally up and used, the other (primary) LSP is down, so in that case, I’m not sure we can still call it merging.

PHP is by default not allowed in the MPLS-TP and I think that is clear in the frame work document.

Suggestion – worth to mention but a non- issue.

./

Lieven

1. LSP Merge:

o 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

o One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.

o 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

o Status of this topic in the -00 draft: not mentioned at all

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant <at> cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

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.

2. LSP Merge:

o 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

o One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge.

o 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

o Status of this topic in the -00 draft: not mentioned at all

3. Per-Interface Label Space:

o The draft states that per-interface label space MAY be used in MPLS-TP

o 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

o 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).

o Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031.

4. Sections:

o The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections).

o 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)?

o 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

5. Label Allocation Schemes:

o 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

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

o 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)

o Status of this topic in the -00 draft: requires clarification

6. MAC addresses on Ethernet data links in MPLS-TP:

o The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs

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

o 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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Internet-Drafts | 4 Feb 2010 12:45

I-D Action:draft-ietf-mpls-tp-linear-protection-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : MPLS-TP Linear Protection
	Author(s)       : S. Bryant, et al.
	Filename        : draft-ietf-mpls-tp-linear-protection-00.txt
	Pages           : 20
	Date            : 2010-02-04

The MPLS Transport Profile (MPLS-TP) being specified jointly by IETF
and ITU-T includes requirements documents and framework documents.
The framework documents define the basic architecture that is needed
in order to support various aspects of the required behavior.  This
document addresses the functionality described in the MPLS-TP
Survivability Framework document and defines a protocol that may be
used to fulfill the function of the Protection State Coordination for
linear protection, as described in that document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment (draft-ietf-mpls-tp-linear-protection-00.txt): message/external-body, 70 bytes

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Internet-Drafts | 4 Feb 2010 13:15

I-D Action:draft-ietf-mpls-tp-framework-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : A Framework for MPLS in Transport Networks
	Author(s)       : M. Bocci, et al.
	Filename        : draft-ietf-mpls-tp-framework-10.txt
	Pages           : 49
	Date            : 2010-02-04

This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched transport networks.  It describes a
common set of protocol functions - the MPLS Transport Profile
(MPLS-TP) - that supports the operational models and capabilities
typical of such networks, including signaled or explicitly
provisioned bi-directional connection-oriented paths, protection and
restoration mechanisms, comprehensive Operations, Administration and
Maintenance (OAM) functions, and network operation in the absence of
a dynamic control plane or IP forwarding support.  Some of these
functions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the
requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths.  The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Attachment (draft-ietf-mpls-tp-framework-10.txt): message/external-body, 70 bytes

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Alexander Vainshtein | 4 Feb 2010 14:12

Re: Label alloc. Schemes in data-plane-draft'

Lieven,

Lots of thanks for a prompt response.

IMHO and FWIW the label allocation scheme is not just a control plane issue.

Please note that, as per RFC 5332, MPLS packets with upstream-allocated labels use a different code point on Ethernet links and GRE tunnels.

To me this is a data plane issue.

What is more, upstream-allocated labels must refer to a certain context by the downstream router. And context resolution is part of the data plane as well.

Regards,

Sasha

From: LEVRAU, LIEVEN (LIEVEN) [mailto:lieven.levrau <at> alcatel-lucent.com]
Sent: Wednesday, February 03, 2010 9:06 AM
To: Alexander Vainshtein; stbryant <at> cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: Label alloc. Schemes in data-plane-draft'

Hello Shasha

Changed title from Comments on draft-fbb-mpls-tp-data-plane-00 -> Label alloc. Schemes in data-plane-draft’

In my view - This is a control plane issue and not a data plane issue. How the labels are assigned is outside the scope of the draft.

./

Lieven

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

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Alexander Vainshtein
Sent: 01 February 2010 18:00
To: stbryant <at> cisco.com; 'Dan Frost'; Bocci, Matthew (Matthew)
Cc: mpls <at> ietf.org; mpls-tp <at> ietf.org
Subject: [mpls] Comments on draft-fbb-mpls-tp-data-plane-00

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.

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

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.

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

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

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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28

140	May 2013
90	April 2013
148	March 2013
142	February 2013
184	January 2013
173	December 2012
167	November 2012
193	October 2012
72	September 2012
176	August 2012
226	July 2012
105	June 2012
83	May 2012
95	April 2012
216	March 2012
86	February 2012
100	January 2012
83	December 2011
149	November 2011
141	October 2011
120	September 2011
147	August 2011
303	July 2011
184	June 2011
247	May 2011
182	April 2011
229	March 2011
107	February 2011
148	January 2011
183	December 2010
145	November 2010
170	October 2010
56	September 2010
121	August 2010
217	July 2010
118	June 2010
114	May 2010
168	April 2010
319	March 2010
112	February 2010
92	January 2010
40	December 2009
77	November 2009
66	October 2009
40	September 2009
25	August 2009
56	July 2009
26	June 2009
22	May 2009
16	April 2009
90	March 2009
33	February 2009
18	January 2009
32	December 2008
85	November 2008
115	October 2008
91	September 2008
88	August 2008
63	July 2008
41	June 2008
69	May 2008
74	April 2008
49	March 2008
76	February 2008
29	January 2008
24	December 2007
46	November 2007
32	October 2007
47	September 2007
12	August 2007
44	July 2007
39	June 2007
42	May 2007
33	April 2007
64	March 2007
30	February 2007
49	January 2007
37	December 2006
70	November 2006
49	October 2006
69	September 2006
18	August 2006
36	July 2006
79	June 2006
48	May 2006
103	April 2006
26	March 2006
79	February 2006
29	January 2006
50	December 2005
31	November 2005
38	October 2005
32	September 2005
54	August 2005
37	July 2005
32	June 2005
42	May 2005
32	April 2005
58	March 2005
84	February 2005
26	January 2005
52	December 2004
63	November 2004
111	October 2004
46	September 2004
44	August 2004
34	July 2004
93	June 2004
121	May 2004
83	April 2004
133	March 2004
88	February 2004
82	January 2004
26	December 2003
227	November 2003
121	October 2003
82	September 2003
89	August 2003
118	July 2003
167	June 2003
86	May 2003
161	April 2003
396	March 2003
195	February 2003
164	January 2003
374	December 2002
221	November 2002
157	October 2002
102	September 2002
147	August 2002
435	July 2002
192	June 2002
277	May 2002
245	April 2002