Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Oct 2009 11:55:57 +0000

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SD-Triggered Protection Switching in MPLS-TP
> 	Author(s)       : Z. Haiyan, et al.
> 	Filename        : draft-zhl-mpls-tp-sd-01.txt
> 	Pages           : 9
> 	Date            : 2009-10-26
>
>   

I am not quite sure what is being proposed in this document.

I had always assumed that  L/D thresholds would trigger
standard protection switching with a new pair of reason
codes. Is that what the authors are proposing?

- Extra traffic

I thought that there was a project decision not to formally  support
extra traffic, since all that is needed is an LSP with suitable priority
and it comes for free.

- Stewart

---

From: Zhang Haiyan <[email-masked]>
Date: Wed, 28 Oct 2009 16:42:43 +0800

Stewart,

Thanks for your concerns.

Please see inline... 

B.R.
Haiyan

----- Original Message ----- 
From: "Stewart Bryant" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 26, 2009 7:55 PM
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

> codes. Is that what the authors are proposing?

[HY] Yes, LM and DM thresholds are used to generate SD condition, and SD can trigger standard protection switching. LM need to measure the amount of the lost service packets, so the detection of SD must be based on service packets.

But in 1:1 and 1:n protection architecture, there is no normal traffic on 
1) working transport entity when protection switching is active, or
2) protection transport entity when protection switching is not active,
which makes the detection of SD based on service packets impossible and causes switch flapping. 

This document describes the solutions in two ways, one is to implement LM by non-normal traffic, and the other is to optimize the protection switching behavior, in 1:1 and 1:n protection architecture. Besides, two requests SD-W and SD-P are defined in this document to assist protection switching.

> extra traffic, since all that is needed is an LSP with suitable priority

[HY] We considered extra traffic as one solution in this document, only because extra traffic is mentioned in MPLS-TP survivability framework. If there was a decision not to support extra traffic in MPLS-TP, we will follow it and delete extra traffic in next version.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2009 11:03:48 -0000

Hi Haiyan,

Two things.

1. Yes, you make a good point that in 1:n protection it is not possible to 
know whether the protecting path is functional in advance of the proteciton 
switch without running some form of OAM on it ahead of time. Not doing this 
risks a flap if and only if the reason for switchover is signal degradation 
(rather than complete failure).

2. The Survivability Framework tries to reflect the requirements in RFC 
5654. Thus, in Section 3.1 we have...
   Note that there is no requirement for support for extra traffic
   [RFC4427] except in a ring where MPLS-TP must support the sharing of
   protection bandwidth in a ring by allowing best-effort traffic (108).

Additionally, we have Section 4.3.3. This describes extra traffic, but 
continues to note that it is not required in MPLS-TP.

I would say that, in the presence of extra traffic it *is* possible to use 
the traffic as a sign that the protection LSP is functional, but this is not 
something that can be relied upon because:
a. There is no gaurantee that every proteciton LSP will carry extra traffic 
(especially since we are told that, in general, no-one in MPLS-TP wants 
extra traffic)
b. Where extra traffic exists, it might go silent for long periods such that 
the receiver cannot tell the state of the LSP.

Thus, OAM is the only way to reliably know the health of a proteciton LSP.

Cheers,
Adrian

----- Original Message ----- 
From: "Zhang Haiyan" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 8:42 AM
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

> [HY] Yes, LM and DM thresholds are used to generate SD condition, and SD 
> can trigger standard protection switching. LM need to measure the amount 
> of the lost service packets, so the detection of SD must be based on 
> service packets.
>
> This document describes the solutions in two ways, one is to implement LM 
> by non-normal traffic, and the other is to optimize the protection 
> switching behavior, in 1:1 and 1:n protection architecture. Besides, two 
> requests SD-W and SD-P are defined in this document to assist protection 
> switching.
>
>> - Extra traffic
>>
> [HY] We considered extra traffic as one solution in this document, only 
> because extra traffic is mentioned in MPLS-TP survivability framework. If 
> there was a decision not to support extra traffic in MPLS-TP, we will 
> follow it and delete extra traffic in next version.
>
>
>> - Stewart
>>
>>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 13:16:18 +0100

