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

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 27 Feb 2009 16:38:55 +0100

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

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

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: giovedì 26 febbraio 2009 2.19
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Feb 2009 16:31:45 -0000

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

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.

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: giovedì 26 febbraio 2009 2.19
To: Annamaria Fulignoli; [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection requirement 
on " draft-ietf-mpls-tp-requirements-04"

Annamaria,

>  B) Unidirectional 1:n protection for P2MP connectivity MAY be

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

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: George Swallow <[email-masked]>
Date: Fri, 27 Feb 2009 13:26:23 -0500

Getting back to the requirement.

What does n:1 P2MP mean.  Do we believe that there will exist lots of P2MP
circuits with the exact same set of end-points.  And that there will
topologies with lots of SRLG diverse paths to those end-points.   Could we
hear about some real-world use cases before signing up to this?

...George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 28 Feb 2009 14:09:59 +0000

George,

> hear about some real-world use cases before signing up to this?

I can think of real world requirement we have for this on our existing MPLS
network but I am not prepared, at this time, to describe the scenario
publicly.

However, I would note that the scenario I have in mind is likely to only
require 1:1 not generic n:1 protection.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Feb 2009 14:14:20 -0000

can we be tidy wrt 1:n and n:1?

(Crying "All for one and one for all" and leaping into the fray)

A

----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "George Swallow" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; "Annamaria Fulignoli" 
<[email-masked]>; <[email-masked]>
Sent: Saturday, February 28, 2009 2:09 PM
Subject: Re: [Mpls-interop] MPLS-TP 1+1 bidirectional protection 
requirementon " draft-ietf-mpls-tp-requirements-04"