Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement on " draft-ietf-mpls-tp-requirements-04"

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 2 Mar 2009 08:27:59 +0100

Ben,

As far as I can understand from Annamaria's mail, the problem is that
1:n protection requires a return path:

> > -  I can understand that for p2mp the 1:n (unidirectional) 
> protection is
> > required; however please note that it needs a return path 
> from leaf to
> > root to signal the failure; 

Therefore, if 1:n protection for p2mp unidirectional transport paths is
a MUST, then also a solution for implementing a return path with p2mp
unidirectional transport paths is also a MUST for the toolking. Note
that such a transport path MUST NOT rely upon the presence of a control
plane because of other MPLS-TP requirements.

If everybody agrees with the latter (i.e. the return path for p2mp
transport paths) then we can keep the MUST for 1:n protection switching.
Otherwise, we should qualify the requirement either with a MAY or with a
SHOULD.

My preference is to qualify the requirement as a SHOULD (for the
toolkit).

Italo

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Thursday, February 26, 2009 2:19 AM
> To: Annamaria Fulignoli; [email-masked]
> Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional 
> protection requirement on " draft-ietf-mpls-tp-requirements-04"
> 
> Annamaria,
> 
> Thanks, please see below.
> 
> On 24/02/2009 15:32, "Annamaria Fulignoli"
> <[email-masked]> wrote:
> 
> > Hi Ben,
> > thank you for your answer.
> > 
> > About requirement 54, following the operators requirements as you've
> > described , I agree with the changes you've proposed.
> > 
> > About requirement 55 I think that:
> > -  for p2p only the bidirectional protection switching MUST be
> > supported.
> > -  for p2p I do not see needs for unidirectional protection as yet
> > reported in C ( my interpretation is that it is not supported in
> > MPLS-TP)
> > -  I can understand that for p2mp the 1:n (unidirectional) 
> protection is
> > required; however please note that it needs a return path 
> from leaf to
> > root to signal the failure;
> > 
> > Maybe we could change the requirement 55 with the following:
> > 
> > MPLS-TP MUST support 1:n protection (including 1:1 protection)
> >  A) Bidirectional  1:n protection for P2P connectivity MUST be
> > supported.
> >  B) Unidirectional 1:n protection for P2MP connectivity MAY be
> > supported.
> 
> If 1:n for P2MP is required (your earlier statement) then why 
> do you suggest
> a MAY and not a MUST? Remember the MPLS-TP requirements draft 
> does not place
> requirements of what specific implementations may choose to support as
> emphasised in the following paragraph of the Introduction
> 
>    The requirements are for the the behavior of the protocol
>    mechanisms and procedures that constitute building blocks out of
>    which the MPLS transport profile is constructed.  That is, the
>    requirements indicate what features are to be available in the MPLS
>    toolkit for use by MPLS-TP.  The requirements in this 
> document do not
>    describe what functions an MPLS-TP implementation supports.  The
>    purpose of this document is to identify the toolkit and any new
>    protocol work that is required.
> 
> As such I think the toolkit MUST support 1:n for P2MP but individual
> implementations are free to choose whether or not they will 
> support it.
> 
> Therefore I would conclude that requirement 55 is OK as it is 
> currently
> recorded in -04.
> 
> Ben
> 
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 2 Mar 2009 08:28:49 +0100

We have agreed that the requirements are for the toolkit and not for the implementation and that was clarified in the Introduction of the document as pointed out by Ben.

As a consequence, I think that the list of features that are required for an implementation to claim compliancy with MPLS-TP are outside the scope of draft-ietf-mpls-tp-requirements-04.

However, MPLS-TP is a transport profile of MPLS.

I understood the plan was that IETF defines such a transport profile.

If my understanding was correct, then Annamaria's remark is valid: we need an IETF document that defines the transport profile of MPLS (MPLS-TP).