G.808.1 amendment 1 addresses this SD issue, and describes a solution.
http://www.itu.int/rec/T-REC-G.808.1-200901-I!Amd1/en

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: woensdag 28 oktober 2009 12:04
To: Zhang Haiyan; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

Hi Haiyan,

Two things.

I would say that, in the presence of extra traffic it *is* possible to use
the traffic as a sign that the protection LSP is functional, but this is not
something that can be relied upon because:
a. There is no gaurantee that every proteciton LSP will carry extra traffic
(especially since we are told that, in general, no-one in MPLS-TP wants
extra traffic) b. Where extra traffic exists, it might go silent for long
periods such that the receiver cannot tell the state of the LSP.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2009 12:34:18 -0000

Yes, this document advocates using a copy of all client traffic "bridged" 
onto the protection path in order to allow the egress to evaluate the 
protection path state using the identical mechanisms that are used for the 
working path.

I would like to understand how this mechanism for 1:1 differs from 1+1. (Not 
that I have ever seen much value in 1:1 in the absence of extra traffic!)

On the other hand, in the case of 1:n, this document is completely unclear 
about which traffic should be bridged onto the protection path (clearly it 
cannot carry all of the traffic from all of the working paths it protects). 
Yet, to provide the correct like-for-like comparison with a working path, it 
would need to carry the identical traffic.

It also does not indicate how to handle the case where the client traffic is 
quiet (this being a packet network, not an optical network, there is no 
carrier signal that is constantly present).

So, yes, the reference you give us indicates that this problem has been 
thought about before. But, for MPLS-TP some further thought is required.

Using an OAM pattern on the protection path may be a way to handle this in 
MPLS-TP. I would be interested to understand how many packets per second are 
necessary to judge the quality of the protection path, and what the 
consequences are for processing in the network and for power consumption.

Thanks,
Adrian
----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; "'Zhang Haiyan'" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 12:16 PM
Subject: RE: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Oct 2009 14:57:40 +0200

Adrian,
Lots of thanks for clarification!!! 
IMO you've given an excellent example how "copy and paste" of a solution used in  traditional, 
TDM-based transport networks (and sanctified by the appropriate standardization bodies) 
becomes meaningless in the new packet-based context.

My 2c,
     Sasha  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, October 28, 2009 2:34 PM
> To: Maarten Vissers; 'Zhang Haiyan'; [email-masked]
> Cc: [email-masked]
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Adrian Farrel
> > switch without running some form of OAM on it ahead of 
> time. Not doing 
> > this
> > the traffic as a sign that the protection LSP is 
> functional, but this is 
> > not
> >>>> A New Internet-Draft is available from the on-line 
> Internet-Drafts
> >>>> directories.
> >>>>
> >> which makes the detection of SD based on service packets 
> impossible and
> >> causes switch flapping.
> >>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 14:09:39 +0100

Adrian,

The value of 1:1 protection in circuit transport networks is not high; it
would only make sense to use it when there is another low priority
connection with pre-emptable traffic ... Such is in most cases not present
between the end points of the 1:1 protected connection.

The value of 1:1 protection in packet transport networks lies in the fact
that during 95% to 99% of the time the protection connection is not being
used to carry traffic. As a result the bandwidth reserved on the link(s) for
this protection connection can be used for unprotected connections carrying
best effort (EIR) traffic, or for unprotected connections carrying a mix of
guaranteed (CIR) and best effort (EIR) traffic. As long as the reserved
protection connection bandwidth is not used, this bandwidth is available for
the EIR traffic of other connections. And because these other connections do
not have to follow exactly the same set of links as the protected
connection, it is much more likely that the reserved protection connection
bandwidth will be used by one or more of such other connections.

> Yet, to provide the correct like-for-like comparison with a working path,
> it would need to carry the identical traffic.

This is what G.808.1 am1 specifies in the following sentences: "When SD is
detected on the working transport entity, the sink end sends SD-W indication
to the source end and the selector at the sink end switches to the
protection transport entity. The bridge at the source end will then
broadcast the normal traffic signal on both working and protection transport
entities and the performance of both working and protection transport
entities can be monitored."

