Subject: Re: [PWE3] WG Adoption: draft-muley-pwe3-redundancy-00.txt]

From: Luca Martini <[email-masked]>
Date: Thu, 12 Oct 2006 16:22:30 -0600

Danny,

After carefully reading this draft , I fail to see what problem this
document has solved.
In section 3.1 the document describes the case of a multi-homed CE with
single SS-PW redundancy. This topology , does not need any protocol
extensions. In fact this problem has already been successfully resolved
in implementations without any protocol extensions. I believe that the
authors missed the point that a PW can only forward traffic when both
directions of the PW are in a forwarding state. If only one direction is
forwarding , then no traffic can flow in either direction.
Section 3.2 describes the case of multiple multi-homed CEs with single
SS-PW redundancy. What is the purpose of this topology ? The PSN cannot
fail as long as there is enough diversity ( as is shown in figure  2 ).
Why can't the PE just select another PSN tunnel if the  original tunnel
fails ? Since PSN tunnels are uni-directional the PW would not even
notice the event. Again this has already been implemented. I fail to see
the advantage of this protocol extension.

In section 4 , the document treats of a more interesting problem: MS-PW
redundancy applications. Here the topology in a limited subset of the
possible topologies. One cannot assume that there is only a single S-PE
between two T-PE. In fact in most applications the minimum is two S-PEs.
This is a difficult problem to solve. Unfortunately this document
leaves  it for "further study".

I would like to suggest that we concentrate our effort in resolving the
more general problem for MS-PW, which will most likely involve the use
of a PCE, and some kind of ERO.

I believe that the document still needs quite a bit of work
concentrating in section 4 on MS-PWs.

Luca

Danny McPherson wrote:
>
> Folks,
> We'd like to considering moving this document towards
> WG adoption and progression towards the chartered
> PW redundancy work.
>
> Comments to chairs/list within next two weeks (by
> 10/13/2006).
>
> Thanks!
>
> -danny
>
>
> On Sep 27, 2006, at 7:57 AM, Stewart Bryant wrote:
>
>>
>>
>> -------- Original Message --------
>> Subject:     I-D ACTION:draft-muley-pwe3-redundancy-00.txt
>> Date:     Tue, 26 Sep 2006 10:50:01 -0400
>> From:     [email-masked]
>> Reply-To:     [email-masked]
>> To:     [email-masked]
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>     Title        : Pseudowire (PW) Redundancy     Author(s)    : P.
>> Muley, et al.
>>     Filename    : draft-muley-pwe3-redundancy-00.txt
>>     Pages        : 11
>>     Date        : 2006-9-26
>>     
>> This document describes a few scenarios where PW redundancy is  
>> needed. A set of redundant PWs is configured between PE nodes in
>> SS-   PW applications, or between T-PE nodes in MS-PW applications.
>> In   order for the PE/T-PE nodes to indicate the preferred PW path
>> to   forward to one another, a new status bit is needed to indicate
>> the  preferential forwarding status of active or standby for each PW
>> in   the redundancy set. This draft specifies a new PW status bit for
>> this purpose.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-muley-pwe3-redundancy-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body
>> of the message. You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
>> subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then "get
>> draft-muley-pwe3-redundancy-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>>     [email-masked].
>> In the body type:
>>     "FILE /internet-drafts/draft-muley-pwe3-redundancy-00.txt".
>>     
>> NOTE:    The mail server at ietf.org can return the document in
>>     MIME-encoded form by using the "mpack" utility.  To use this
>>     feature, insert the command "ENCODING mime" before the "FILE"
>>     command.  To decode the response(s), you will need "munpack" or
>>     a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>     exhibit different behavior, especially when dealing with
>>     "multipart" MIME messages (i.e. documents which have been split
>>     up into multiple messages), so check your local documentation on
>>     how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Fri, 13 Oct 2006 12:16:11 -0400

Luca,
See below.

