Subject: Re: [mpls-tp] [CCAMP] [mpls]Term"PSC" indraft-ietf-mpls-tp-linear-protection-01

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 10:32:56 +0200

Adrian,

I think that this thread discussion is actually proving that the idea to re-define a new term for what everybody in the world known as APS was not a good idea.

We therefore better come back and adopt the widely known concept rather than inventing a new term and confuse the whole industry.

Regarding your references, I think it is worth clarifying that:

- APS is a generic term for the coordination protocol and does not imply any specific protocol implementation;

- Ethernet APS is a specific protocol specification of APS in Ethernet networks and it is defined in G.8031;

- SONET/SDH APS is a specific protocol specification of APS in SONET/SDH networks and it is defined in G.841;

- OTN APS is a specific protocol specification of APS in OTN networks and it is defined in G.873.1

What IETF actually should define the specific realization of APS in MPLS-TP networks.

I do not see any value in calling PSC such a specific realization while I can see a huge value in calling it as "MPLS-TP APS".

Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Adrian Farrel
> Sent: giovedì 25 marzo 2010 1.33
> To: [email-masked]; Cecil Byles
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC" 
> indraft-ietf-mpls-tp-linear-protection-01
> 
> Huub,
> 
> You will note that the comment in the liaison you reference said:
> 
> "The acronyms PSC and APS are used, in ITU-T APS is a generic 
> term used in different methodologies and does not provide a solution."
> 
> This was neither a question nor a request for any change. And 
> it is not really clear that it is a "concern".
> 
> APS is an abstract protocol (G.808.1) with specific 
> characteristics and behaviors.
> 
> The Survivability Framework deliberately does not prejudge 
> the abstract protocol or solution protocol that is required. 
> Instead, it picked another acronym to avoid any assumptions. 
> This frees the people working in the solution space to choose 
> the necessary abstract model for the problems they need to 
> solve, and to develop a protocol realisation that meets the model. 
> This neither precludes nor forces the use of APS.
> 
> If you like, PSC is simply a generalisation that allows 
> freedom of interpretation. Viz.
> 
>    In some protection switching schemes (such as bidirectional
>    protection switching), it is necessary to coordinate the protection
>    state between the edges of the recovery domain.  An MPLS-TP
>    Protection State Coordination (PSC) protocol may be used as an in-
>    band (i.e., data plane-based) control protocol to align 
> both ends of
>    the protected domain.  Control plane-based mechanism can 
> also be used
>    to coordinate the protection states between the edges of the
>    protection domain.
> 
> In the view of the authors, the term "APS" has become 
> synonymous with specific protocol realisations. For example, 
> in the working copy of G.8131 I have infront of me, section 
> 10 describes the "APS Protocol" setting out byte formats and 
> defining messages to go on the wire. While we can interpret 
> "APS Protocol" as the technology-specific realisation of 
> "APS", there are sufficient overtones that if the 
> Survivability Framework used the term "APS" 
> it might be construed as support for a specific protocol 
> realisation. Y.1731 defines APS PDUs for Ethernet which gives 
> us another competing interpretation of the term. (It is 
> notable that the term "APS Protocol" is used in G.870 to mean 
> the abstract protocol, which is subtly different from its use 
> in G.8131 and Y.1731.)
> 
> Surely the working group would prefer to derive the correct 
> protocol solution without being constrained except at a 
> functional level?
> 
> Adrian
> 
> 
> ----- Original Message -----
> From: "Huub van Helvoort" <[email-masked]>
> To: "Cecil Byles" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 24, 2010 5:14 PM
> Subject: Re: [CCAMP] [mpls-tp] [mpls] Term"PSC" 
> indraft-ietf-mpls-tp-linear-protection-01
> 
> 
> Hello Cecil,
> 
> You wrote:
> 
> > Can I therefore also asked how PSC "Protection State 
> Coordination" in the 
> > MPLS-TP parlance align with ITU-T 808.1 recommendation that 
> "defines the 
> > generic functional models, characteristics and processes 
> associated with 
> > various linear protection schemes for connection-oriented 
> layer networks; 
> > e.g., Optical Transport Networks (OTN), Synchronous Digital 
> Hierarchy 
> > (SDH) networks and Asynchronous Transfer Mode (ATM) 
> networks" and the 
> > sections covering  Terms and Definitions as well as 
> Abbreviations.  IMO 
> > all transport engineers and the general telecom community 
> understand that 
> > 1+1 or 1:1 are either SNCP or APS. Hence why introduce a 
> new TLA (three 
> > letter abbreviation) cover the same function and feature 
> for MPLS-TP.  I 
> > can only agree that this will only cause confusion.
> 
> I agree with you.
> 
> In addition to that:
> The ITU-T experts that reviewed the survivability draft had the same
> concerns, and expressed that in their reply liaison for the review of
> this draft: https://datatracker.ietf.org/liaison/618/ that was
> sent in november last year.
> This concern has not been addressed yet.
> 
> Regards, Huub.
> 
> 
> -- 
> ================================================================
> Always remember that you are unique...just like everyone else...
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 10:54:49 +0100

