Subject: [mpls-tp] Fwd: I-D Action:draft-fbb-mpls-tp-p2mp-framework-00.txt

From: Loa Andersson <[email-masked]>
Date: Wed, 13 Jan 2010 17:51:28 +0100

All,

we have a new Internet Draft, a framework for mpls-tp p2mp.

The background is that we broke this out from the generic mpls-tp
framework in order to be able to progress both documents independently.

Please review the document and send comments to mpls-tp mailing
list.

/Loa

-------- Original Message --------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : A Framework for Point-to-Multipoint MPLS in Transport 
Networks
	Author(s)       : D. Frost, et al.
	Filename        : draft-fbb-mpls-tp-p2mp-framework-00.txt
	Pages           : 11
	Date            : 2010-01-13

The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
is the common set of MPLS protocol functions defined to enable the
construction and operation of packet transport networks.  The MPLS-TP
supports both point-to-point and point-to-multipoint transport paths.
This document defines the elements and functions of the MPLS-TP
architecture applicable specifically to supporting point-to-
multipoint transport paths.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
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.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fbb-mpls-tp-p2mp-framework-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.

---

From: Dan Frost <[email-masked]>
Date: Wed, 13 Jan 2010 17:24:36 +0000

Hi,

This is a short document that primarily intends to summarise the P2MP
content from the other frameworks (CP, OAM, Survivability).  The
editors would therefore like to ask the authors of those frameworks
to contribute summary text for the respective sections in this document
that is consistent with the point-to-multipoint architecture described
in their frameworks.  We'll be in touch on this topic unless you get
to us first.  ;)

Cheers,

-d

On Wed, Jan 13, 2010 at 05:51:28PM +0100, Loa Andersson wrote:
> 	Title           : A Framework for Point-to-Multipoint MPLS in 
> 	Transport Networks
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Fri, 15 Jan 2010 17:55:07 +0000

Two comments after a quick read.

1) Section 1.2.1. Probably worth having an informative reference to
draft-ietf-mpls-tp-rosetta-stone

2) Section 3.1 states packet encapsulation & forwarding is identical to
RFC4875 and RFC5332. Is this true - the MPLS-TP (P2P) framework includes
quite a bit of text related to the Gach & GAL. I think we need something
equivalent (or references if the usage is identical) in this draft.

Ben

---

From: David Allan I <[email-masked]>
Date: Wed, 20 Jan 2010 17:30:02 -0500

Happy to oblige, but before I craft some text I think a couple of the requirements need to be tweaked...

In particular

   o  Recovery techniques used for P2P and P2MP should be identical to
      simplify implementation and operation.

Given we have unidirectional P2P, associated bi-directional P2P and co-routed bi-directional P2P, and just uni-directional P2MP, apples to apples would suggest "for uni-directional P2P and P2MP..." should be what is actally stated.

   o  Unidirectional 1+1 and 1:n protection for P2MP connectivity must
      be supported.

