Subject: [PWE3] Channel Type defined in draft-ietf-pwe3-segmented-pw-02 disaccord with RFC4385

From: zikang <[email-masked]>
Date: Wed, 11 Oct 2006 16:58:09 +0800

Hi,

   I want to know the channel type of MH-VCCV. 
   But in draft-ietf-pwe3-segmented-pw-02, the define is:

"   The [PW-CW] defines an PW Associated Channel, which is specified in
   [VCCV] as follows for single-hop pseudowires:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|  Reserved = 0 |         Channel Type = 0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Multi-hop pseudowire OAM is indicated using the following PW header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|  0x00 |  Reserved = 0 |         Channel Type = 0x01   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | MH-TTL        |            MH-VCCV sub-TLV                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"
   The first question is:

   In single-hop PW, the channel type is 0x21 for IPv4 and 0x57 for IPv6.
   This is defined in RFC 4385.

   The secont question is:

   In multi-hop PW, the channel type can not discriminate the PDU is IPv4 or IPv6.

   Thanks for any answer!

Zi Kang

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

---

From: Luca Martini <[email-masked]>
Date: Tue, 17 Oct 2006 16:34:45 -0600

Zi Kang,

Please disregard this section in draft-ietf-pwe3-segmented-pw-02, it is incorrect.
We are going to change it in the next revision to agree with the rfc.
Thanks.
Luca

onsider other ways to solve this problem.
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.

>>     
>>> 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 
>> MA> sides
>>     
what dual homing protocols ?
>> 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.
>>     
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 ?
>>  
>>     
>>> 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.
>>>       
>> 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). 
>> I would be interested to hear your ideas on using PCE to 
>> solve this problem.
>>
>>     
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

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

---

From: Luca Martini <[email-masked]>
Date: Tue, 17 Oct 2006 16:34:45 -0600

Zi Kang,