I.e. the "normal traffic signal" (which is the protected traffic) is
normally send over Working, but after an SD condition has been detected on
Working, the "normal traffic signal" will be send over both Working and
Protection.

The text in G.808.1 am1 then continues with "If SD is detected on the
protection transport entity as well, i.e., SD-W and SD-P exist
simultaneously, the sink end will continue selecting normal traffic signals
from the protection transport entity, to avoid flapping between protection
and working states.
The priority of SD-W and SD-P in the APS protocol is fixed as SD-W > SD-P,
to avoid flapping between protection and working states." 

By giving SD-W a higher priority then SD-P the selector will not start to
flap.

Note that for the case of SF condition the opposite priority is present;
i.e. SF-P is a higher priority then SF-W. Rationale is that the APS channel
is carried over the Protection connection and a signal fail condition on
Protection interrupts the APS channel. Both ends now fall back to the
default (Working) position.

I hope this clarifies the protection switching behaviour that we have
specified for SD conditions in packet transport networks.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 13:34
To: Maarten Vissers; 'Zhang Haiyan'; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2009 13:32:00 -0000

Hi Maarten,

You say...

> specified for SD conditions in packet transport networks.

I think your use of "we" may be ambiguous :-)

Anyway, thanks for your apple pie, but you didn't really answer the bulk of 
my questions.

1. How is the idea in 808.1 A1 different from 1+1? It appears that it relies 
on continuous bridging at the source and selection at the sink.  Isn't that 
exactly 1+1?

2. How does the idea in 808.1 A1 work for n:m with n>0 and m>1? Which signal 
will be bridged at the source?

3. How is SD judged in the case where there is little or no packet traffic?

Your observations about the value of mesh networks and shared protection 
resources are well made. Of course they can be achieved in all networks, but 
they are considerably easier to operate in a packet network where resources 
are not synonymous to labels. However, we should observe (again) that the 
use of extra traffic is explicitly made a non-requirement for MPLS-TP in 
RFC5654 (doesn't mean we must not support it, only that it is not an 
expected feature of an MPLS-TP network).

So, and finally...

4. How does the mechanism of G.808.1 A1 work in mesh protection? In this 
case, the resources in the core of the network are in use for preemptable 
extra traffic, but this traffic is not running end-to-end between the same 
ingress and egress as is specified for the 1:1 protection pair. So, if 
traffic is bridged onto the protection path, there will be a conflict for 
resources in the core of the network.

Thanks,
Adrian

----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 1:09 PM
Subject: RE: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

> it

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 15:24:43 +0100

Hi Adrian,

See inline... 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 14:32
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

Hi Maarten,

You say...

[mv] "we" = Q.9/15 :-)

[mv] in 1+1 you have a "permanent bridge" (refer to 3.2.11.1/G.870) which
continuously transmits the normal traffic signal on both Working and
Protection connections. In 1:1 you only transmit the normal traffic signal
on both Working and Protection connections during the detection of a SF-W or
SD-W defect. I.e. you will use then what is called a "broadcast bridge"
(refer to 3.2.11.2/G.870). http://www.itu.int/rec/T-REC-G.870/en

[mv] The signal being bridged is the "normal traffic signal", which is the
signal that is protected.

[mv] SD = aTSD = dDEG (degraded defect). dDEG for ETH is specified in clause
6.1.3/G.8021 http://www.itu.int/rec/T-REC-G.8021/en. 

------6.1.3/G.8021-------
Figure 6-3/G.8021/Y.1341 - dDEG detection and clearance process
The Degraded Signal defect is calculated at the ETH layer. It monitors the
connectivity of an ETH Trail. 
Its detection and clearance are defined in Figure 6-3. 
Every second the statemachine receives the 1 second counters for far end
received and transmitted frames and determines whether the second was a Bad
Second. The defect is detected if there are MI_LM_DEGM consecutive Bad
Seconds and cleared if there are MI_LM_M consecutive Good Seconds. 
In order to declare a Bad Second the number of transmitted frames must
exceed a threshold (TF_MIN). If this is true then a Bad Second is declared
if either the Frame Loss is negative (i.e. there are more frames received
than transmitted) or the Frame Loss Ratio (lost frames/transmitted frames)
is greater than MI_LM_DEGTHR. 
-------------------------