Hi,

It's not my job to judge consensus on this list. But as one of the editors 
of the Survivability Framework I have to move the draft forward.

What I think I see is:
- Most people prefer not to use the acronym PSC because they
  fear people will be confused especially by the expansion Packet
  Switch Capable.
- A number of people prefer to use the term APS because this is
   an established abstract protocol that provides the function needed
- A number of people prefer to avoid the term APS for two reasons:
   - they don't want the framework to constrain even the abstract
      solution
   - they fear that using the term will constrain the solution to a
      specific message flow/format

I can see that the answer in draft-ietf-mpls-tp-linear-protection may be 
very different from the answer for the Survivability Framework. The Linear 
Protection draft is expressing a solution and must engage in state machines, 
message flows, and bits&bytes. The Survivability Framework, on the other 
hand, is at a very high level; it does not go into the details of a state 
machine, but simply says that some form of state coordination will be needed 
through a protocol.

At this stage I propose to use the acronym "RSC" (Recovery State 
Coordination) to identify the protocol that will be used. IMHO this does not 
prohibit in any way the use of the APS abstract protocol, nor the 
realisation of an MPLS-TP APS. On the other hand, it also does not prejudge 
the value of using APS in this situation. It seems to me to be reasonable to 
phase our work, and this is one way of splitting the decisions points.

So (for the Survivability Framework only) I am seeking consensus that we use 
"RSC".

Thanks,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
"Cecil Byles" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 02, 2010 9:32 AM
Subject: RE: [CCAMP] [mpls-tp] 
[mpls]Term"PSC"indraft-ietf-mpls-tp-linear-protection-01

Adrian,

I think that this thread discussion is actually proving that the idea to 
re-define a new term for what everybody in the world known as APS was not a 
good idea.

We therefore better come back and adopt the widely known concept rather than 
inventing a new term and confuse the whole industry.

- APS is a generic term for the coordination protocol and does not imply any 
specific protocol implementation;

- Ethernet APS is a specific protocol specification of APS in Ethernet 
networks and it is defined in G.8031;

- SONET/SDH APS is a specific protocol specification of APS in SONET/SDH 
networks and it is defined in G.841;

- OTN APS is a specific protocol specification of APS in OTN networks and it 
is defined in G.873.1

What IETF actually should define the specific realization of APS in MPLS-TP 
networks.

I do not see any value in calling PSC such a specific realization while I 
can see a huge value in calling it as "MPLS-TP APS".

Italo

P.S. Please note my new email address, [email-masked], 
effective since 1 November 2009.

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 12:05:36 +0200

Adrian,

>    - they don't want the framework to constrain even the abstract

APS-based protection switching is a key transport requirement to be addressed by the framework document.

>       specific message flow/format

This is based on incorrect understanding of the term APS.
Given statement above, I also have good reasons to fear that the usage of a different term is a lack of commitment to develop an APS solution that meets the transport requirements.

Italo

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: venerdì 2 aprile 2010 11.55
> To: BUSI ITALO; [email-masked]; Cecil Byles
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Term"PSC" in the Survivability 
> Framework [Was: in Linear Protection]
> 
> Hi,
> 
> It's not my job to judge consensus on this list. But as one 
> of the editors of the Survivability Framework I have to move 
> the draft forward.
> 
> What I think I see is:
> I can see that the answer in 
> draft-ietf-mpls-tp-linear-protection may be very different 
> from the answer for the Survivability Framework. The Linear 
> Protection draft is expressing a solution and must engage in 
> state machines, message flows, and bits&bytes. The 
> Survivability Framework, on the other hand, is at a very high 
> level; it does not go into the details of a state machine, 
> but simply says that some form of state coordination will be 
> needed through a protocol.
> 
> Coordination) to identify the protocol that will be used. 
> IMHO this does not prohibit in any way the use of the APS 
> abstract protocol, nor the realisation of an MPLS-TP APS. On 
> the other hand, it also does not prejudge the value of using 
> APS in this situation. It seems to me to be reasonable to 
> So (for the Survivability Framework only) I am seeking 
> consensus that we use "RSC".
> 
> Thanks,
> Adrian
> 
> To: "Adrian Farrel" <[email-masked]>; 
> <[email-masked]>; "Cecil Byles" <[email-masked]>
> I think that this thread discussion is actually proving that 
> the idea to re-define a new term for what everybody in the 
> world known as APS was not a good idea.
> 
> We therefore better come back and adopt the widely known 
> concept rather than inventing a new term and confuse the 
> whole industry.
> 
> - APS is a generic term for the coordination protocol and 
> does not imply any specific protocol implementation;
> 
> - Ethernet APS is a specific protocol specification of APS in 
> Ethernet networks and it is defined in G.8031;
> 
> - SONET/SDH APS is a specific protocol specification of APS 
> in SONET/SDH networks and it is defined in G.841;
> 
> I do not see any value in calling PSC such a specific 
> realization while I can see a huge value in calling it as 
> "MPLS-TP APS".
> 
> Italo
> 
> P.S. Please note my new email address, 
> [email-masked], effective since 1 November 2009.
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 11:24:24 +0100