Mustapha. 

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 6:23 PM
> To: Danny McPherson
> Cc: pwe3 WG ((((((((E-mail))))))))
> Subject: Re: [PWE3] WG Adoption: draft-muley-pwe3-redundancy-00.txt]
> 
> Danny,
> 
> After carefully reading this draft , I fail to see what 
> problem this document has solved.
> In section 3.1 the document describes the case of a 
> multi-homed CE with single SS-PW redundancy. This topology , 
> does not need any protocol extensions. In fact this problem 
> has already been successfully resolved in implementations 
> without any protocol extensions. I believe that the authors 
> missed the point that a PW can only forward traffic when both 
> directions of the PW are in a forwarding state. If only one 
> direction is forwarding , then no traffic can flow in either 
> direction.
MA> The new status bit indicates the frowarding state of the SAP, not of the
PW. The forwarding status of the SAP on the CE1-PE1 link reflects the status
of the dual-homing protocol running between CE1 and {PE1, PE3}. What we want
to achieve is that PE2 knows which of PE1 or PE3 to send traffic to. If
traffic is sent to PE3 while its SAP is in standby status, PE3 will discard
this traffic.
I am open to consider other ways to solve this problem.

> Section 3.2 describes the case of multiple multi-homed CEs 
> with single SS-PW redundancy. What is the purpose of this 
> topology ? The PSN cannot fail as long as there is enough 
> diversity ( as is shown in figure  2 ).
> Why can't the PE just select another PSN tunnel if the  
> original tunnel fails ? Since PSN tunnels are uni-directional 
> the PW would not even notice the event. Again this has 
> already been implemented. I fail to see the advantage of this 
> protocol extension.
MA> In this scenario, the dual-homing protocols on the left and right sides
make independent decision of which SAP is active and which SAP is standby.
Again, the new status bit is sent to reflect this status. This way, each PE
will select the PW that will guarantee the traffic is sent to the remote PE
which has the SAP active. 
For example, assume the SAP on the CE1-PE1 link is active and the SAP on
link CE2-PE4 is active at this point in time. PE1 needs to know that it
should send traffic on PW4 and not on PW1, even if PW1 is operationally UP.
It knows finds out by checking the new bit set by PE4 in the last T-LDP
status notification message.
 
> In section 4 , the document treats of a more interesting 
> problem: MS-PW redundancy applications. Here the topology in 
> a limited subset of the possible topologies. One cannot 
> assume that there is only a single S-PE between two T-PE. In 
> fact in most applications the minimum is two S-PEs.
> This is a difficult problem to solve. Unfortunately this 
> document leaves  it for "further study".
> 
> I would like to suggest that we concentrate our effort in 
> resolving the more general problem for MS-PW, which will most 
> likely involve the use of a PCE, and some kind of ERO.
> 
MA> We also believe this problem is important to solve. Although this is a
different problem from the previous sections, they all make use of PW
redundancy to achieve the desired resilience. We had some discussions with a
few operators and vendors in the last IETF and there have been a number of
solutions proposed. One of them is based on signaling the PW precedence as
described in draft-pan-pwe3-protection-03.txt. This however will need to be
augmented to guarantee that the paths are synchronised and to allow for an
explicit switcover operation triggered by the operator (similar to APS). 
I would be interested to hear your ideas on using PCE to solve this problem.

> Luca
> 
> 
> Danny McPherson wrote:
> >
> > Folks,
> > We'd like to considering moving this document towards WG 
> adoption and 
> > progression towards the chartered PW redundancy work.
> >
> > Comments to chairs/list within next two weeks (by 10/13/2006).
> >
> > Thanks!
> >
> > -danny
> >
> >

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Fri, 13 Oct 2006 16:04:23 -0400

Sorry but in the message below I meant "AC (attachement circuit)" when I was
referring to "SAP".

Mustapha. 