Thanks, Italo

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, February 27, 2009 5:32 PM
> To: Annamaria Fulignoli; Ben Niven-Jenkins; [email-masked]
> protectionrequirementon " draft-ietf-mpls-tp-requirements-04"
> 
> Hi,
> 
> This has been said over and over.
> 
> The requirements are requirements for the toolkit. They say 
> what functions 
> MPLS-TP itself must support.
> 
> They say nothing about what level of implementation is required.
> 
> In general the IETF does not do conformance statements, and 
> this is good and 
> proper. We may find, on the other hand, that a protocol spec 
> includes "MUST" 
> language about protocol behavior - but that sort of language 
> is present to 
> ensure interoperability between implementations that both 
> claim to conform 
> to the same function/features within the specification.
> 
> For example, MPLS-TP MUST include P2MP support. Does that 
> mean that an 
> implementation MUST support P2MP? Clearly not. This is an 
> issue between the 
> implementer and the customer.
> 
> Other bodies sometimes produce implementation profiles of 
> IETF RFCs in order 
> to facilitate mindless purchasing.
> 
> Cheers.
> Adrian
> ----- Original Message ----- 
> From: "Annamaria Fulignoli" <[email-masked]>
> To: "Ben Niven-Jenkins" <[email-masked]>; 
> <[email-masked]>
> Sent: Friday, February 27, 2009 3:38 PM
> Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection 
> requirementon " draft-ietf-mpls-tp-requirements-04"
> 
> 
> Hi Ben,
> you wrote:
> > MPLS-TP requirements draft does not place requirements of 
> what specific 
> > implementations may choose to support as emphasised in the 
> following 
> > paragraph
> > of the Introduction
> The implication of this statement is that another document is 
> required to 
> say whether a node, in a particular operational scenario, 
> provides a valid 
> subset of MPLS-TP features i.e. what is absolutely required 
> or absolutely 
> prohibited, may or may not exist in particular circumstances, 
> be optional or 
> vendor-specific.
> 
> 
> Thank you and kind regards
> Annamaria
> 
> 
> 
> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: giovedì 26 febbraio 2009 2.19
> protection
> > is required; however please note that it needs a return 
> path from leaf
> > to root to signal the failure;
> >

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Mon, 2 Mar 2009 08:11:21 -0500

I think what we're getting stuck on here is the definition of the word
"profile".

Typically, "profiles" have been defined by industry forums and consortia
that are really a conformance statement - this is the minimum that must
be implemented by a vendor in order to claim conformance to a standard.
Such profiles are used by vendors as an aid to assist their product
development plans, sometimes used as the basis for conformance testing,
and as Adrian pointed out, sometimes used by service providers as an
input in their purchasing decisions. This is the use of the word
"profile" that Annamaria and Italo are using.

In this case, "profile" has a different definition - a subset of the
larger MPLS protocol/toolset suite that is required for transport
applications.

MPLS-TP will still be a protocol/toolset specification, not an equipment
conformance statement. Such conformance statements have typically been
done outside of the IETF, in organizations such as the IP/MPLS Forum,
OIF, MEF, and so on.

However, we've been blazing a lot of new ground with MPLS-TP work. So,
once we have a complete set of requirements and a protocol definition,
we could decide to write a conformance statement as well. Or we could
leave that to the industry consortia.

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of BUSI ITALO
Sent: Monday, March 02, 2009 2:29 AM
To: Adrian Farrel; Annamaria Fulignoli; Ben Niven-Jenkins;
[email-masked]
Subject: Re: [Mpls-interop] MPLS-TP 1+1
bidirectionalprotectionrequirementon "
draft-ietf-mpls-tp-requirements-04"

We have agreed that the requirements are for the toolkit and not for the
implementation and that was clarified in the Introduction of the
document as pointed out by Ben.

As a consequence, I think that the list of features that are required
for an implementation to claim compliancy with MPLS-TP are outside the
scope of draft-ietf-mpls-tp-requirements-04.

If my understanding was correct, then Annamaria's remark is valid: we
need an IETF document that defines the transport profile of MPLS
(MPLS-TP).

Thanks, Italo

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 3 Mar 2009 14:34:13 +0100

As an input for our call today, please find in attachment the latest
editors' draft of the OAM Framework I-D

Italo

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 03 Mar 2009 23:07:53 +0000