[mv] In Ethernet (G.8031) and T-MPLS (G.8131) protection switching
specifications there is no support for "extra traffic". As such ITU-T and
IETF are aligned on this item.

So, and finally...

[mv] What do you mean with "mesh protection"? Is it linear protection in a
network which contains in the core (and possibly in one or more metro
domains) a full mesh of links between e.g. PE nodes? If it is this latter,
then there is no mesh protection, just linear protection. The pre-emptable
additional traffic (I on purpose do not use the reserved term "extra
traffic" here) that is on the PE-to-PE links (supported by an LSP) in the
core is traffic that belongs to other service layer connections and it is
drop eligible (EIR). When the linear protection switching switches the
normal traffic signal onto Protection, then there is suddenly more CIR
traffic (i.e. from the normal traffic signal), and this CIR traffic which
has a high priority and is non-drop eligible will thus push away the
additional EIR traffic when there is not enough resource available on the
core domain link or links. I.e. due to different priorities and different
drop eligibilities it is easy to determine which packets/frames will
continue and which will be dropped.

Regards,
Maarten

Thanks,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 28 Oct 2009 17:26:34 +0100

I agree! 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Alexander Vainshtein
Sent: Wednesday, October 28, 2009 2:58 PM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

Adrian,
Lots of thanks for clarification!!! 
IMO you've given an excellent example how "copy and paste" of a solution
used in  traditional, 
TDM-based transport networks (and sanctified by the appropriate
standardization bodies) 
becomes meaningless in the new packet-based context.

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 18:09:04 +0100

Sasha, Nurit,

Please read my response to Adrian's email as it contains further details and
clarifies his questions that represent some misunderstandings. You seem as
such to have the same misunderstanding of the specifications in G.808.1 and
the associated packet transport network protection swithcing
recommendations. 

FYI, ITU-T SG15 has a long history with respect to protection switching.
PDH, SDH, ATM, OTN, Ethernet and T-MPLS protection switching has been
defined. ATM, Ethernet and T-MPLS are packet based protection switching
mechanisms. ATM and Ethernet protection switching is in the field for some
years now. Please take this into consideration when you voice your opinion
about the protection work done in SG15. These specification are very
meaningfull.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: woensdag 28 oktober 2009 17:27
To: ext Alexander Vainshtein; Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

I agree! 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Alexander Vainshtein
Sent: Wednesday, October 28, 2009 2:58 PM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

Adrian,
Lots of thanks for clarification!!! 
IMO you've given an excellent example how "copy and paste" of a solution
used in  traditional, TDM-based transport networks (and sanctified by the
appropriate standardization bodies) becomes meaningless in the new
packet-based context.

My 2c,
     Sasha  

> protection path state using the identical mechanisms that are used for 
> the working path.
> 
> I would like to understand how this mechanism for 1:1 differs from 
> 1+1. (Not that I have ever seen much value in 1:1 in the absence of 
> extra traffic!)
> 
> On the other hand, in the case of 1:n, this document is completely 
> unclear about which traffic should be bridged onto the protection path 
> (clearly it cannot carry all of the traffic from all of the working 
> paths it protects).
> Yet, to provide the correct like-for-like comparison with a working 
> path, it would need to carry the identical traffic.
> 
> It also does not indicate how to handle the case where the client 
> traffic is quiet (this being a packet network, not an optical network, 
> there is no carrier signal that is constantly present).
> 
> So, yes, the reference you give us indicates that this problem has 
> been thought about before. But, for MPLS-TP some further thought is 
> required.
> 
> Using an OAM pattern on the protection path may be a way to handle 
> this in MPLS-TP. I would be interested to understand how many packets 
> per second are necessary to judge the quality of the protection path, 
> and what the consequences are for processing in the network and for 
> power consumption.
> 
> Thanks,
> Adrian
> > know whether the protecting path is functional in advance of the 
> > proteciton switch without running some form of OAM on it ahead of
> time. Not doing
> > this
> > risks a flap if and only if the reason for switchover is signal 
> > degradation (rather than complete failure).
> >
> > a. There is no gaurantee that every proteciton LSP will carry extra 
> > traffic (especially since we are told that, in general, no-one in
> MPLS-TP wants
> >>> I had always assumed that  L/D thresholds would trigger standard 
> >>> protection switching with a new pair of reason codes. Is that what 
> >>> the authors are proposing?
> >>>
> >>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2009 17:25:13 -0000

Hi Maarten,

I don't think anyone means to disparage the work of SG15, but we do want to 
find out how/if this applicable to MPLS-TP.

You have answered some of these questions helpfully and this will enable us 
to go some way towards forming an opinion.

I have inferred something from your answers that had escaped me before. It 
is not clear from the text of G.808.1 A1 although it may be clear elsewhere. 
Can you confirm for me that I am reading it correctly.

Let's take 1:2 protection as out example.

LSPs A and B are protected by LSP C.
For the normal case, LSP C carries no traffic.
The egress node monitors the traffic and OAM on A and B to check on 
continuity and "signal."

In the event of a failure (fault or degradation) of LSP B (but not LSP A), 
the egress uses fault notifications (OAM or whatever) to request recovery 
action.

The ingress now (and not before) bridges traffic for B onto C.

The egress is now able to compare the signals arriving on B and C. It can 
select the better signal and can give directions to the ingress about how to 
behave. It could cut back to just B. Cut forward to just C. Or keep B and C 
for a while to avoid flaps.

Is this right so far?

If so, this is cool and fine, but it is "fault invoked 1+1 protection based 
on a 1:n resource pool"

In particular, it requires that the ingress can bridge, and that the egress 
can sample and compare two flows while discarding one of them. In 
otherwords, both the ingress and the egress nodes must have 1+1 hardware 
capabilities.

Have we converged in our understanding (even if not in our opinion of what 
is a good deployment solution)?

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Oct 2009 21:21:06 +0100

Hi Adrian,

See inline.. 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 18:25
To: Maarten Vissers; 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext
Alexander Vainshtein'
Cc: [email-masked]

Hi Maarten,

[mv] Thanks.

[mv] Let me add some additional elements:
- LSP A carrier Signal (a), LSP B carriers Signal (b).
- A maintenance entity group is activated within LSP A to monitor LSP A
Working segment. For this purpose LSP MEP functions are activated at the two
end points of the Working segment. 
- A maintenance entity group is activated within LSP B to monitor LSP B
Working segment. For this purpose LSP MEP functions are activated at the two
end points of the Working segment. 
- A maintenance entity group is activated within LSP C to monitor LSP C
Protection segment. For this purpose LSP MEP functions are activated at the
two end points of the Working segment. 
- the LSP MEP sink functions at the endpoints of LSP A, B and C
Working/Protection segments check those segments for continuity,
connectivity and signal degradation continuously. Continuity and
connectivity defects must be detected within 10 ms after the fault occurs.
Signal degradation defects must be detected within 7 seconds, to prevent
that unavailable time is entered. Refer to G.7710. 

[mv] The LSP MEP at the end of the LSP B Working segment detects a SF or SD
condition and reports this to the 1:2 LSP SNC/S protection switching
process. The LSP SNC/S protection switching process checks if the SF or SD
condition reported by LSP B MEP has the highest priority (e.g. no external
commands active, no SF on Protection); if so, then the LSP SNC/S protection
swithcing process will communicate this SF or SD condition of LSP B to the
other end via an APS communication channel (e.g. APS OAM messages).

[mv] Ingress will bridge Signal (b) to both LSP B Working segment and LSP C
Protection segment. It will keep doing this as long as there is no change in
external commands and/or status of LSP Working/Protection segments. I.e.
there is a "broadcast bridge" at the ingress.

Is this right so far?

[mv] Not completely. Egress will read Signal (b) from LSP C. It will keep
doing so as long as there is no change in external commands and/or status of
LSP Working/Protection segments.

[mv] What we have not addressed is the APS protocol type; i.e. 1-phase,
2-phase or 3-phase (refer to clause 24/G.808.1). The choice of APS protocol
type determines how many APS message exchanges are necessary.  1-phase APS
protocol is preferred in packet transport networks, and is used in ETH SNC
protection (refer to G.8031).

[mv] Choosing a 1-phase protocol implies that the 1:n (e.g. 1:2)
architecture must be replaced by a (1:1)**n (e.g. (1:1)**2) architecture
specified in clause 7.4/G.808.1. This would imply for the example, that
there will be the following LSPs:
- LSP A Working segment (carries Signal (a))
- LSP B Working segment (carries Signal (b))
- LSP C Protection segment (carries Signal (a))
- LSP D Protection segment (carries Signal (b)).
LSP C and LSP D Protection segments are carried by the same links.
LSP A and LSP B Working segments are carried by two different links.

[mv] This is an incorrect understanding of 1+1 protection... 1+1 protection
is defined with a permanent bridge, which implies that Signal (x) is carried
continuously over LSP X Working and LSP Y Protection.

[mv] for 1:n and (1:1)**n protection switching there are two bridge types:
1) broadcast bridge
2) selector bridge (refer to 3.2.11.3/G.870).
The "selector bridge" sends its Signal (x) to either Working, or Protection
(but not to both).
The "broadcast bridge" sends its Signal (x) to Working, or to Working and
Protection.