OK,

So you are saying that APS is *an* abstract protocol that meet the 
requirements.
You are also pointing out that APS clearly meets the requirements and is 
field-proven a number of times.

But I don't see how you can say that there is a requirement to use APS-based 
protection switching. I went back to RFC 5654 to check and the only 
requirement I find is to provide protection switching. We as a community 
must work to develop/select the mechanisms that we will use.

I am not seeking to constrain that selection, but I am also not seeking to 
prejudge the selection. I think the correct place to develop the solution is 
in the Linear Protection draft, and I *do* think we need to have the full 
debate about the pros and cons of using something based on APS.

Thanks,
Adrian
----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; "Cecil 
Byles" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 02, 2010 11:05 AM
Subject: RE: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in 
Linear Protection]

Adrian,

>    - they don't want the framework to constrain even the abstract

APS-based protection switching is a key transport requirement to be 
addressed by the framework document.

This is based on incorrect understanding of the term APS.
Given statement above, I also have good reasons to fear that the usage of a 
different term is a lack of commitment to develop an APS solution that meets 
the transport requirements.

Italo

---

From: <[email-masked]>
Date: Fri, 2 Apr 2010 13:05:46 +0100

Adrian,

> must work to develop/select the mechanisms that we will use.

Spot on.

> debate about the pros and cons of using something based on APS.

Couldn't agree more.

Ben

> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 14:12:28 +0200

Adrian,

how do you read requirement 56A in RFC 5654?

Thanks, Italo

> Sent: venerdì 2 aprile 2010 12.24
> To: BUSI ITALO
> Cc: [email-masked]
> So you are saying that APS is *an* abstract protocol that 
> meet the requirements.
> You are also pointing out that APS clearly meets the 
> requirements and is field-proven a number of times.
> 
> But I don't see how you can say that there is a requirement 
> to use APS-based protection switching. I went back to RFC 
> 5654 to check and the only requirement I find is to provide 
> protection switching. We as a community must work to 
> develop/select the mechanisms that we will use.
> 
> I am not seeking to constrain that selection, but I am also 
> not seeking to prejudge the selection. I think the correct 
> place to develop the solution is in the Linear Protection 
> draft, and I *do* think we need to have the full debate about 
> the pros and cons of using something based on APS.
> 
> Thanks,
> Adrian
> To: "Adrian Farrel" <[email-masked]>; 
> Subject: RE: [mpls-tp] Term"PSC" in the Survivability 
> APS-based protection switching is a key transport requirement 
> to be addressed by the framework document.
> 
> Given statement above, I also have good reasons to fear that 
> the usage of a different term is a lack of commitment to 
> develop an APS solution that meets the transport requirements.
> 
> Italo
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 13:47:11 +0100

Hmmm.

> how do you read requirement 56A in RFC 5654?

I read it *exactly* as written.
Including the bit about not overriding other requirements.

I will repeat, that I do think we need to have the full debate about the 
pros and cons of using something based on APS. I have no particular view in 
either direction in advance of hearing the discussions, but I do resist 
adopting a technology without the debate.

Adrian

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 15:13:41 +0200

What requirements are overriden by APS?

Italo