Andy,

Thanks you have communicated what I was trying to say in a much more
articulate manner than I managed.

Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 6 Mar 2009 13:48:26 +0100

Please find attached an updated version of OAM Framework draft, updated
as per the discussion on the MEAD team call on 3 March.

I am planning to upload the new version before the cutoff deadline
IETF74.

Thanks, Italo

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 17 Mar 2009 16:39:52 +0100

Please find attached an updated version of OAM Framework draft, updated
as per discussion on the MEAD team call on 10 March.

We have some pending comments to be resolved in the next version of the
draft but none of them is considered a blocking issue precluding the
draft from being adopted as a WG document.

Thanks, Italo

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 23 Mar 2009 10:57:25 -0700

Hi Adrian and Nurit,

I would like to see a reference to RFC4090 in section 4.4.3.

Thanks,
rahul

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 23 Mar 2009 19:07:43 +0100

I think we need to do more than just adding a reference to RFC4090.

For each mechanism described in this draft (including also FRR), we need
to discuss and describe how it works in the MPLS-TP environment, taking
into consideration MPLS-TP requirements and in particular co-routed
bidirectional transport paths, bidirectional protection switching and
support of operator's commands.

Italo

> [mailto:[email-masked]] On Behalf Of Rahul Aggarwal
> Sent: Monday, March 23, 2009 10:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Mpls-interop] Comment on 
> draft-sprecher-mpls-tp-survive-fwk-01.txt
> 
> 
> Hi Adrian and Nurit,
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Mar 2009 01:20:06 -0000

Yes Rahul,

I understand the need for a reference to 4090 in the document.

I know 4.4.3 seems the obvious place to put this reference, but the 
intention of the whole of section 4 is to describe data plane techniques 
without reference to how they are established or managed. Hence no reference 
to management or control plane.

In section 5, however, we start to reference mechanisms to support the 
techniques described in section 4. Section 5.5 is about the control plane, 
and section 5.5.6 is called "Establishment of Protection and Restoration 
LSPs". I believe it is here that we should place the reference.

Would you like to supply a (short :-) paragraph to go in that section?

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Mar 2009 01:27:33 -0000

Italo,

> support of operator's commands.

Yes, but...  :-)

I think you are right that section 5 must show how existing mechanisms may 
be used to meet some/all of the MPLS-TP protection requirements. Hopefully 
this will also show if some of the solutions are not applicable to some of 
the requirements.

Note that it is not required that a single mechanism meets all requirements. 
It is necessary that each requirement can be met by at least one mechanism.

Text is welcome!

Cheers,
Adrian

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 24 Mar 2009 12:27:59 -0400

Adrian, not sure I like the implication that I must run multiple
mechanisms to meet the requirements of a given deployment scenario.  See
in line below.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, March 23, 2009 9:28 PM
To: BUSI ITALO; Rahul Aggarwal; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Mpls-interop]
Commentondraft-sprecher-mpls-tp-survive-fwk-01.txt

Italo,

> For each mechanism described in this draft (including also FRR), we 
> need to discuss and describe how it works in the MPLS-TP environment, 
> taking into consideration MPLS-TP requirements and in particular 
> co-routed bidirectional transport paths, bidirectional protection 
> switching and support of operator's commands.

Yes, but...  :-)

I think you are right that section 5 must show how existing mechanisms
may be used to meet some/all of the MPLS-TP protection requirements.
Hopefully this will also show if some of the solutions are not
applicable to some of the requirements.

Note that it is not required that a single mechanism meets all
requirements. 
It is necessary that each requirement can be met by at least one
mechanism.

>MB We need to be careful with this IMHO it is preferable to have a
single mechanism to support commonly used sub sets of the requirements. 

Text is welcome!

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Mar 2009 18:04:04 -0000

> mechanisms to meet the requirements of a given deployment
> scenario.

Hmm?
I think you use lungs and legs when you go for a walk.
Everything is made up of building blocks.

>  See in line below.

Your point is valid that you don't want to be juggling lots of different 
bits and pieces.
Also that pieces that are separate need to be coordinated and compatible.

A