In essence any 1:n system is head end switched. The only way a MEG could be constructed to meet this requirement and be consistent with the TP definitions and scope would be an artificial construct of a p2mp path root to leaves, and a unique co-routed p2p path for each leaf back to the root such that an OAM message to trigger a head end switch could flow from a MIP on the P2P path back to the root. This also means that most failure scenarios would result in multiple MIPs originating AIS/LFI traffic back to the root. I don't think anything like this is on the drawing board. The only viable alternative is that non-TP return paths are used, which are optional. This suggests the requirement should stated as "must" for 1+1 and "should" for 1:n....

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Frost
Sent: Wednesday, January 13, 2010 12:25 PM
To: [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D Action:draft-fbb-mpls-tp-p2mp-framework-00.txt

Hi,

This is a short document that primarily intends to summarise the P2MP content from the other frameworks (CP, OAM, Survivability).  The editors would therefore like to ask the authors of those frameworks to contribute summary text for the respective sections in this document that is consistent with the point-to-multipoint architecture described in their frameworks.  We'll be in touch on this topic unless you get to us first.  ;)

Cheers,

-d

On Wed, Jan 13, 2010 at 05:51:28PM +0100, Loa Andersson wrote:
> Please review the document and send comments to mpls-tp mailing list.
> 
> /Loa
> 
> Internet-Drafts are working documents of the Internet Engineering Task 
> Force (IETF), its areas, and its working groups.  Note that other 
> groups may also distribute working documents as Internet- Drafts.
> 
> include Simplified BSD License text as described in Section 4.e of the 
> Trust Legal Provisions and are provided without warranty as described 
> in the BSD License.
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 21 Jan 2010 00:37:45 +0100

Dave,

> an OAM message to trigger a head end switch could flow
> from a MIP on the P2P path back to the root.
> This also means that most failure scenarios would result in
> multiple MIPs originating AIS/LFI traffic back to the root.

MIPs do not generate AIS signals. AIS signals are generated by the
adaptation sink function belonging to the MEP that detects the
signal fail type defect.

If you need to protect a 1+1 unidir p2mp connection, then this can be done
with unidirectional switching; i.e. with leaf side monitoring only. There is
in such case no need for a return path as there is no APS protocol to run.
P2mp connections support a distribution service (e.g. TV signals), and often
associate with duplicated head end systems as well. There are in this case
two roots, which are connected via two diverse rooted unidirectional p2mp
connections to n leafs. A leaf must switch to the standby connection when
the active connection has a signal fail or signal degrade condition (and the
standby connection doesn't have such SF/SD condition). A leaf must also
switch when the connection between the head end system and the p2mp
connection fails, and also when the head end system fails. These two
conditions require that the traditional protection swithcing trigger
conditions (SF,SD) have to be complemented by a client signal fail (CSF)
condition.

I agree with you that 1:n p2mp protection switching would require the set up
of p2p return paths from each leaf to the root (single root). For the
duplicated root case p2p return paths from each leaf to each root would have
to be set up. And in addition a p2p bidir connection between the roots. 

Note that such "bidirectional p2mp connections" (i.e. one unidir p2mp
connection from signle root to n leaves, n unidir p2p connections from each
leaf to the root) are specified in 802.1Qay; the "Point-to-multipoint TE
service instance".

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Allan I
Sent: woensdag 20 januari 2010 23:30
To: Dan Frost; [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D
Action:draft-fbb-mpls-tp-p2mp-framework-00.txt

Happy to oblige, but before I craft some text I think a couple of the
requirements need to be tweaked...

In particular

Given we have unidirectional P2P, associated bi-directional P2P and
co-routed bi-directional P2P, and just uni-directional P2MP, apples to
apples would suggest "for uni-directional P2P and P2MP..." should be what is
actally stated.

In essence any 1:n system is head end switched. The only way a MEG could be
constructed to meet this requirement and be consistent with the TP
definitions and scope would be an artificial construct of a p2mp path root
to leaves, and a unique co-routed p2p path for each leaf back to the root
such that an OAM message to trigger a head end switch could flow from a MIP
on the P2P path back to the root. This also means that most failure
scenarios would result in multiple MIPs originating AIS/LFI traffic back to
the root. I don't think anything like this is on the drawing board. The only
viable alternative is that non-TP return paths are used, which are optional.
This suggests the requirement should stated as "must" for 1+1 and "should"
for 1:n....

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Frost
Sent: Wednesday, January 13, 2010 12:25 PM
To: [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D
Action:draft-fbb-mpls-tp-p2mp-framework-00.txt

Hi,

This is a short document that primarily intends to summarise the P2MP
content from the other frameworks (CP, OAM, Survivability).  The editors
would therefore like to ask the authors of those frameworks to contribute
summary text for the respective sections in this document that is consistent
with the point-to-multipoint architecture described in their frameworks.
We'll be in touch on this topic unless you get to us first.  ;)

Cheers,

-d

---

From: David Allan I <[email-masked]>
Date: Wed, 20 Jan 2010 19:08:49 -0500

Hi Maarten: 

> an OAM message to trigger a head end switch could flow from a MIP on 
> the P2P path back to the root.
> This also means that most failure scenarios would result in multiple 
> MIPs originating AIS/LFI traffic back to the root.

MIPs do not generate AIS signals. AIS signals are generated by the adaptation sink function belonging to the MEP that detects the signal fail type defect.

DA> poor choice of terms. What I was trying to illustrate was that if co-routed p2p LSPs were used as a return path to produce a closed OAM system capable of head end switching, a single failure could result in a number of sources of failure indication colocated at a node adjacent to the failure generating PDUs back to the root.

If you need to protect a 1+1 unidir p2mp connection, then this can be done with unidirectional switching; i.e. with leaf side monitoring only. There is in such case no need for a return path as there is no APS protocol to run.

DA> Violent agreement.

P2mp connections support a distribution service (e.g. TV signals), and often associate with duplicated head end systems as well. There are in this case two roots, which are connected via two diverse rooted unidirectional p2mp connections to n leafs. A leaf must switch to the standby connection when the active connection has a signal fail or signal degrade condition (and the standby connection doesn't have such SF/SD condition). A leaf must also switch when the connection between the head end system and the p2mp connection fails, and also when the head end system fails. These two conditions require that the traditional protection swithcing trigger conditions (SF,SD) have to be complemented by a client signal fail (CSF) condition.

I agree with you that 1:n p2mp protection switching would require the set up of p2p return paths from each leaf to the root (single root). For the duplicated root case p2p return paths from each leaf to each root would have to be set up. And in addition a p2p bidir connection between the roots.

DA> More violent agreement....

Note that such "bidirectional p2mp connections" (i.e. one unidir p2mp connection from signle root to n leaves, n unidir p2p connections from each leaf to the root) are specified in 802.1Qay; the "Point-to-multipoint TE service instance".

DA> yes, agreed, though I believe with shared forwarding the return path could be constructed more frugally than a literal "leaf x p2p" connections of forwarding state

Best regards
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: woensdag 20 januari 2010 23:30
To: Dan Frost; [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D

In particular

In essence any 1:n system is head end switched. The only way a MEG could be constructed to meet this requirement and be consistent with the TP definitions and scope would be an artificial construct of a p2mp path root to leaves, and a unique co-routed p2p path for each leaf back to the root such that an OAM message to trigger a head end switch could flow from a MIP on the P2P path back to the root. This also means that most failure scenarios would result in multiple MIPs originating AIS/LFI traffic back to the root. I don't think anything like this is on the drawing board. The only viable alternative is that non-TP return paths are used, which are optional.
This suggests the requirement should stated as "must" for 1+1 and "should"
for 1:n....

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Frost
Sent: Wednesday, January 13, 2010 12:25 PM
To: [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D

Hi,

This is a short document that primarily intends to summarise the P2MP content from the other frameworks (CP, OAM, Survivability).  The editors would therefore like to ask the authors of those frameworks to contribute summary text for the respective sections in this document that is consistent with the point-to-multipoint architecture described in their frameworks.
We'll be in touch on this topic unless you get to us first.  ;)

Cheers,

-d

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Jan 2010 06:40:40 -0500

On 1/20/2010 5:30 PM, David Allan I wrote:
 > This suggests the requirement should stated as "must" for 1+1 and 
"should" for 1:n....

Dave,

This is straight from RFC5654 req 65.C and 67.B...

Lou

---

From: David Allan I <[email-masked]>
Date: Thu, 21 Jan 2010 09:30:06 -0500

Hmmmm

I was wondering if I'd encounter something like that. I'll have to think about how to square this circle... As I'd consider the requirement aspirational, and not necessarily practically realizable given the constraints... If such a thing is to be accomplished we need a bi-directional P2MP, or absolutely mandate use of non-TP return paths instead of simply "smoke 'em IF you have them..."

D 

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 6:41 AM
To: David Allan I
Cc: Dan Frost; [email-masked]; Loa Andersson
Subject: Re: [mpls-tp] Fwd: I-D Action:draft-fbb-mpls-tp-p2mp-framework-00.txt

On 1/20/2010 5:30 PM, David Allan I wrote:
 > This suggests the requirement should stated as "must" for 1+1 and "should" for 1:n....

Dave,

Lou

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 21 Jan 2010 16:54:40 +0100

Hi Dave,

> Note that such "bidirectional p2mp connections" (i.e. one unidir p2mp
connection from
> signle root to n leaves, n unidir p2p connections from each leaf to the
root) are
> specified in 802.1Qay; the "Point-to-multipoint TE service instance".
>
> DA> yes, agreed, though I believe with shared forwarding the return path 
> DA> could be constructed more frugally than a literal "leaf x p2p" 
> DA> connections of forwarding state 

The amount of state in the data plane (i.e. switch fabrics) will be indeed
be less due to administrating only a subset of the TESI label values, but
the amount of state in the management system is the same; i.e. each unidir
p2p ESP needs to be administered I assume... Or can this also be done in a
shared manner?

In MPLS one could emulate the administration of PBB-TE ESPs by means of
using two labels to identify a tunnel LSP, i.e. an inner source label plus
an outer destination label. P nodes can now administer the shared
destination label. PE NNI ports need to push/pop now two label stack entry
headers instead of one.

Regards,
Maarten

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: donderdag 21 januari 2010 1:09
To: Maarten Vissers; 'Dan Frost'; [email-masked]; 'Loa Andersson'
Subject: RE: [mpls-tp] Fwd: I-D

MIPs do not generate AIS signals. AIS signals are generated by the
adaptation sink function belonging to the MEP that detects the signal fail
type defect.

DA> poor choice of terms. What I was trying to illustrate was that if
co-routed p2p LSPs were used as a return path to produce a closed OAM system
capable of head end switching, a single failure could result in a number of
sources of failure indication colocated at a node adjacent to the failure
generating PDUs back to the root.

DA> Violent agreement.

DA> yes, agreed, though I believe with shared forwarding the return path 
DA> could be constructed more frugally than a literal "leaf x p2p" 
DA> connections of forwarding state

Best regards
Dave

-----Original Message-----

In particular

Cheers
Dave

-----Original Message-----

Hi,

Cheers,

-d