[mv] If the SD condition would not be a required protection switching
condition in a packet transport network, then one would prefer to use the
"selector bridge". If the SD condition is a required protection switching
condition in a packet transport network, then you have to use the "broadcast
bridge" for SNC protection. But when you would use CL-SNCG/I (compound link
sub-network connection group protection with inherent monitoring), then you
can again use the "selector bridge". In this CL-SNCG/I proteciton method a
group of Signals (x1,x2,x3,x4,x5,...) is protected by monitoring its server
layer trails. Half of the Signals (bandwidht wise) are transported via Link
#0, the other half via Link #1. Or for the case of 3 links, 1/3th via Link
#0, 1/3th via Link #1 and 1/3th via Link #2. All server layer trails now
carry traffic and are able to determine prior to a switching action if there
is a SD condition.

[mv] Slightly different... In the 1:2 example you have three NNI ports, each
NNI port containing one LSP. Each NNI port contains one LSP MEP. All 3 LSP
MEP Source functions generate CC, CV and LM information. All 3 LSP MEP Sink
functions detect for LOC, MMG and DEG defects (plus some other ones). All 3
LSP MEP Sink functions send their SF/SD status to the SNC protection process
in the LSP connection function (i.e. switch fabric). The LSP C Protection
MEP Sink function also forwards the APS channel messages to the SNC
protection process in the connection function. The LSP C Protection MEP
Source function forwards the APS channel messages recevied from the SNC
protection process.
The SNC protection process in the LSP connection function will control the
forwarding of Signal (a) and Signal (b). Signal (b) is forwarded to either
LSP B, or to LSP B + LSP C in one direction. In the other direction Signal
(b) can be read from either LSP B, or LSP C (case of "selective selector"). 