> Sent: venerdì 2 aprile 2010 14.47
> To: BUSI ITALO
> Cc: [email-masked]
> I will repeat, that I do think we need to have the full 
> debate about the pros and cons of using something based on 
> APS. I have no particular view in either direction in advance 
> of hearing the discussions, but I do resist adopting a 
> technology without the debate.
> 
> Adrian
> 
> > But I don't see how you can say that there is a requirement to use 
> > APS-based protection switching. I went back to RFC
> protection 
> > switching. We as a community must work to develop/select the 
> > mechanisms that we will use.
> >
> > I am not seeking to constrain that selection, but I am also not 
> > seeking to prejudge the selection. I think the correct place to 
> > develop the solution is in the Linear Protection draft, and I *do* 
> > think we need to have the full debate about the pros and 
> cons of using 
> > something based on APS.
> >
> > Thanks,
> > Adrian
> > To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
> > Given statement above, I also have good reasons to fear 
> that the usage 
> > of a different term is a lack of commitment to develop an 
> APS solution 
> > that meets the transport requirements.
> >
> > Italo
> >
> > > Subject: Re: [mpls-tp] Term"PSC" in the Survivability Framework 
> > > [Was: in Linear Protection]
> > >
> > > Hi,
> > >
> > > It's not my job to judge consensus on this list. But as 
> one of the 
> > > editors of the Survivability Framework I have to move the draft 
> > > forward.
> > >
> > > What I think I see is:
> > > draft-ietf-mpls-tp-linear-protection may be very 
> different from the 
> > > answer for the Survivability Framework. The Linear 
> Protection draft 
> > > is expressing a solution and must engage in state 
> machines, message 
> > > flows, and bits&bytes. The Survivability Framework, on the other 
> > > hand, is at a very high level; it does not go into the 
> details of a 
> > > state machine, but simply says that some form of state 
> coordination 
> > > will be needed through a protocol.
> > >
> abstract 
> > > protocol, nor the realisation of an MPLS-TP APS. On the 
> other hand, 
> > > it also does not prejudge the value of using APS in this 
> situation. 
> > > It seems to me to be reasonable to phase our work, and 
> this is one 
> > > way of splitting the
> > decisions points.
> > >
> > > So (for the Survivability Framework only) I am seeking consensus 
> > > that we use "RSC".
> > >
> > > Thanks,
> > > Adrian
> > >
> > > I think that this thread discussion is actually proving that the 
> > > idea to re-define a new term for what everybody in the 
> world known 
> > > We therefore better come back and adopt the widely known concept 
> > > rather than inventing a new term and confuse the whole industry.
> > >
> does not 
> > > imply any specific protocol implementation;
> > >
> > > - SONET/SDH APS is a specific protocol specification of APS in 
> > > SONET/SDH networks and it is defined in G.841;
> > >
> > > What IETF actually should define the specific realization 
> of APS in 
> > > MPLS-TP networks.
> > >
> > > I do not see any value in calling PSC such a specific realization 
> > > while I can see a huge value in calling it as "MPLS-TP APS".
> > >
> > > Italo
> > >
> > > > From: [email-masked] [mailto:[email-masked]] On 
> > > > Behalf Of Adrian Farrel
> > > > "The acronyms PSC and APS are used, in ITU-T APS is a 
> generic term 
> > > > used in different methodologies and does not provide a
> > > solution."
> > > >
> > > > This was neither a question nor a request for any 
> change. And it 
> > > > is not really clear that it is a "concern".
> > > >
> > > > The Survivability Framework deliberately does not prejudge the 
> > > > abstract protocol or solution protocol that is required.
> > > > This frees the people working in the solution space to 
> choose the 
> > > > necessary abstract model for the problems they need to 
> solve, and 
> > > > to develop a protocol realisation that meets the model.
> > > >    band (i.e., data plane-based) control protocol to align both 
> > > > ends of
> > > >    the protected domain.  Control plane-based mechanism 
> can also 
> > > > be used
> synonymous 
> > > > with specific protocol realisations. For example, in 
> the working 
> > > > copy of G.8131 I have infront of me, section 10 
> describes the "APS 
> > > > Protocol" setting out byte formats and defining 
> messages to go on 
> > > > the wire. While we can interpret "APS Protocol" as the 
> > > > technology-specific realisation of "APS", there are sufficient 
> > > > overtones that if the Survivability Framework used the 
> term "APS"
> > > > realisation. Y.1731 defines APS PDUs for Ethernet which 
> gives us 
> > > > another competing interpretation of the term. (It is 
> notable that 
> > > > the term "APS Protocol" is used in G.870 to mean the abstract 
> > > > protocol, which is subtly different from its use in G.8131 and 
> > > > Y.1731.)
> > > >
> functional 
> > > > level?

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 14:15:31 +0100

Italo,

> What requirements are overriden by APS?

This is exactly the debate that the community should be having.
If you are right, there is nothing to be worried about.

All I am saying is that we should have the discussion in the context of the 
solutions work and not the framework. All that the framework needs to do is 
point out the high-level need for a coordination mechanism.

Can we not agree on that point and get on with the discussion that you 
obviously want to have in the context of the solutions work?

Cheers,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 02 Apr 2010 16:13:25 +0200

Hi Adrian,

You wrote:

> All I am saying is that we should have the discussion in the context of 
> the solutions work and not the framework. All that the framework needs 
> to do is point out the high-level need for a coordination mechanism.

So why not leave it at that high level and forget the introduction
of an acronym that may give the impression that thee is already a
solution.

Regards, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Apr 2010 15:22:53 +0100

Right, and the acronym only existed to stop the text repeating "protection 
state coordination".

If it is preferred that we completely avoid an abbreviation, that works for 
me.

A
----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 02, 2010 3:13 PM
Subject: Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in 
Linear Protection]

>> the solutions work and not the framework. All that the framework needs to 
>> do is point out the high-level need for a coordination mechanism.
>

---

From: [email-masked]
Date: Fri, 2 Apr 2010 11:37:13 -0500

All,

I have concerns with using the phrase Recovery State Coordination and 
consequently the acronym RSC.  The term Recovery applies to both 
protection switching and restoration.  The use of RSC implies that they 
both need to use the same coordination protocol.  This is clearly not 
true, in general restoration implies the establishment or activation of a 
new path.  I therefore support the use of the acronym APS, since it is an 
abstract protocol that is clearly scoped to protection switching and 
avoids ambiguity that it may also be applied to restoration.  In terms of 
biasing the outcome of the discussion I would note that the framework has 
already suggested the use of the RSVP-TE notify message, so that should be 
removed as well.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]> 
Sent by: [email-masked]
02/04/2010 05:54 AM
Please respond to
Adrian Farrel <[email-masked]>

To
"BUSI ITALO" <[email-masked]>, <[email-masked]>, 
"Cecil Byles" <[email-masked]>
cc
[email-masked]
Subject
Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in Linear 
Protection]

Hi,

What I think I see is:

Protection draft is expressing a solution and must engage in state 
machines, 
message flows, and bits&bytes. The Survivability Framework, on the other 
hand, is at a very high level; it does not go into the details of a state 
machine, but simply says that some form of state coordination will be 
needed 
through a protocol.

At this stage I propose to use the acronym "RSC" (Recovery State 
Coordination) to identify the protocol that will be used. IMHO this does 
not 
prohibit in any way the use of the APS abstract protocol, nor the 
realisation of an MPLS-TP APS. On the other hand, it also does not 
prejudge 
the value of using APS in this situation. It seems to me to be reasonable 
to 
phase our work, and this is one way of splitting the decisions points.

So (for the Survivability Framework only) I am seeking consensus that we 
use 
"RSC".

Thanks,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 

Adrian,

I think that this thread discussion is actually proving that the idea to 
re-define a new term for what everybody in the world known as APS was not 
a 
good idea.

We therefore better come back and adopt the widely known concept rather 
than 
inventing a new term and confuse the whole industry.

- APS is a generic term for the coordination protocol and does not imply 
any 
specific protocol implementation;

- OTN APS is a specific protocol specification of APS in OTN networks and 
it 
is defined in G.873.1

What IETF actually should define the specific realization of APS in 
MPLS-TP 
networks.

Italo

---

From: John E Drake <[email-masked]>
Date: Fri, 2 Apr 2010 12:07:29 -0700

Malcolm,

Wrt Notify, we do have direction to re-use existing MPLS and GMPLS technology.

Thanks,

John

Sent from my iPhone

On Apr 2, 2010, at 12:39 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

All,

I have concerns with using the phrase Recovery State Coordination and consequently the acronym RSC.  The term Recovery applies to both protection switching and restoration.  The use of RSC implies that they both need to use the same coordination protocol.  This is clearly not true, in general restoration implies the establishment or activation of a new path.  I therefore support the use of the acronym APS, since it is an abstract protocol that is clearly scoped to protection switching and avoids ambiguity that it may also be applied to restoration.  In terms of biasing the outcome of the discussion I would note that the framework has already suggested the use of the RSVP-TE notify message, so that should be removed as well.

Regards,

Malcolm

"Adrian Farrel" <[email-masked]<mailto:[email-masked]>>
Sent by: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>

02/04/2010 05:54 AM

Please respond to
Adrian Farrel <[email-masked]<mailto:[email-masked]>>

To
        "BUSI ITALO" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "Cecil Byles" <[email-masked]<mailto:[email-masked]>>
cc
        [email-masked]<mailto:[email-masked]>
Subject
        Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in        Linear Protection]

Hi,

What I think I see is:

Thanks,
Adrian

----- Original Message -----
From: "BUSI ITALO" <[email-masked]<mailto:[email-masked]>>
To: "Adrian Farrel" <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
"Cecil Byles" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 02, 2010 9:32 AM
Subject: RE: [CCAMP] [mpls-tp]
[mpls]Term"PSC"indraft-ietf-mpls-tp-linear-protection-01