> From: Mustapha Aissaoui [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 12:16 PM
> To: 'Luca Martini'; 'Danny McPherson'
> Cc: 'pwe3 WG ((((((((E-mail))))))))'
> Subject: RE: [PWE3] WG Adoption: draft-muley-pwe3-redundancy-00.txt]
> 
> Luca,
> See below.
> 
> Mustapha. 
> 
> > In section 3.1 the document describes the case of a multi-homed CE 
> > with single SS-PW redundancy. This topology , does not need any 
> > protocol extensions. In fact this problem has already been 
> > successfully resolved in implementations without any protocol 
> > extensions. I believe that the authors missed the point 
> that a PW can 
> > only forward traffic when both directions of the PW are in a 
> > forwarding state. If only one direction is forwarding , then no 
> > traffic can flow in either direction.
> MA> The new status bit indicates the frowarding state of the 
> SAP, not of 
> MA> the
> PW. The forwarding status of the SAP on the CE1-PE1 link 
> reflects the status of the dual-homing protocol running 
> between CE1 and {PE1, PE3}. What we want to achieve is that 
> PE2 knows which of PE1 or PE3 to send traffic to. If traffic 
> is sent to PE3 while its SAP is in standby status, PE3 will 
> discard this traffic.
> with single 
> > SS-PW redundancy. What is the purpose of this topology ? The PSN 
> > cannot fail as long as there is enough diversity ( as is shown in 
> > figure  2 ).
> original tunnel 
> > notice the event. Again this has already been implemented. 
> I fail to 
> > see the advantage of this protocol extension.
> MA> In this scenario, the dual-homing protocols on the left and right 
> MA> sides
> Again, the new status bit is sent to reflect this status. 
> This way, each PE will select the PW that will guarantee the 
> traffic is sent to the remote PE which has the SAP active. 
> For example, assume the SAP on the CE1-PE1 link is active and 
> the SAP on link CE2-PE4 is active at this point in time. PE1 
> needs to know that it should send traffic on PW4 and not on 
> PW1, even if PW1 is operationally UP.
> It knows finds out by checking the new bit set by PE4 in the 
> last T-LDP status notification message.
>  
> > problem: MS-PW redundancy applications. Here the topology 
> in a limited 
> > subset of the possible topologies. One cannot assume that there is 
> > only a single S-PE between two T-PE. In fact in most 
> applications the 
> > minimum is two S-PEs.
> > I would like to suggest that we concentrate our effort in resolving 
> > the more general problem for MS-PW, which will most likely 
> involve the 
> > use of a PCE, and some kind of ERO.
> > 
> MA> We also believe this problem is important to solve. 
> Although this is 
> MA> a
> different problem from the previous sections, they all make 
> use of PW redundancy to achieve the desired resilience. We 
> had some discussions with a few operators and vendors in the 
> last IETF and there have been a number of solutions proposed. 
> One of them is based on signaling the PW precedence as 
> described in draft-pan-pwe3-protection-03.txt. This however 
> will need to be augmented to guarantee that the paths are 
> synchronised and to allow for an explicit switcover operation 
> triggered by the operator (similar to APS).

---

From: Luca Martini <[email-masked]>
Date: Tue, 17 Oct 2006 14:49:06 -0600

Mustapha Aissaoui wrote:
>> problem this 
>> I am open to cFrom [email-masked] Tue Oct 17 23:24:32 2006
Date: Tue, 17 Oct 2006 14:49:06 -0600
From: Luca Martini <[email-masked]>
To: Mustapha Aissaoui <[email-masked]>
Subject: Re: [PWE3] WG Adoption: draft-muley-pwe3-redundancy-00.txt]
Cc: "'pwe3 WG \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\)'" <[email-masked]>,
	'Danny McPherson' <[email-masked]>

Mustapha Aissaoui wrote:
>> problem this 
How and an AC be in "standby " mode ?
are you talking about some obscure frame-relay feature ?
ACs can only have one of the status defined in the OAM message mapping
draft.

In the architecture we can have a PW in administratively disabled mode.
The concept of "standby" is only local to a U-PE.