[mv] for the case of (1:1)**2 architecture Alternatively, Signal (b) can be
read from both LSP B + LSP D (case of "merging selector") (and Signal (a)
can be read from both LSP A + LSP C). In this case the LSP MEP Sink
functions must block the traffic when the LSP is the "standby" LSP (refer to
3.2.107/G.870).

[mv] Use of a "braodcast selector" requires that the connection fucntion
(i.e. switch fabric) is capable to multicast traffic to two LSPs during a
protection switch condition.

[mv] Let me know if you have further questions that I should clarify.

Regards,
Maarten

Cheers,
Adrian

---

From: Zhang Haiyan <[email-masked]>
Date: Thu, 29 Oct 2009 20:06:58 +0800

Hi Adrain,

Please see inline...

B.R.
Haiyan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Zhang Haiyan" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 7:03 PM
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

> continues to note that it is not required in MPLS-TP.

[HY] I only find the note in new version (upload on Oct 25, 2009) of Survivability Framework after I submitted the draft. And I will delete the extra traffic in next version.

> Thus, OAM is the only way to reliably know the health of a proteciton LSP.

[HY] The document does describe one solution based on OAM mechanism (LM by CC/CV or Test).

---

From: Zhang Haiyan <[email-masked]>
Date: Thu, 29 Oct 2009 20:11:00 +0800