Adrian,

Italo

P.S. Please note my new email address, [email-masked]<mailto:[email-masked]>,
effective since 1 November 2009.

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> To: [email-masked]<mailto:[email-masked]>; Cecil Byles
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
> From: "Huub van Helvoort" <[email-masked]<mailto:[email-masked]>>
> To: "Cecil Byles" <[email-masked]<mailto:[email-masked]>>
> Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>
> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/ccamp> https://www.ietf.org/mailman/listinfo/ccamp
>
> <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/ccamp> https://www.ietf.org/mailman/listinfo/ccamp
>

_______________________________________________
mpls-tp mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/mpls-tp>https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 5 Apr 2010 22:41:18 +0200

Hi Malcolm,

I am not happy to use the acronym APS because one can think that we refer to a specific mechanism used by the ITU-T...it is also the protocol name? isn't it? At least this is what I can recall from linear and ring protection....(APS and R-APS).

I would support any name that hints for the purpose and objective of the protocol.: to coordinate the recovery states between the edges of the recovery domain....and please note that this may be used also in mesh protection as well, etc................I think it is better to use the general recovery term.......

I am surprised to see your words "In terms of biasing the outcome of the discussion I would note that the framework has already suggested the use of the RSVP-TE notify message....."....this is misleading......

Since the protection switching should fully operate also in the absence of a control plan, and in order to achieve 50ms protection switching when a control plane exists but does not apply to the performance requirements, we recommend in the framework to use in-band data-plane driven signaling protocol......and we refer to the IETF draft in work in progress on linear protection. 

We also refer to the GMPLS procedures and messages' elements defined in (RFC 4426, RFC4872 and RFC4873) that are used coordinate the protection states between the edges of the protection domain.....and we also indicate which capabilities are still missing in these messages. Section 6.5 that discusses the aspects of the control plane (GMPLS which is the protocol of choice for MPLS-TP) and refers to existing message that is already defined in GMPLS that can be used for this purpose if the control plane is used for this sake......still it written.......: "however, specific message field values remain to be defined for this operation. A further piece of work in needed to allow .........". 

I find it very correct that a framework in the IETF refers to existing protocols in the IETF (or protocols that are still in work in progress) that can be used........ and indicates what is missing in these protocols and need to be extended...

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Friday, April 02, 2010 7:37 PM
To: Adrian Farrel
Cc: Cecil Byles; [email-masked]; BUSI ITALO
Subject: Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in Linear Protection]

All, 

Regards, 

Malcolm 

02/04/2010 05:54 AM 

Please respond to

To

"BUSI ITALO" <[email-masked]>, <[email-masked]>, "Cecil Byles" <[email-masked]> 

cc

[email-masked] 

Subject

		

Hi,

What I think I see is:

Thanks,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 

Adrian,

Italo

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 5 Apr 2010 13:59:52 -0700

Dear Nurit,
I thought that adding to the Rosetta Stone a description of APS as
principle, paradigm of predetermined, coordinated, and implementation
non-specific protection might set correct context within MPLS-TP documents.
If you disagree, may I suggest CAPS (my favorite because of CRAPS for
rings), or ACPS ("C" - for coordinated).

Regards,
Greg

On Mon, Apr 5, 2010 at 1:41 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