>> MA> In this scenario, the dual-homing protocols on the left and right 
what dual homing protocols ?
>> last T-LDP status notification message.
ok but if the PSN tunnel never fails , why would a PE ever choose a
different PW ?
ACs cannot signal anything except UP , or DOWN state ....
Are you talking about expanding this architecture ?
>> I would be interested to hear your ideas on using PCE to 
I can only think of two possible solutions to choose redundant paths:

1- have a loose S-PE path specified by configuration. This is the
solution that is most likely to be used first given the small number of
ASBRs that SP will initially  have .

2- Use a PCE to compute the primary and alternate path.

Once this is done there is no need of any sort of "redundancy" bits.
However we will need some flag to designate PW priority with the label
mapping message.

I have the feeling that we are not speaking the same language .... the
architecture does not define an AC is connected to more then one PW.

Luca

>>>>> A New Internet-Draft is available from the on-line 
>>>>>           
>> Internet-Drafts 
>>     
>>>>> directories.
>>>>>
>>>>>
>>>>>     Title        : Pseudowire (PW) Redundancy     
>>>>>           
>> Author(s)    : P.
>>     
>>>>> Muley, et al.
>>>>> SS-   PW applications, or between T-PE nodes in MS-PW 
>>>>>           
>> applications.
>>     
>>>>> In   order for the PE/T-PE nodes to indicate the 
>>>>>           
>> preferred PW path
>>     
>>>>> to   forward to one another, a new status bit is needed 
>>>>>           
>> to indicate
>>     
>>>>> the  preferential forwarding status of active or standby
>>>>>           
>>> for each PW
>>>       
>>>>> in   the redundancy set. This draft specifies a new PW 
>>>>>           
>>> status bit for
>>>       
>>>>> this purpose.
>>>>>
>> http://www.ietf.org/internet-drafts/draft-muley-pwe3-redundancy-00.tx
>>     
>>>>> t
>>>>>
>>>>> To remove yourself from the I-D Announcement list, send a
>>>>>           
>>> message to
>>>       
>>>>> [email-masked] with the word unsubscribe in
>>>>>           
>>> the body
>>>       
>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to 
>>>>>           
>> change your 
>>     
>>>>> subscription settings.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP. Login
>>>>>           
>>> with the
>>>       
>>>>> username "anonymous" and a password of your e-mail 
>>>>>           
>> address. After 
>>     
>>>>>     command.  To decode the response(s), you will need 
>>>>>           
>> "munpack" or
>>     
>>>>>     a MIME-compliant mail reader.  Different
>>>>>           
>>> MIME-compliant mail readers
>>>       
>>>>>     "multipart" MIME messages (i.e. documents which have 
>>>>>           
>> been split
>>     
>>>>>     up into multiple messages), so check your local
>>>>>           
>>> documentation on
>>>       
>>>>> implementation to automatically retrieve the ASCII 
>>>>>           
>> version of the 
>>     
>>>>> Internet-Draft.
>>>>>
>>>>>
>>>>> Content-Type: text/plain

---

From: Cao Wei <[email-masked]>
Date: Wed, 18 Oct 2006 15:28:11 +0800

Hi Danny,
     I read your draft with interest  and I have a few comments. 

In section 3.1
    What is the "dual-homing protocol"?  Generally the protection should be either 
taken by CE or PE. It is not convenient to require a CE device cooperate with 
multiple PEs. 
    Also as you pointed out in page 5, "Note in this example, the receipt of 
   the operational status of the AC on the CE1-PE1 link is normally 
   sufficient to have PE2 switch the path to PW2."    I believe it is sufficient.

In section 3.2
    There are four PWs between CE1 and CE2. But I think the cost is expensive.
May be  two PWs (PW1 and PW2) are enough for the scenario. For example,
In the case the AC  between CE1 and PE2 fail, PW1 will be turned to down. Both CE1 
and CE2 can detect  the failure (e.g. BFD) then they can switch to the other ACs and
PW2 will be used.  
    
Regards,
Cao Wei