Adrian,

You said,

> would need to carry the identical traffic.

[HY] For 1:n, n working entities are protected by one protection transport entity. When SF or SD is detected only on one working transport entity, the process is the same as 1:1. When SF or SD is detected on several working transport entities, we switch the traffic on the working entity that has the highest priority to protection transport entity.

Regarding the problem to be solved in this draft the solution is the same for 1:1 and 1:n.

B.R.
Haiyan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>; "'Zhang Haiyan'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 28, 2009 8:34 PM
Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt

>> proteciton
>> traffic

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Oct 2009 12:40:37 -0000

Hi,

>> unclear
> [HY] For 1:n, n working entities are protected by one protection transport
> entity. When SF or SD is detected only on one working transport entity,
> the process is the same as 1:1. When SF or SD is detected on several
> working transport entities, we switch the traffic on the working entity 
> that
> has the highest priority to protection transport entity.

Yes.
The issue I had was that I was not clear that bridging does not happen until 
the failure/degradation has been detected on one of the working paths.
In that respect, as I said to maarten, this scheme is like on-demand 1+1 
protection.

Cheers,
Adrian

---

From: Zhang Haiyan <[email-masked]>
Date: Fri, 30 Oct 2009 16:05:53 +0800

Adrian,

> In that respect, as I said to maarten, this scheme is like on-demand 1+1 

We use Permanent bridge at source end in 1+1; Broadcast bridge or Selector bridge in 1:1 and 1:n.

For 1:1 with Broadcast bridge, when protection switching is active, normal traffic is sent to protection transport entity by closing the switch on Broadcast bridge. But this doesn't mean initiating 1+1 proteciton (as a type of protection switching) IMHO though after protection switching traffic is sent on both working and protection entities.

Bridge types is shown in the following pictures. Hope it helps.

Permanent bridge:

       +----------+
       |          | W   
--->---|-----+----|---->---
       |     |    | 
       |     +----|---->---
       |          | P
       +----------+

Broadcast bridge:                    Selector bridge:

       +----------+                        +----------+
       |          | W                      |      /   | W  
--->---|-----+----|---->---                |     /----|---->---
       |    /     |                 --->---|----+     |
       |   /  ----|---->---                |      ----|---->---
       |          | P                      |          | P
       +----------+                        +----------+

In case of "broadcast bridge", 1:n Protection is described as follows (only unidirection). 

Normal State:
       +---------------------------------------------+
       |                                             |
--->---|--+------------------->----------------\     |
       |  |  /             Working 1            +----|--->---
       |  +-+  --+                          +--      |
       |         |                          |        |
       +---------|--------------------------|--------+
                 |                          |
       +---------|--------------------------|--------+
       |         |                          |        |
--->---|--+------|------------>-------------|--\     |
       |  |  /   |         Working 2        |   +----|--->---
       |  +-+  --+                          +--      |
       |         |                          |        |
       +---------|--------------------------|--------+
                 .                          .
                 .                          .
                 .                          .
       +---------|--------------------------|--------+
       |         |                          |        |
       |         +------------>-------------+        |
       |                   Protection                |
       +---------------------------------------------+                   

After protection switching:
       +---------------------------------------------+
       |                                             |
--->---|--+-------------------X----------------      |
       |  |                Working 1            +----|--->---
       |  +-+----+                          +--/     |
       |         |                          |        |
       +---------|--------------------------|--------+
                 |                          |
       +---------|--------------------------|--------+
       |         |                          |        |
--->---|--+------|------------>-------------|--\     |
       |  |  /   |         Working 2        |   +----|--->---
       |  +-+  --+                          +--      |
       |         |                          |        |
       +---------|--------------------------|--------+
                 .                          .
                 .                          .
                 .                          .
       +---------|--------------------------|--------+
       |         |                          |        |
       |         +------------>-------------+        |
       |                   Protection                |
       +---------------------------------------------+

Hope this can clarify our solution better.

B.R.
Haiyan

> To: "Zhang Haiyan" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, October 29, 2009 8:40 PM