>  Hi Malcolm,
>
> I am not happy to use the acronym APS because one can think that we refer
> to a specific mechanism used by the ITU-T…it is also the protocol name?
> isn’t it? At least this is what I can recall from linear and ring
> protection….(APS and R-APS).
>
> I would support any name that hints for the purpose and objective of the
> protocol.: to *coordinate* the recovery states between the edges of the
> recovery domain….and please note that this may be used also in mesh
> protection as well, etc…..………..I think it is better to use the general
> recovery term…….
>
> *I am surprised* to see your words “In terms of biasing the outcome of the
> discussion I would note that the framework has already suggested the use of
> the RSVP-TE notify message…..”….*this is misleading*……
>
> Since the protection switching should fully operate also in the absence of
> a control plan, and in order to achieve 50ms protection switching when a
> control plane exists but does not apply to the performance requirements, we
> recommend in the framework to use *in-band data-plane driven signaling
> protocol*……*and we **refer to the IETF draft in work in progress on linear
> protection. *
>
> We also refer to the *GMPLS procedures and messages’ elements** *defined
> in (RFC 4426, RFC4872 and RFC4873) that are used coordinate the protection
> states between the edges of the protection domain…..and we also indicate
> which capabilities *are still missing in these messages*. Section 6.5 that
> *discusses the aspects of the control plane (GMPLS which is the protocol
> of choice for MPLS-TP)* and refers to existing message that is already
> defined in GMPLS that can be used for this purpose *if the control plane
> is used for this sake*……still it written…….: “however, specific message
> field values remain to be defined for this operation. A further piece of
> work in needed to allow ………”.
>
> *I find it **very correct** that a framework in the IETF refers to
> existing protocols in the IETF (or protocols that are still in work in
> progress) that can be used*…….. and indicates what is missing in these
> protocols and need to be extended...
>
> Best regards,
>
> Nurit
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *ext [email-masked]
> *Sent:* Friday, April 02, 2010 7:37 PM
> *To:* Adrian Farrel
> *Cc:* Cecil Byles; [email-masked]; BUSI ITALO
>
> *Subject:* Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in
> Linear Protection]
>
>
>
>
> All,
>
> consequently the acronym RSC.  The term Recovery applies to both protection
> switching and restoration.  The use of RSC implies that they both need to
> use the same coordination protocol.  This is clearly not true, in general
> restoration implies the establishment or activation of a new path.  I
> therefore support the use of the acronym APS, since it is an abstract
> protocol that is clearly scoped to protection switching and avoids ambiguity
> that it may also be applied to restoration.  In terms of biasing the outcome
> of the discussion I would note that the framework has already suggested the
> use of the RSVP-TE notify message, so that should be removed as well.
>
> Regards,
>
> Malcolm
>
>
>   *"Adrian Farrel" <[email-masked]>*

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 5 Apr 2010 14:37:59 -0700

Once again I've went over the limit and had to cut part of discussion.
Resending ...

On Mon, Apr 5, 2010 at 2:32 PM, Greg Mirsky <[email-masked]> wrote:

> Dear Nurit,
> it could be that I've jumped the gun - my apologies.
> I'm thinking of coordinated automatic protection switching without tying it
> to a particular topology. The topology, linear or ring, allows us certain
> optimization of generic principle, method. And I think that the discussion
> stepped up from the linear topology to survivability, protection in MPLS-TP
> in general. If in any MPLS-TP topology coordination between the end-points
> is required, then, I think, that is that common that we can capture in the
> terminology we use when describing protection switching in MPLS-TP. I agree
> that APS might imply SONET/SDH APS, but it is the latter that carries ITU-T
> logo, not the former (my understanding of the history of these).
> It could be M-APS - not most important to me. More important, and I think
> that is what you're advocating, agree on sufficiently descriptive and clear
> terminology. Hope I didn't miss it this time.
>
> Regards,
> Greg
>
>
> On Mon, Apr 5, 2010 at 2:10 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
>>  Hi Greg,
>> I think you misunderstood me…….Did you miss the “*and we **refer to the
>> IETF draft in work in progress on linear protection.”*
>>
>> *In the framework we refer to the linear protection document* in which
>> the protocol elements and procedures are being defined………
>>
>> Whether the Linear protection document refers and uses the ITU-T APS
>> mechanism or utilizes the GMPLS messages’ elements or defines and use a new
>> protocol is open for a discussion…….and any feedback is much appreciated…..
>>
>> I do not think the purpose of the Rosetta Stone document is to describe
>> the ITU-T mechanisms but to “translate” between ITU-T and IETF acronyms and
>> definitions……..
>>
>> Best regards,
>>
>> Nurit
>>
>>
>>
>>
>>
>> *From:* ext Greg Mirsky [mailto:[email-masked]]
>> *Sent:* Tuesday, April 06, 2010 12:00 AM
>> *To:* Sprecher, Nurit (NSN - IL/Hod HaSharon)
>> *Cc:* [email-masked]; Adrian Farrel; Cecil Byles; BUSI ITALO;
>> [email-masked]
>>
>> *Subject:* Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was:
>> in Linear Protection]
>>
>>
>>
>> Dear Nurit,
>> *I am surprised* to see your words “In terms of biasing the outcome of
>> the discussion I would note that the framework has already suggested the use
>> of the RSVP-TE notify message…..”….*this is misleading*……
>>
>> protocol*……*and we **refer to the IETF draft in work in progress on
>> linear protection. *
>>
>> which capabilities *are still missing in these messages*. Section 6.5
>> that *discusses the aspects of the control plane (GMPLS which is the
>> protocol of choice for MPLS-TP)* and refers to existing message that is
>> already defined in GMPLS that can be used for this purpose *if the
>> control plane is used for this sake*……still it written…….: “however,
>> specific message field values remain to be defined for this operation. A
>> further piece of work in needed to allow ………”.
>>
>> *Subject:* Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was:
>> in Linear Protection]
>>
>>
>>
>>
>> All,
>>

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 5 Apr 2010 15:08:05 -0700

Hi Stewart,

The MPLS-TP frame work draft (draft-ietf-mpls-tp-framework-11) says that:

   A label may be used to identify the network layer protocol payload
   type.  Therefore, when multiple protocol payload types are to be
   carried over a single service LSP, a unique label stack entry MUST be
   present for each payload type.  Such labels are referred to as
   "Encapsulation Labels", one of which is shown in Figure 9.
   Encapsulation Label may be either configured or signaled.

Does this statement need to be changed (from Must to May) in scope of the "virtual Ethernet" concept introduced in "draft-bryant-pwe3-packet-pw-03"?

Thanks,
Shahram

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 06 Apr 2010 00:29:54 -0400

In message <[email-masked]>
[email-masked] writes:
> protection switching and restoration.  The use of RSC implies that
> they both need to use the same coordination protocol.  This is clearly
> not true, in general restoration implies the establishment or
> activation of a new path.  I therefore support the use of the acronym
> APS, since it is an abstract protocol that is clearly scoped to
> protection switching and avoids ambiguity that it may also be applied
> to restoration.  In terms of biasing the outcome of the discussion I
> would note that the framework has already suggested the use of the
> RSVP-TE notify message, so that should be removed as well.
>  
> Regards,
>  
> Malcolm

Malcolm,

All shared mesh protection is restoration by your definition and
therefore out of scope.  I don't think that restriction is the intent
of the framework draft and therefore RSC should be fine.

I was OK with MPLS-TP APS but since some people have confirmed that
they feel it *should* constrain the solution to be exactly identical
to existing APS, then I agree with Adrian that RSC is a better choice.

Curtis

snipped reply.  It was highly mangled already by mix of text, rtf, and
html mailers.  See
<[email-masked]>
if you need context.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 5 Apr 2010 23:10:37 +0200

Hi Greg,

I think you misunderstood me.......Did you miss the "and we refer to the IETF draft in work in progress on linear protection."

In the framework we refer to the linear protection document in which the protocol elements and procedures are being defined.........

Whether the Linear protection document refers and uses the ITU-T APS mechanism or utilizes the GMPLS messages' elements or defines and use a new protocol is open for a discussion.......and any feedback is much appreciated.....

I do not think the purpose of the Rosetta Stone document is to describe the ITU-T mechanisms but to "translate" between ITU-T and IETF acronyms and definitions........

Best regards,

Nurit

From: ext Greg Mirsky [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2010 12:00 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Adrian Farrel; Cecil Byles; BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in Linear Protection]

Dear Nurit,
I thought that adding to the Rosetta Stone a description of APS as principle, paradigm of predetermined, coordinated, and implementation non-specific protection might set correct context within MPLS-TP documents. If you disagree, may I suggest CAPS (my favorite because of CRAPS for rings), or ACPS ("C" - for coordinated).

Regards,
Greg

On Mon, Apr 5, 2010 at 1:41 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <[email-masked]> wrote:

Hi Malcolm,

Best regards,

Nurit

All, 

Regards, 

Malcolm 

02/04/2010 05:54 AM 

Please respond to

To

cc

[email-masked] 

Subject

		

Hi,

What I think I see is:

Thanks,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 

Adrian,

Italo

---

From: [email-masked]
Date: Tue, 6 Apr 2010 13:09:10 -0400

Nurit,

See in line below:

Regards,

Malcolm

snip>---------------------------

> I would support any name that hints for the purpose and objective of
> the protocol.: to coordinate the recovery states between the edges 
> of the recovery domain?.and please note that this may be used also 
> in mesh protection as well, etc?..???..I think it is better to use 
> the general recovery term??.

[MB] from Section 1.1 of the draft:
"   Various recovery schemes (for protection and restoration) "

As I stated my concern is that the term recovery applies to both 
protection and restoration - a new coordination protocol is only required 
for protection.

> I am surprised to see your words ?In terms of biasing the outcome of
> the discussion I would note that the framework has already suggested
> the use of the RSVP-TE notify message?..??.this is misleading??
> Since the protection switching should fully operate also in the 
> absence of a control plan, and in order to achieve 50ms protection 
> switching when a control plane exists but does not apply to the 
> performance requirements, we recommend in the framework to use in-
> band data-plane driven signaling protocol??and we refer to the IETF 
> draft in work in progress on linear protection. 
> We also refer to the GMPLS procedures and messages? elements defined
> in (RFC 4426, RFC4872 and RFC4873) that are used coordinate the 
> protection states between the edges of the protection domain?
[MB] A much better place to look is the ITU work on data plane protection 
and referencing just the IETF work implies that other work should be 
ignored and as such will bias any reader.

snip>--------------------