From yaakov_s@rad.com Wed Jul 1 07:03:05 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497B828C539 for ; Wed, 1 Jul 2009 07:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRWhYWYfXMWs for ; Wed, 1 Jul 2009 07:03:04 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 161E028C536 for ; Wed, 1 Jul 2009 07:03:01 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 01 Jul 2009 17:02:54 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 1 Jul 2009 17:02:54 +0300 From: Yaakov Stein To: "pwe3@ietf.org" Date: Wed, 1 Jul 2009 17:02:53 +0300 Thread-Topic: Ethernet PW congestion control draft Thread-Index: Acn6VKBPwdGNwT9wRFGM+cqm0jUdmQ== Message-ID: <48E7911F78327A449A9FB9563766728611D56CB0@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728611D56CB0exrad4adradcoil_" MIME-Version: 1.0 Subject: [PWE3] Ethernet PW congestion control draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:03:05 -0000 --_000_48E7911F78327A449A9FB9563766728611D56CB0exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As promised in San Francisco, I have posted a draft detailing the handling = of congestion for Ethernet PWs. Y(J)S Filename: draft-stein-pwe3-ethpwcong Revision: 00 Title: Ethernet PW Congestion Handling Mechanisms Creation_date: 2009-07-01 WG ID: Independent Submission Number_of_pages: 7 Abstract: Mechanisms for handling congestion in Ethernet pseudowires are presented. These mechanisms extend capabilities of the native service across the PSN, = and require use of the PWE3 control word. --_000_48E7911F78327A449A9FB9563766728611D56CB0exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As promised in San Francisco, I have posted a draft detailing the handling of congestion

for Ethernet PWs.

 

Y(J)S

 

 

 

Filename:   draft-stein-pwe3-ethpwcong

Revision:   00

Title:       &nb= sp;    Ethernet PW Congestion Handling Mechanisms

Creation_date:    2009-07-01

WG ID:       &nb= sp;    Independent Submission

Number_of_pages: 7

 

Abstract:

Mechanisms for handling congestion in Ethernet pseudow= ires are presented. 

These mechanisms extend capabilities of the native ser= vice across the PSN, and require use of the PWE3 control word.

 

--_000_48E7911F78327A449A9FB9563766728611D56CB0exrad4adradcoil_-- From Alexander.Vainshtein@ecitele.com Wed Jul 1 07:54:23 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C364428C0FA for ; Wed, 1 Jul 2009 07:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9MjcXZZAT3z for ; Wed, 1 Jul 2009 07:54:22 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id B09673A6858 for ; Wed, 1 Jul 2009 07:54:21 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 01 Jul 2009 17:46:51 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 17:51:30 +0300 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 1 Jul 2009 17:51:30 +0300 From: Alexander Vainshtein To: Yaakov Stein Date: Wed, 1 Jul 2009 17:51:29 +0300 Thread-Topic: Ethernet PW congestion control draft Thread-Index: Acn6VKBPwdGNwT9wRFGM+cqm0jUdmQAAbA4g Message-ID: References: <48E7911F78327A449A9FB9563766728611D56CB0@exrad4.ad.rad.co.il> In-Reply-To: <48E7911F78327A449A9FB9563766728611D56CB0@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76AA61700EF3ILPTMAIL02eci_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2009 14:51:30.0456 (UTC) FILETIME=[6B37D980:01C9FA5B] Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Ethernet PW congestion control draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:54:23 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76AA61700EF3ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaakov, I've read the draft and I have a couple of questions. 1. Dummy PW packets for BECN * The draft states that these packets must have their BECN bit set in= the CW, but the LEN field in the CW must be set to 0 to indicate that they= do not carry any data. * However, the semantics of the LEN field as defined in RFC 4385 uses= the 0 value to indicate that the MPLS payload size is greater than or equa= l to 64 bytes. Hence, for an Ethernet PWs using the CW, the LEN field will = be always set to zero (since MPLS payload is at least 64 bytes) 2. Ingress PE action on received BECN * The draft says that, where applicable, the ingress PE, upon receivi= ng a PW packet with the BECN set,. SHOULD send PAUSE frames or apply backpr= essure (presumably on half-duplex links) towards its adjacent CE * This proposal looks to me : * Incomplete: Ethernet PAUSE frames as defined in IEEE 802.3-2005,= Annex 31B "MAC Control PAUSE Operation" carry the pause-time value (16bits= ). You did not specify which value of this parameter should be used * Problematic in the situations when multiple Ethernet PWs in the = ingress PE are originated on service-delimiting VLANs in the same port. PAU= SE, when app[lied, will stop ALL these VLANs, and not just one that is asso= ciated with the congested PW. Of course, this equally applies to backpressu= re in the case of half-duplex ports. 3. DEI interworking between the PW and AC * The draft says that egress PE MUST copy the DEI bit from the CW to = the Q-in-Q header (if such is used) of the Ethernet frame it sends towards = its adjacent CE * IMHO MUST is too strong here: please take into account, that pre-80= 2.1ad HW would treat the DEI bit in the VLAN tag as the (obsoleted) CFI bit= and would simply discard all frames with such a bit set. One may say that = such an action does not contradict the DEI semantics, but I would prefer no= t to extedn the notion of "discard eligibility" that far. A configurable op= tion looks better to me. Hopefully these notes will be useful. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Wednesday, July 01, 2009 5:03 PM To: pwe3@ietf.org Subject: [PWE3] Ethernet PW congestion control draft Hi all, As promised in San Francisco, I have posted a draft detailing the handling = of congestion for Ethernet PWs. Y(J)S Filename: draft-stein-pwe3-ethpwcong Revision: 00 Title: Ethernet PW Congestion Handling Mechanisms Creation_date: 2009-07-01 WG ID: Independent Submission Number_of_pages: 7 Abstract: Mechanisms for handling congestion in Ethernet pseudowires are presented. These mechanisms extend capabilities of the native service across the PSN, = and require use of the PWE3 control word. --_000_A3C5DF08D38B6049839A6F553B331C76AA61700EF3ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yaakov,
I've=20 read the draft and I have a couple of questions.
 
  1. Dummy PW packets for=20 BECN
    • The=20 draft states that these packets must have their BECN bit set in the CW,= but=20 the LEN field in the CW must be set to 0 to indicate that they do not c= arry=20 any data.
    • However, the semantics of the LEN field as d= efined=20 in RFC 4385 uses the 0 value to indicate that the MPLS payload size is= =20 greater than or equal to 64 bytes. Hence, for an Ethernet PWs using the= CW,=20 the LEN field will be always set to zero (since MPLS payload i= s at=20 least 64 bytes)
  2. Ingress PE action on received=20 BECN
    • The=20 draft says that, where applicable, the ingress PE, upon receiving a PW= =20 packet with the BECN set,. SHOULD send PAUSE frames or apply backpressu= re=20 (presumably on half-duplex links) towards its adjacent CE=
    • This proposal looks to me :
      • Incomplete: Ethernet PAUSE frames= as=20 defined in IEEE 802.3-2005, Annex 31B "MAC Control PAUSE=20 Operation" carry the pause-time value (16bits). You d= id not=20 specify which value of this parameter should be used
      • Problematic in the situations whe= n=20 multiple Ethernet PWs in the ingress PE are originated on=20 service-delimiting VLANs in the same port. PAUSE, when app[lied, will= stop=20 ALL these VLANs, and not just one that is associated with the congest= ed=20 PW. Of course, this equally applies to backpressure in the case of=20 half-duplex ports.
  3. DEI interworking between the PW and=20 AC
    • The=20 draft says that egress PE MUST copy the DEI bit from the CW to the Q-in= -Q=20 header (if such is used) of the Ethernet frame it sends towards its adj= acent=20 CE
    • IMHO MUST is too strong here: please take in= to=20 account, that pre-802.1ad HW would treat the DEI bit in the VLAN tag as= the=20 (obsoleted) CFI bit and would simply discard all frames with s= uch a=20 bit set. One may say that such an action does not contradict the DEI=20 semantics, but I would prefer not to extedn the notion of "discard=20 eligibility" that far. A configurable option looks better to=20 me.
Hopefully these notes will be=20 useful.
 
Regards,
     Sasha
 

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov=20 Stein
Sent: Wednesday, July 01, 2009 5:03 PM
To:=20 pwe3@ietf.org
Subject: [PWE3] Ethernet PW congestion control=20 draft

Hi all,

 

As promised in San Francisco, I have posted a draft= =20 detailing the handling of congestion

for Ethernet PWs.

 

Y(J)S

 

 

 

Filename:  =20 draft-stein-pwe3-ethpwcong

Revision:   00

Title:       &nbs= p;   =20 Ethernet PW Congestion Handling Mechanisms

Creation_date:   =20 2009-07-01

WG=20 ID:           =20 Independent Submission

Number_of_pages: 7

 

Abstract:

Mechanisms for handling congestion in Ethernet pseud= owires=20 are presented. 

These mechanisms extend capabilities of the native s= ervice=20 across the PSN, and require use of the PWE3 control word.

 

--_000_A3C5DF08D38B6049839A6F553B331C76AA61700EF3ILPTMAIL02eci_-- From yaakov_s@rad.com Wed Jul 1 12:08:08 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD373A67E4 for ; Wed, 1 Jul 2009 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBspxaraeQbs for ; Wed, 1 Jul 2009 12:08:06 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by core3.amsl.com (Postfix) with ESMTP id 2F3BD3A698B for ; Wed, 1 Jul 2009 12:08:03 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir1.rad.co.il with ESMTP; 01 Jul 2009 22:07:42 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Wed, 1 Jul 2009 22:07:41 +0300 From: Yaakov Stein To: Alexander Vainshtein Date: Wed, 1 Jul 2009 22:07:38 +0300 Thread-Topic: Ethernet PW congestion control draft Thread-Index: Acn6VKBPwdGNwT9wRFGM+cqm0jUdmQAAbA4gAAotPWA= Message-ID: <48E7911F78327A449A9FB9563766728611D56E10@exrad4.ad.rad.co.il> References: <48E7911F78327A449A9FB9563766728611D56CB0@exrad4.ad.rad.co.il> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB9563766728611D56E10exrad4adradcoil_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Ethernet PW congestion control draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:08:08 -0000 --_000_48E7911F78327A449A9FB9563766728611D56E10exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha Thanks. You comments are very useful as usual. I'll change the length field to something small. We can discuss the other issues. Y(J)S From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 01, 2009 17:51 To: Yaakov Stein Cc: pwe3@ietf.org Subject: RE: Ethernet PW congestion control draft Yaakov, I've read the draft and I have a couple of questions. 1. Dummy PW packets for BECN * The draft states that these packets must have their BECN bit set in= the CW, but the LEN field in the CW must be set to 0 to indicate that they= do not carry any data. * However, the semantics of the LEN field as defined in RFC 4385 uses= the 0 value to indicate that the MPLS payload size is greater than or equa= l to 64 bytes. Hence, for an Ethernet PWs using the CW, the LEN field will = be always set to zero (since MPLS payload is at least 64 bytes) 2. Ingress PE action on received BECN * The draft says that, where applicable, the ingress PE, upon receivi= ng a PW packet with the BECN set,. SHOULD send PAUSE frames or apply backpr= essure (presumably on half-duplex links) towards its adjacent CE * This proposal looks to me : * Incomplete: Ethernet PAUSE frames as defined in IEEE 802.3-2005,= Annex 31B "MAC Control PAUSE Operation" carry the pause-time value (16bits= ). You did not specify which value of this parameter should be used * Problematic in the situations when multiple Ethernet PWs in the = ingress PE are originated on service-delimiting VLANs in the same port. PAU= SE, when app[lied, will stop ALL these VLANs, and not just one that is asso= ciated with the congested PW. Of course, this equally applies to backpressu= re in the case of half-duplex ports. 3. DEI interworking between the PW and AC * The draft says that egress PE MUST copy the DEI bit from the CW to = the Q-in-Q header (if such is used) of the Ethernet frame it sends towards = its adjacent CE * IMHO MUST is too strong here: please take into account, that pre-80= 2.1ad HW would treat the DEI bit in the VLAN tag as the (obsoleted) CFI bit= and would simply discard all frames with such a bit set. One may say that = such an action does not contradict the DEI semantics, but I would prefer no= t to extedn the notion of "discard eligibility" that far. A configurable op= tion looks better to me. Hopefully these notes will be useful. Regards, Sasha ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaa= kov Stein Sent: Wednesday, July 01, 2009 5:03 PM To: pwe3@ietf.org Subject: [PWE3] Ethernet PW congestion control draft Hi all, As promised in San Francisco, I have posted a draft detailing the handling = of congestion for Ethernet PWs. Y(J)S Filename: draft-stein-pwe3-ethpwcong Revision: 00 Title: Ethernet PW Congestion Handling Mechanisms Creation_date: 2009-07-01 WG ID: Independent Submission Number_of_pages: 7 Abstract: Mechanisms for handling congestion in Ethernet pseudowires are presented. These mechanisms extend capabilities of the native service across the PSN, = and require use of the PWE3 control word. --_000_48E7911F78327A449A9FB9563766728611D56E10exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha<= /p>

 =

Thanks.

 =

You comments are very us= eful as usual.

 =

I'll change the length f= ield to something small.

 =

We can discuss the other= issues.

 =

Y(J)S<= /p>

 =

From: Alexander Vai= nshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 01, 2009 17:51
To: Yaakov Stein
Cc: pwe3@ietf.org
Subject: RE: Ethernet PW congestion control draft<= /p>

 

Yaakov,

I've read the draft and I have a couple of questions.

 

  1. Dummy PW packets for BECN=
    • The draft states that these packets = must have their BECN bit set in the CW, but the LEN field in the CW must b= e set to 0 to indicate that they do not carry any data.
    • However, the semantics of the LEN fi= eld as defined in RFC 4385 uses the 0 value to indicate that the MPLS pay= load size is greater than or equal to 64 bytes. Hence, for an Ethernet PWs using the CW, the LEN field will be always set to zero (since MPLS payload is at least 64 bytes)
  2. Ingress PE action on received BECN=
    • The draft says that, where applicabl= e, the ingress PE, upon receiving a PW packet with the BECN set,. SHOULD send PAUSE frames or apply backpressure (presumably on half-duplex li= nks) towards its adjacent CE
    • This proposal looks to me :
      • Incomplete<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blu= e'>: Ethernet PAUSE frames as defined in IEEE 802.3-2005, Annex 31B "= ;MAC Control PAUSE Operati= on" carry the pause-time value (16bits). You di= d not specify which value of this parameter should be used
      • Problematic= in the situations when multiple Ethernet PWs in the ingress PE are orig= inated on service-delimiting VLANs in the same port. PAUSE, when app[lied, = will stop ALL these VLANs, and not just one that is associated with the congested PW. Of course, this equally applies to backpressure in the case of half-duplex ports.
  3. DEI interworking between the PW and A= C=
    • The draft says that egress PE MUST c= opy the DEI bit from the CW to the Q-in-Q header (if such is used) of the Ethernet frame it sends towards its adjacent CE
    • IMHO MUST is too strong here: please take into account, that pre-802.1ad HW would treat the DEI bit in the VLAN tag as the (obsoleted) CFI bit and would simply discard all frames<= /em> with such a bit set. One may say that such an action does not contrad= ict the DEI semantics, but I would prefer not to extedn the notion of "discard eligibility" that far. A configurable option looks better to me.

Hopefully these notes will be useful.

 

Regards,

     Sasha

 

 

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Wednesday, July 01, 2009 5:03 PM
To: pwe3@ietf.org
Subject: [PWE3] Ethernet PW congestion control draft

Hi all,

 

As promised in San Francisco, I have posted a draft detailing the handling of congestion

for Ethernet PWs.

 

Y(J)S

 

 

 

Filename:   draft-stein-pwe3-ethpwcong

Revision:   00

Title:       &nb= sp;    Ethernet PW Congestion Handling Mechanisms

Creation_date:    2009-07-01

WG ID:       &nb= sp;    Independent Submission

Number_of_pages: 7

 

Abstract:

Mechanisms for handling congestion in Ethernet pseudow= ires are presented. 

These mechanisms extend capabilities of the native ser= vice across the PSN, and require use of the PWE3 control word.

 

--_000_48E7911F78327A449A9FB9563766728611D56E10exrad4adradcoil_-- From benjamin.niven-jenkins@bt.com Wed Jul 1 13:03:11 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9E63A6838; Wed, 1 Jul 2009 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=0.969, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXnM8DD6qzQM; Wed, 1 Jul 2009 13:03:11 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C7C2B3A6821; Wed, 1 Jul 2009 13:03:10 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 21:03:20 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jul 2009 20:03:18 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 01 Jul 2009 21:03:17 +0100 From: Ben Niven-Jenkins To: Loa Andersson , , , , Message-ID: Thread-Topic: [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document Thread-Index: Acn6hvkv8+OWPI7irk223I8aXpu5Zg== In-Reply-To: <4A4A1EFA.6040101@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jul 2009 20:03:20.0120 (UTC) FILETIME=[FB0C0380:01C9FA86] Subject: Re: [PWE3] [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:03:11 -0000 Support. Ben On 30/06/2009 15:19, "Loa Andersson" wrote: > All, > > we have an individual draft, draft-andersson-mpls-tp-process-03.txt, > that describes additions to the mpls working group process to allow > ITU-T to give input on MPLS-TP Internet Drafts. > > It pretty much captures current practice, and from the start we had no > intention to ever progress, but recently there has been comments that > it would have a better and clearer sttus if it were a working group > document. > > We have had no plans to ever make it an RFC, but it has been pointed > out that it would be possible to publish as an Historical RFC. Whether > we execute on that or not is not yet decided. > > Therefore, is is to start at two week poll on making > draft-andersson-mpls-tp-process-03.txt an MPLS working group document. > > The poll ends on July 14. > > Please send your comments to the mpls-tp list. > > Please > > > > From tnadeau@lucidvision.com Wed Jul 1 14:15:54 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA383A6F3A; Wed, 1 Jul 2009 14:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNHcVjjV-EZk; Wed, 1 Jul 2009 14:15:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id CF2803A6D73; Wed, 1 Jul 2009 14:15:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 66A273F54A18; Wed, 1 Jul 2009 17:16:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at lucidvision.local Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viJXjmg1n4B2; Wed, 1 Jul 2009 17:16:09 -0400 (EDT) Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.myfairpoint.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 529313F54A09; Wed, 1 Jul 2009 17:16:09 -0400 (EDT) Message-Id: <621E8D9D-514D-4794-B5A6-05F85BBCFC0C@lucidvision.com> From: Thomas Nadeau To: Ben Niven-Jenkins In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 17:16:08 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [PWE3] [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:15:54 -0000 Support. > Support. Ben > > > > On 30/06/2009 15:19, "Loa Andersson" wrote: > >> All, >> >> we have an individual draft, draft-andersson-mpls-tp-process-03.txt, >> that describes additions to the mpls working group process to allow >> ITU-T to give input on MPLS-TP Internet Drafts. >> >> It pretty much captures current practice, and from the start we had >> no >> intention to ever progress, but recently there has been comments that >> it would have a better and clearer sttus if it were a working group >> document. >> >> We have had no plans to ever make it an RFC, but it has been pointed >> out that it would be possible to publish as an Historical RFC. >> Whether >> we execute on that or not is not yet decided. >> >> Therefore, is is to start at two week poll on making >> draft-andersson-mpls-tp-process-03.txt an MPLS working group >> document. >> >> The poll ends on July 14. >> >> Please send your comments to the mpls-tp list. >> >> Please >> >> >> >> > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From root@core3.amsl.com Thu Jul 2 01:15:01 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3D09C3A6E47; Thu, 2 Jul 2009 01:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090702081501.3D09C3A6E47@core3.amsl.com> Date: Thu, 2 Jul 2009 01:15:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-fat-pw-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Flow Aware Transport of Pseudowires over an MPLS PSN Author(s) : S. Bryant, et al. Filename : draft-ietf-pwe3-fat-pw-00.txt Pages : 18 Date : 2009-07-01 Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-fat-pw-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-02010454.I-D@ietf.org> --NextPart-- From stbryant@cisco.com Thu Jul 2 04:56:06 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E201E28C14A for ; Thu, 2 Jul 2009 04:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6cjUcfFX9G2 for ; Thu, 2 Jul 2009 04:56:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC25F3A6D5B for ; Thu, 2 Jul 2009 04:56:04 -0700 (PDT) X-Files: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch.eml : None X-IronPort-AV: E=Sophos;i="4.42,332,1243814400"; d="eml'208?scan'208,208";a="44205621" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Jul 2009 11:56:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n62BuPcI012424 for ; Thu, 2 Jul 2009 13:56:25 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n62BuPER022170 for ; Thu, 2 Jul 2009 11:56:25 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n62BuOD09927; Thu, 2 Jul 2009 12:56:24 +0100 (BST) Message-ID: <4A4CA068.9090002@cisco.com> Date: Thu, 02 Jul 2009 12:56:24 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pwe3 Content-Type: multipart/mixed; boundary="------------000302060301040308060009" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11455; t=1246535785; x=1247399785; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20DISCUSS=20and=20COMMENT=3A=20draft-ie tf-pwe3-ms-pw-arch] |Sender:=20; bh=7WM1aAZCQ4zmEAdNkgon33083a8TYMxOG9TVKg7H3Po=; b=DQzeHb6h89SBZyQdCg6KR337Ew7Iwmfpxp5Bm3ZaKqaz53s1sylyyaCzML 23GrWCFuk3+AzDESLASdz8uiS6N77580jUssi1BhqTHyHHhtyBuCf2C66aBX dyzXCkdRwH; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [PWE3] [Fwd: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:56:07 -0000 This is a multi-part message in MIME format. --------------000302060301040308060009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit --------------000302060301040308060009 Content-Type: message/rfc822; name="DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n62BWJD08027 for ; Thu, 2 Jul 2009 12:32:19 +0100 (BST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2009 11:32:18 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n62BWIkW008464 for ; Thu, 2 Jul 2009 04:32:18 -0700 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n62BWHaQ008634 for ; Thu, 2 Jul 2009 11:32:18 GMT X-from-outside-Cisco: 64.170.98.42 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoICAMw3TEpAqmIqhWdsb2JhbACBUY0eAYodAQEBCgsKBRWcZJkFhBEFgTo X-IronPort-AV: E=Sophos;i="4.42,332,1243814400"; d="scan'208";a="114269412" Received: from lptools1.amsl.com (HELO zinfandel.tools.ietf.org) ([64.170.98.42]) by sj-inbound-f.cisco.com with ESMTP/TLS/AES256-SHA; 02 Jul 2009 11:32:18 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MMKWT-0006Yp-DT; Thu, 02 Jul 2009 04:32:14 -0700 Received: by core3.amsl.com (Postfix, from userid 30) id 2DED628C22E; Thu, 2 Jul 2009 04:31:19 -0700 (PDT) From: Adrian Farrel To: iesg@ietf.org Cc: pwe3-chairs@tools.ietf.org, draft-ietf-pwe3-ms-pw-arch@tools.ietf.org, david.sinicrope@ericsson.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090702113120.2DED628C22E@core3.amsl.com> Date: Thu, 2 Jul 2009 04:31:20 -0700 (PDT) X-SA-Exim-Connect-IP: 2001:1890:1112:1::20 X-SA-Exim-Rcpt-To: draft-ietf-pwe3-ms-pw-arch@tools.ietf.org, pwe3-chairs@tools.ietf.org X-SA-Exim-Mail-From: wwwrun@core3.amsl.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Subject: DISCUSS and COMMENT: draft-ietf-pwe3-ms-pw-arch X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Authentication-Results: sj-dkim-4; header.From=adrian.farrel@huawei.com; dkim=neutral Discuss: I appreciate the work that has gone into this document, but I believe it needs some more polish. === Section 1.1 It is not clear to me that the first motivation (which seems the most realistic of the motivations) naturally leads to multisegment PWs when the PSN tunnels can themselves be aggregated and tunneled using standard features of MPLS-TE. The other motivations require some form of planning/routing decisions in what we might call the PW layer. These techniques do not yet exist and would need to be invented and developed. However, inter- domain MPLS-TE already exists and is proven in deployments. Why would you not continue to use single segment PWs while making the multi-domain and aggregation decisions within the MPLS-TE LSPs? (The same argument applies to IP-in-IP tunnelling.) The only argument I can see in favor of your technique to address these motivations is that you can support different PSN tunneling techniques in different domains. Obviously, this does not apply for the first of your three motivations as there is only one domain. In the other two cases, I suggest that the arrangement in figure 2 would normally allow tunnelling of the access technology tunnels over the core technology tunnel. That leaves only the case of peer domains with different tunnelling technologies. You seem to be inventing a lot or architecture for a small set of deployments === I am concerned that you are not separating two distinct cases. Where the PSN technology is the same, and the PW encapsulation is the same, you are truly switching. You have just two layers to worry about. Where the PSN technology chnages and there is a change in encapsulation there is a bigger question. You are not switching PW segments, but you are ending one encapsulation and begining a new one. This is the "translation" you describe in Section 3.2. Translation or gateway functions are neither elegant nor scalable with an increase in tunneling technologies, and I note that you have hidden/ignored this problem in Figure 7. Architecturally, there are only two ways to handle this: 1. You emerge from the first encapsulation into the client (i.e. payload) layer, swtich in that layer, and re-encapsulate for the next PW segment. I suspect you don;t want to do this as it requires you to install L2-capable switching equipment at the switching points. 2. You insert a thin transport-agnostic PW layer between the client layer and the PW encapsulation layer. === Section 1.3 It seems that the terminology is tied in some knots! An S-PE would be the perfect term except that in motivation 1 you have stitching within a domain, and in motivation 2 you may be stitching at ABRs (which are not PEs). So, in the middle of the terminology section you use "PW Switching Point" without any definition. Indeed, the convolutions are such that you have... A S-PE can exist anywhere where a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network. That is: "A provider edge is not limited to the edge of a provider network." Clearly a problem! You need to introduce the term "PW Switching Point" and recast the whole document in terms of PW Switching Points and not S-PEs. === Section 3 is very important. It is good to see that you have made the architectural separation between the PW layer and the PSN layer. You introduce a concept "The design of PW routing domains..." which is very significant, but you don't discuss it at all in the rest of the document (you vaguely touch on it in Section 9.1). Since you have introduced the concept of a PW routing domain, you must discuss its architecture and operation. Saying in Section 3.1 that: The selection of which set of S-PEs to use to reach a given T-PE is considered to be within the scope of MS-PW solutions. ...is dodging the issue too much. In an architecture you must say what functions you require for operation and on parameters you expect these functions to act. Tucked away in the text of Section 3 is an assumption that IP reachability and tunnel reachability (e.g. MPLS-TE reachability) are synonymous. They are not. === An "interesting" wrinkle. In RFC 3985, the PW segment is considered to run from the input interface of the ingress PE to the output interface of the egress PE. This clearly continues to apply for the T-PEs, but it is not clear in your figures what happens at S-PEs. For example, in Figure 4, it is unclear where the PW segments start and end. Obviously, this is intended to be at "the switcing point" but you don't make this clear, and extrapolation from 3985 would lead someone to assume that the first segment ended at the outgoing interface of the first S-PE. === Section 6 says Where the encapsulation format is different e.g. MPLS and L2TPv3, the payload encapsulation may be transparently translated at the S-PE. But 8.2 says that an S-PE may introduce fragmentation. This is good, but is not a transparent translation of encapsulation. === Section 9.1 is confused about "dynamically chosen" and "signaled". Possibly, For the signaled case, there are two options for selecting the path of the MS-PW: should read For the case of dynamic choice of PW switching points, there are two options for selecting the path of the MS-PW: === In Section 9.2 Since a multi-segment PW consists of a number of concatenated PW segments, the emulated service can only be considered as being up when all of the constituting PW segments and PSN tunnels (if used) are functional and operational along the entire path of the MS-PW. I think this is the first time you have suggested that PSN tunnels might not be used. === Comment: Introduction The PW passes through a maximum of one PSN tunnel between the originating and terminating PEs. I'm not sure that this limitation is made in RFC 3985. I don't believe that there is anything that prohibits LSP stitching to make a "multi-segment LSP tunnel" that carries a single segment PW. === Section 1.1 You suggest that the solution helps to reduce the scaling issues at PEs and P nodes. But doesn't the stitching PE have a signficant scaling problem? === Section 2 As well as supporting traditional L2VPNs, an MS-PW is applicable to providing connectivity within a transport network based on packet switching technology e.g. MPLS Transport profile (MPLS-TP) [6]. s/within/across/ I don't think [6] is the best reference for MPLS-TP. You would do better to point at draft-ietf-mpls-tp-requirements and draft-ietf-mpls-tp-framework === Section 4 Note that although the S-PE path is therefore reciprocal, the path taken by the PSN tunnels between the T-PEs and S-PEs may not be reciprocal due to choices made by the PSN routing protocol. s/may/might/ !!! But this is an odd thing to say. Why do you require the S-PEs to be reciprocal, but not the tunnels? Are you sure your architecture is not being driven by your solutions? === Section 9.2 RFC 3985 describes the need for failure and other status notification mechanisms for PWs. These considerations also apply to multi-segment pseudowires. In addition, if a failure notification mechanism is provided for consecutive segments of the same PW, the S-PE must be able to propagate such notifications between the consecutive concatenated segments. This looks like a requirement hiding in the wrong document! Is it? === idnits says ** You're using the IETF Trust Provisions Section 6.b License Notice from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/) === Nits Abstract s/same providers PSN/same provider's PSN/ --- Section 8.1 Expand NSP on first use. --- Section 11 Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk 01.txt, or its successor, prior to publication. Ready to be fixed now? --- Section 11 s/However, this may not effective/However, this may not be effective/ --- I would prefer the references section to be named "Normative References if they really are all normative. --- Your references are out of date. --------------000302060301040308060009-- From gregimirsky@gmail.com Thu Jul 2 08:57:10 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A7F3A6915; Thu, 2 Jul 2009 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx-D2PxK8Gif; Thu, 2 Jul 2009 08:57:10 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 29EA83A682E; Thu, 2 Jul 2009 08:57:08 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so482368fgg.18 for ; Thu, 02 Jul 2009 08:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dlfPyzLgWbWkzCCes7O75nZ1YQwjeEYKKgu9mCUXKn4=; b=KDCjDt1t/cnvGPCbT6BO36UQyhhCaDzNDoaRsFMPirlVEy1JTp9BcE889IkneW8HxH a4zxUz3vI7oIOAQhTaLYjHhnbzqC3tPSd/MNieSb7N8VKTExCz4KoPjKiJacTmCMzeCJ zwqTB4P3SE41Y4hIQdlVUWqZib7Cje7m6pLxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JvQg41OmuAYzNz/R0EbC1my6keHR/lwIodVg5eWo5kdMBNqTogQeVZGuFtDAZqu5/8 KzIPfAWdMzs4XelnvPvgV8gACa6Vw4sbZOoUhO2MN5WJDSIh9+kW59YlFMewTZxh5PmO SAYwoinUao/5W2V9oBHwFxdrWTBegTxEvrKc4= MIME-Version: 1.0 Received: by 10.239.162.17 with SMTP id j17mr18583hbd.123.1246550248668; Thu, 02 Jul 2009 08:57:28 -0700 (PDT) In-Reply-To: <4A4A1EFA.6040101@pi.nu> References: <4A4A1EFA.6040101@pi.nu> Date: Thu, 2 Jul 2009 11:57:28 -0400 Message-ID: <787be2780907020857j4f87f2d2u645e9307df2dcd9d@mail.gmail.com> From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=001485f040a4c44372046dbb1822 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [PWE3] [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:57:10 -0000 --001485f040a4c44372046dbb1822 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support Thanks, Greg On Tue, Jun 30, 2009 at 10:19 AM, Loa Andersson wrote: > All, > > we have an individual draft, draft-andersson-mpls-tp-process-03.txt, > that describes additions to the mpls working group process to allow > ITU-T to give input on MPLS-TP Internet Drafts. > > It pretty much captures current practice, and from the start we had no > intention to ever progress, but recently there has been comments that > it would have a better and clearer sttus if it were a working group > document. > > We have had no plans to ever make it an RFC, but it has been pointed > out that it would be possible to publish as an Historical RFC. Whether > we execute on that or not is not yet decided. > > Therefore, is is to start at two week poll on making > draft-andersson-mpls-tp-process-03.txt an MPLS working group document. > > The poll ends on July 14. > > Please send your comments to the mpls-tp list. > > Please > > > > > > -- > > > Loa Andersson > > Sr Strategy and Standards Manager phone: +46 10 717 52 13 > Ericsson /// +46 767 72 92 13 > > email: loa.andersson@ericsson.com > loa@pi.nu > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --001485f040a4c44372046dbb1822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

Thanks,
Greg

On Tue, Ju= n 30, 2009 at 10:19 AM, Loa Andersson <loa@pi.nu> wrote:
All,

we have an individual draft, draft-andersson-mpls-tp-process-03.txt,
that describes additions to the mpls working group process to allow
ITU-T to give input on MPLS-TP Internet Drafts.

It pretty much captures current practice, and from the start we had no
intention to ever progress, but recently there has been comments that
it would have a better and clearer sttus if it were a working group
document.

We have had no plans to ever make it an RFC, but it has been pointed
out that it would be possible to publish as an Historical RFC. Whether
we execute on that or not is not yet decided.

Therefore, is is to start at two week poll on making
draft-andersson-mpls-tp-process-03.txt an MPLS working group document.

The poll ends on July 14.

Please send your comments to the mpls-tp list.

Please





--


Loa Andersson

Sr Strategy and Standards Manager =A0 =A0phone: =A0+46 10 717 52 13
Ericsson /// =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 +46 767 72 92 13

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 em= ail: =A0loa= .andersson@ericsson.com
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 loa@pi.nu
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--001485f040a4c44372046dbb1822-- From liu.guoman@zte.com.cn Thu Jul 2 21:27:06 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515723A6807 for ; Thu, 2 Jul 2009 21:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.661 X-Spam-Level: X-Spam-Status: No, score=-95.661 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HQgJBgPoa+B for ; Thu, 2 Jul 2009 21:27:05 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 90FEA3A67EA for ; Thu, 2 Jul 2009 21:27:04 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Fri, 3 Jul 2009 12:11:12 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.100] with StormMail ESMTP id 74177.1397396305; Fri, 3 Jul 2009 12:20:54 +0800 (CST) To: "pwe3@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 3 Jul 2009 12:27:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-03 12:27:19, Serialize complete at 2009-07-03 12:27:19 Content-Type: multipart/related; boundary="=_related 001879F6482575E8_=" Subject: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 04:27:06 -0000 This is a multipart message in MIME format. --=_related 001879F6482575E8_= Content-Type: multipart/alternative; boundary="=_alternative 001879F6482575E8_=" --=_alternative 001879F6482575E8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksYWxsDQogZm9yIHRoZSBkcmFmdCxJIGhhdmUgYSBxdWVzdGlvbiBvZiBmbG93IGxhYmVsLiBm b3IgZXhhbXBsZSAgdGhlcmUgaXMgYSANCnNpdHVhdGlvbiBhcyB0aGUgZm9sbG93aW5nIDogDQog DQphY2NvcmRpbmcgdGhlIHNvbHV0aW9ucyBpbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBhIGdyZWF0 IHRyYWZmaWMgQUMxICx3aGljaCANCm1heSBiZSB0cmFuc3BvcnRlZCBpbiB0d28gcHcgcGF0aCwg ZS5nLiBQVzEsUFcyLiBhbmQgYXQgcmVzb3VyY2UgYW5kIHNpbmsgDQpwb2ludHMsIHRoZXJlIGlz IHRoZSBzYW1lIGZsb3cgbGFiZWwgLiBub3cgd2Ugc3VwcG9zZWQgdGhlcmUgaXMgYW5vdGhlciAN CnRyYWZmaWMgQUMyICx3aGljaCBtYXkgYmUgdHJhbnNwb3J0ZWQgYnkgZW5jYXBzdWxhdGlvbiBp biBwdzMuIA0KDQpxdWVzdGlvbjogaWYgIHB3MyBsYWJlbCBpcyB0aGUgc2FtZSBBQzEgZmxvdyBs YWJlbC4gaG93IHRvIGRpc3Rpbmd1aXNoIA0KdGhlbSB2ZXJ5IHdlbGwuIHdoZXRoZXIgQUMxIHNl cnZpY2UgcGFja2V0cyBtYXkgYmUgd3JvbmcgcmVnYXJkZWQgYXMgQUMyIA0Kc2VydmljZXMgcGFj a2V0cy4NCiANCg0KYmVzdCByZWdhcmRzDQpsaXUNCg0KDQoNCg0KDQoNCg0KSW50ZXJuZXQtRHJh ZnRzQGlldGYub3JnIA0Kt6K8/sjLOiAgcHdlMy1ib3VuY2VzQGlldGYub3JnDQoyMDA5LTA3LTAy IDE2OjE1DQoNCsrVvP7Iyw0KaS1kLWFubm91bmNlQGlldGYub3JnDQqzrcvNDQpwd2UzQGlldGYu b3JnDQrW98ziDQpbUFdFM10gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXB3ZTMtZmF0LXB3LTAwLnR4 dA0KDQoNCg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVkZ2UgV29ya2lu ZyANCkdyb3VwIG9mIHRoZSBJRVRGLg0KDQoNCiAgICAgICAgICAgICAgICAgVGl0bGUgICAgICAg ICAgIDogRmxvdyBBd2FyZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMgDQpvdmVyIGFuIE1QTFMg UFNODQogICAgICAgICAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IFMuIEJyeWFudCwgZXQgYWwu DQogICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcHdlMy1mYXQt cHctMDAudHh0DQogICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE4DQogICAgICAg ICAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMDktMDctMDENCg0KV2hlcmUgdGhlIHBheWxv YWQgY2FycmllZCBvdmVyIGEgcHNldWRvd2lyZSBjYXJyaWVzIGEgbnVtYmVyIG9mDQppZGVudGlm aWFibGUgZmxvd3MgaXQgY2FuIGluIHNvbWUgY2lyY3Vtc3RhbmNlcyBiZSBkZXNpcmFibGUgdG8g Y2FycnkNCnRob3NlIGZsb3dzIG92ZXIgdGhlIGVxdWFsIGNvc3QgbXVsdGlwbGUgcGF0aHMgKEVD TVBzKSB0aGF0IGV4aXN0IGluDQp0aGUgcGFja2V0IHN3aXRjaGVkIG5ldHdvcmsuICBNb3N0IGZv cndhcmRpbmcgZW5naW5lcyBhcmUgYWJsZSB0bw0KaGFzaCBiYXNlZCBvbiBsYWJlbCBzdGFja3Mg YW5kIHVzZSB0aGlzIHRvIGJhbGFuY2UgZmxvd3Mgb3ZlciBFQ01Qcy4NClRoaXMgZHJhZnQgZGVz Y3JpYmVzIGEgbWV0aG9kIG9mIGlkZW50aWZ5aW5nIHRoZSBmbG93cywgb3IgZmxvdw0KZ3JvdXBz LCB0byB0aGUgbGFiZWwgc3dpdGNoZWQgcm91dGVycyBieSBpbmNsdWRpbmcgYW4gYWRkaXRpb25h bA0KbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrLg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1E cmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt cHdlMy1mYXQtcHctMDAudHh0DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQg bWFpbCByZWFkZXINCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhl IEFTQ0lJIHZlcnNpb24gb2YgdGhlDQpJbnRlcm5ldC1EcmFmdC4NCmZ0cDovL2Fub255bW91c0Bm dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAudHh0 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBt YWlsaW5nIGxpc3QNCnB3ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHdlMw0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 001879F6482575E8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjx0YWJs ZT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLGFsbDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7Zm9yIHRoZSBkcmFmdCxJIGhhdmUgYSBx dWVzdGlvbg0Kb2YgZmxvdyBsYWJlbC4gZm9yIGV4YW1wbGUgJm5ic3A7dGhlcmUgaXMgYSBzaXR1 YXRpb24gYXMgdGhlIGZvbGxvd2luZw0KOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgPC9mb250PjxpbWcgc3JjPWNpZDpfMV8xMEIwOTFG NDEwQjA4RkNDMDAxODc5RjY0ODI1NzVFOD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+YWNjb3JkaW5nIHRoZSBzb2x1dGlvbnMgaW4gdGhpcyBkcmFmdCwNCnRoZXJlIGlzIGEg Z3JlYXQgdHJhZmZpYyBBQzEgJm5ic3A7LHdoaWNoIG1heSBiZSB0cmFuc3BvcnRlZCBpbiB0d28g cHcNCnBhdGgsIGUuZy4gUFcxLFBXMi4gYW5kIGF0IHJlc291cmNlIGFuZCBzaW5rIHBvaW50cywg dGhlcmUgaXMgdGhlIHNhbWUNCmZsb3cgbGFiZWwgLiBub3cgd2Ugc3VwcG9zZWQgdGhlcmUgaXMg YW5vdGhlciB0cmFmZmljIEFDMiAsd2hpY2ggbWF5IGJlDQp0cmFuc3BvcnRlZCBieSBlbmNhcHN1 bGF0aW9uIGluIHB3My4gJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5xdWVzdGlvbjogaWYgJm5ic3A7cHczIGxhYmVsIGlzIHRoZQ0Kc2FtZSBB QzEgZmxvdyBsYWJlbC4gaG93IHRvIGRpc3Rpbmd1aXNoIHRoZW0gdmVyeSB3ZWxsLiB3aGV0aGVy IEFDMSBzZXJ2aWNlDQpwYWNrZXRzIG1heSBiZSB3cm9uZyByZWdhcmRlZCBhcyBBQzIgc2Vydmlj ZXMgcGFja2V0cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJl c3QgcmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1 PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9k aXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5JbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7cHdlMy1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDkt MDctMDIgMTY6MTU8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+aS1kLWFubm91bmNlQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5wd2Uz QGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bUFdFM10gSS1EIEFjdGlvbjpkcmFmdC1pZXRm LXB3ZTMtZmF0LXB3LTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9Mj48dHQ+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUNCkludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQpUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVk Z2UgV29ya2luZw0KR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KPGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRpdGxlICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGbG93IEF3YXJlIFRyYW5zcG9ydCBv ZiBQc2V1ZG93aXJlcw0Kb3ZlciBhbiBNUExTIFBTTjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpBdXRob3IocykgJm5ic3A7ICZu YnNwOyAmbmJzcDsgOiBTLiBCcnlhbnQsIGV0IGFsLjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpGaWxlbmFtZSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAudHh0PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBh Z2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxODxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpEYXRlICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDA5LTA3LTAxPGJyPg0K PGJyPg0KV2hlcmUgdGhlIHBheWxvYWQgY2FycmllZCBvdmVyIGEgcHNldWRvd2lyZSBjYXJyaWVz IGEgbnVtYmVyIG9mPGJyPg0KaWRlbnRpZmlhYmxlIGZsb3dzIGl0IGNhbiBpbiBzb21lIGNpcmN1 bXN0YW5jZXMgYmUgZGVzaXJhYmxlIHRvIGNhcnJ5PGJyPg0KdGhvc2UgZmxvd3Mgb3ZlciB0aGUg ZXF1YWwgY29zdCBtdWx0aXBsZSBwYXRocyAoRUNNUHMpIHRoYXQgZXhpc3QgaW48YnI+DQp0aGUg cGFja2V0IHN3aXRjaGVkIG5ldHdvcmsuICZuYnNwO01vc3QgZm9yd2FyZGluZyBlbmdpbmVzIGFy ZSBhYmxlIHRvPGJyPg0KaGFzaCBiYXNlZCBvbiBsYWJlbCBzdGFja3MgYW5kIHVzZSB0aGlzIHRv IGJhbGFuY2UgZmxvd3Mgb3ZlciBFQ01Qcy48YnI+DQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIG1l dGhvZCBvZiBpZGVudGlmeWluZyB0aGUgZmxvd3MsIG9yIGZsb3c8YnI+DQpncm91cHMsIHRvIHRo ZSBsYWJlbCBzd2l0Y2hlZCByb3V0ZXJzIGJ5IGluY2x1ZGluZyBhbiBhZGRpdGlvbmFsPGJyPg0K bGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNrLjxicj4NCjxicj4NCkEgVVJMIGZvciB0aGlzIEludGVy bmV0LURyYWZ0IGlzOjxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtcHdlMy1mYXQtcHctMDAudHh0PGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0KPGJyPg0KQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2gg d2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjxicj4NCmltcGxlbWVudGF0 aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlPGJy Pg0KSW50ZXJuZXQtRHJhZnQuPGJyPg0KPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPmZ0cDovL2Fub255bW91c0BmdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtcHdlMy1mYXQtcHctMDAudHh0PC9mb250Pjxmb250IHNpemU9Mj48dHQ+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwd2UzIG1haWxp bmcgbGlzdDxicj4NCnB3ZTNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3B3ZTM8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5i c3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWls Jm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21t dW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNw O25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21h aW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1p dHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMm bmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQm bmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJz cDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJz cDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lv dSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5i c3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9y Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7 ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Ro b3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZu YnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNw O3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNw YW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001879F6482575E8_=-- --=_related 001879F6482575E8_= Content-Type: image/gif Content-ID: <_1_10B091F410B08FCC001879F6482575E8> Content-Transfer-Encoding: base64 R0lGODlhNQICAecAAP///wAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAANQICAUAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKhRlAIIJgWQtOlAAVCP0gxAtarVq1izar0qtatXgwFOhv16EurSgk6f mj1LVuXYkm/byh0ad2TduXjzNrwbkq9eomuXsjU4mKVfjFUJHv7LWO9dqh8XgzwrGK3SxnMlA4CM GLPnxpodck4Y+rNpuwNHRz59kW3ltEwvs15NMvHs22Ilqn5YGrfvm73BBg/+uzhE4sfjIjfOfOXj 5QyhN5+uODf161OtY98uWjv37269g/8fX92kdPLoj4tPD/58RPfs4yOEz1s+efrd7evvbH7/d/x7 +SfgRABGNyBLsA1W2VPr9cVdYII5FZVAax04X4MbFRaYWhNa+FKBC4EoV2EUxsbgiR6mhiFGlKHY IoopOrdijBaKSBqNxtl4IY486rgjj7f5CBaQOApZ0G5EfmZkeUl6uKSKTbL2pEBTRolZlVVaOROW Wh7IZZeefQnmfmKO+VeZNSFpZpozrukVmm7GKeecdNZp55145qnnnnz26eefgAYq6KCEFmrooYgm quiijDbqqKNwkkdiVB2W6GWbj6YUaaZtbYpngpbB2JKnnL6J6UegJkTin+fZZmCpeQ3/J12WsO6o Jke01nrqRZDlqiuTP/KH3qqwiTogiLf6+iuVGmmm7LIO7uXes7+SCq1Q1l5LG1zamtpft7tmRC24 zYZLLq/mnmtTtuoKW1u7RLELb0Xyzpvdt/Z6VG++Me1r54YmIrSqSP6eBnBsxTI18KX4epSqQgsT WjC/o6ZL8avcXszTxBoHi1rHOmE5Lqwcg9zwxyZbVHLKKL/LMr0Wv+xyxjLrFnPN0dKMc30n71xx zz4rtHLQ5QJN9NFIJ6300kw37fTTUEct9dRUV2311VhnrfXWXHft9ddghy322GTf6VqJCUec3tAp sz0bsQEbq5/bINO9td0a45213kBq/1ih3OEZXbbHBCMYqqVmFffwQWrr3Netgx8UFuQb+bo4Yb+9 GLCC/VYO+chBS0a5ekhR2mHiHFYKKHGj3xh5gBS1DizUfMn+3uuwd4Qk6Epu5fvvwAcv/PBcOf4d hBRKSBnqDBvvdO0i8v7TwRIy7uTjsz9dmu2uDytw3Gc3r7KzVLfam/Q4I8d99s/r7hf6NS+2fojl wzX/2sTnr//+/Pe//2ZGgh+kbhY2vvHLgFZDoL0UWD/BLY2BU4NguyQYNQqey4LaI+DLMNg+ByqN g00DobZE+EANsoyEHzRh21TYNRQuy4VIg6GA/Ma8v3kQV7jD2MwIdTnrsTA/2wlf9f8sRcQYKfBy Cyrig1zERMBta4fXgdvAGmcfBAJsYVQUlAyJtkWS/fBuX8xbGPc2Rop10WdYgpAa18jGNrrxjXBU nZvOuLMsCZBRdEyfWO64qDzGr4wHBGQCBblAQjbQeSE0ZAQVOUFGVtCRF4RkBm8YQ0l2EJFM86PM NNkoTp7Qkt3yJAA7JkpFifJ+LwTlCFX5QP/pL4ewjKUsZ0nLWtrylrjMpS53ycte+vKXwAymMIdJ zGIa85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685uKu6LyZANOWAoRYYcTUCkT5cpX yod66CSnOlkJrXXmRIqYE1/LaEf/T6ngM53+seehBHoxghbKoIGk5NEQmi+GarGflVQoFyG6UHrS sFJZ/AvnTsQ8lzh0XiREojxv08ORGmaP7UypSlfK0pa69KUwzYpEOVJSJ36mpko8KcHGwscVUgmV QCzL37CYOY6mM6M585zkdPk+oBKOJJrTXE5Nk7gaYtSGOuUV+XIZGlfF7pDJYR1TdXO/nppSNE7d zFjH11WwHimtR1prs5IFVq/ikKuPe4tZEWUVTMZySnBdYWB1OJ5zLg6p3BFZTBfbPy3VZbBLTY9h 42bSudmFp25VTIH2apNJNUVDKbLR7jIrHHGx5582texchUZa0sxKsnKMZ/KwGlCt/waVnwQSK14J ZLNF2pawtZQVzHwrLvnJ1bWmJS6uHnNczequtUpV625/mlTc2o+x2M0u/3ok3X1O0q+w/OjqKDrR maKRvKFDb6nE20jz1lG973WvHuUrNvb6yb6RpO8m4Ttf8CYNv+QC8J4EHEr+PorAq9TvBg28XwV/ 0sFeQzCeJFxPBnfSwg/2b0Q1/DoK28nD1cJwH0VsMhDTycS1QrGcVLxeErPTxaSE8UBlXFAaH9TG CeVweXU8OBbPEccNBfJ0Noq4yoLEx5lCMl5wauQnenfIshki+LgLYYgdtYiIJenmFpJllQk5JZOd FJCOuGWGdNlgRiXnmb1cZb14Vv9hPiwSIZlM2QeZbnmuORgUC7dE64Vvqvrks8PS3MQDf1moYlZQ R40IyKqe7qq05euh28vj87YZjJcWY6bJuGkzTlpdSh5TqC/c6SDG8dSoTrWq3WiSVbv61bCOtaxn Teta27rWlY5vrsc26i71esSf5tOvzxrsARcbXCJT7pNnmWypDfvF5uGsoZ4t6VIH2dpVo3aStD3t Y+uJ2zfGNki9neBd/1Hcyhb0I9HtbHJP2N0VZjeo4Z1KeefX3AWkd53ALTF9n9jfKQb4igXeYnsH mOCc4recDX7JPTd82bJUOI0kHiiKhxbhSca4mU4pbTBZ/HoMf0/Hfa1xUZec1Pg7XnDIM3lykq+8 nKHULmRhTvOa2/zmOM+5znfO8577/OdAD7rQh070ohv96EhPutKXzvSmO/3pUL9JQAAAOw== --=_related 001879F6482575E8_=-- From stbryant@cisco.com Fri Jul 3 00:21:17 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11BF3A6B71 for ; Fri, 3 Jul 2009 00:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.582 X-Spam-Level: X-Spam-Status: No, score=-8.582 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_51=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8-0s0OqS554 for ; Fri, 3 Jul 2009 00:21:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 533813A6801 for ; Fri, 3 Jul 2009 00:18:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,339,1243814400"; d="scan'208,217,147";a="44271965" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 07:19:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n637JBxU021476; Fri, 3 Jul 2009 09:19:11 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n637JBvV027731; Fri, 3 Jul 2009 07:19:11 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n637J9D25698; Fri, 3 Jul 2009 08:19:10 +0100 (BST) Message-ID: <4A4DB0ED.3020605@cisco.com> Date: Fri, 03 Jul 2009 08:19:09 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040308010008050907070202" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17388; t=1246605551; x=1247469551; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20a=20question=20of=20draft-ietf -pwe3-fat-pw-00 |Sender:=20; bh=GZ2yE+QuQCXG8fZlSwD6IsPrKGE2P8h2PVvs96f1bBY=; b=ALfi2jEKDIYN6vdWdCj5UgNgfybEgb9h1CNsQl3CxMG1R6jg+D/36tejsl 7GDVXgP+ms1Nl1YVE/rWuPn81y0ZkYlQaBwrwNsccQzCoJrxLm/p38pPp0FO 52Lf1+sPPB; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "pwe3@ietf.org" Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 07:21:17 -0000 This is a multi-part message in MIME format. --------------040308010008050907070202 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Liu There is only one PW between the AC1 pair (PW1). There are however multiple LSPs over which the PW1 could have been routed due to ECMP (remember this is hop by hop forwarding in an LDP environment in which the routes are inherited from the IGP). What the draft does is to spread the PW1 traffic over those paths in a way that does not damage the user traffic. PW2 does not exist. There is a statistical chance that PW3 will be co-routed, but that is what happens in a hop by hop system. PW1 pkts are distinguished from PW3 pkts by their PW labels which are always present. The flow label is an additional label. - Stewart liu.guoman@zte.com.cn wrote: > > > > > > > hi,all > for the draft,I have a question of flow label. for example there is a > situation as the following : > > according the solutions in this draft, there is a great traffic AC1 > ,which may be transported in two pw path, e.g. PW1,PW2. and at > resource and sink points, there is the same flow label . now we > supposed there is another traffic AC2 ,which may be transported by > encapsulation in pw3. > > question: if pw3 label is the same AC1 flow label. how to distinguish > them very well. whether AC1 service packets may be wrong regarded as > AC2 services packets. > > > best regards > liu > > > > > > > > *Internet-Drafts@ietf.org* > ·¢¼þÈË: pwe3-bounces@ietf.org > > 2009-07-02 16:15 > > > ÊÕ¼þÈË > i-d-announce@ietf.org > ³­ËÍ > pwe3@ietf.org > Ö÷Ìâ > [PWE3] I-D Action:draft-ietf-pwe3-fat-pw-00.txt > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Pseudowire Emulation Edge to Edge > Working Group of the IETF. > > > Title : Flow Aware Transport of Pseudowires over an MPLS PSN > Author(s) : S. Bryant, et al. > Filename : draft-ietf-pwe3-fat-pw-00.txt > Pages : 18 > Date : 2009-07-01 > > Where the payload carried over a pseudowire carries a number of > identifiable flows it can in some circumstances be desirable to carry > those flows over the equal cost multiple paths (ECMPs) that exist in > the packet switched network. Most forwarding engines are able to > hash based on label stacks and use this to balance flows over ECMPs. > This draft describes a method of identifying the flows, or flow > groups, to the label switched routers by including an additional > label in the label stack. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt_______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > -------------------------------------------------------- > ZTEInformationSecurityNotice:Theinformationcontainedinthismailissolelypropertyofthesender'sorganization.Thismailcommunicationisconfidential.Recipientsnamedaboveareobligatedtomaintainsecrecyandarenotpermittedtodisclosethecontentsofthiscommunicationtoothers. > Thisemailandanyfilestransmittedwithitareconfidentialandintendedsolelyfortheuseoftheindividualorentitytowhomtheyareaddressed.Ifyouhavereceivedthisemailinerrorpleasenotifytheoriginatorofthemessage.Anyviewsexpressedinthismessagearethoseoftheindividualsender. > ThismessagehasbeenscannedforvirusesandSpambyZTEAnti-Spamsystem. > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --------------040308010008050907070202 Content-Type: multipart/related; boundary="------------050408050602050403070707" --------------050408050602050403070707 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Liu

There is only one PW between the AC1 pair (PW1).

There are however multiple LSPs over which the PW1 could have been
routed due to ECMP (remember this is hop by hop forwarding
in an LDP environment in which the routes are inherited from the IGP).
What the draft does is to spread the PW1 traffic over those
paths in a way that does not damage the user traffic.

PW2 does not exist.

There is a statistical chance that PW3 will be co-routed, but that
is what happens in a hop by hop system.

PW1 pkts are distinguished from PW3 pkts by their PW
labels which are always present. The flow label is an
additional label.

- Stewart


liu.guoman@zte.com.cn wrote:





hi,all
 for the draft,I have a question of flow label. for example  there is a situation as the following :
   
according the solutions in this draft, there is a great traffic AC1  ,which may be transported in two pw path, e.g. PW1,PW2. and at resource and sink points, there is the same flow label . now we supposed there is another traffic AC2 ,which may be transported by encapsulation in pw3.  

question: if  pw3 label is the same AC1 flow label. how to distinguish them very well. whether AC1 service packets may be wrong regarded as AC2 services packets.
 

best regards
liu






Internet-Drafts@ietf.org
·¢¼þÈË:  pwe3-bounces@ietf.org

2009-07-02 16:15

ÊÕ¼þÈË
 i-d-announce@ietf.org
³­ËÍ
 pwe3@ietf.org
Ö÷Ìâ
 [PWE3] I-D Action:draft-ietf-pwe3-fat-pw-00.txt







A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF.


                Title           : Flow Aware Transport of Pseudowires over an MPLS PSN
                Author(s)       : S. Bryant, et al.
                Filename        : draft-ietf-pwe3-fat-pw-00.txt
                Pages           : 18
                Date            : 2009-07-01

Where the payload carried over a pseudowire carries a number of
identifiable flows it can in some circumstances be desirable to carry
those flows over the equal cost multiple paths (ECMPs) that exist in
the packet switched network.  Most forwarding engines are able to
hash based on label stacks and use this to balance flows over ECMPs.
This draft describes a method of identifying the flows, or flow
groups, to the label switched routers by including an additional
label in the label stack.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-pwe3-fat-pw-00.txt_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
  

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

--------------050408050602050403070707 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhNQICAecAAP///wAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAANQICAUAI/wABCBxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKhRlAIIJgWQtOlAAVCP0gxAtarVq1izar0qtatXgwFOhv16EurSgk6fmj1LVuXY km/byh0ad2TduXjzNrwbkq9eomuXsjU4mKVfjFUJHv7LWO9dqh8XgzwrGK3SxnMlA4CMGLPn xpodck4Y+rNpuwNHRz59kW3ltEwvs15NMvHs22Ilqn5YGrfvm73BBg/+uzhE4sfjIjfOfOXj 5QyhN5+uODf161OtY98uWjv37269g/8fX92kdPLoj4tPD/58RPfs4yOEz1s+efrd7evvbH7/ d/x7+SfgRABGNyBLsA1W2VPr9cVdYII5FZVAax04X4MbFRaYWhNa+FKBC4EoV2EUxsbgiR6m hiFGlKHYIoopOrdijBaKSBqNxtl4IY486rgjj7f5CBaQOApZ0G5EfmZkeUl6uKSKTbL2pEBT RolZlVVaOROWWh7IZZeefQnmfmKO+VeZNSFpZpozrukVmm7GKeecdNZp55145qnnnnz26eef gAYq6KCEFmrooYgmquiijDbqqKNwkkdiVB2W6GWbj6YUaaZtbYpngpbB2JKnnL6J6UegJkTi n+fZZmCpeQ3/J12WsO6oJke01nrqRZDlqiuTP/KH3qqwiTogiLf6+iuVGmmm7LIO7uXes7+S Cq1Q1l5LG1zamtpft7tmRC24zYZLLq/mnmtTtuoKW1u7RLELb0Xyzpvdt/Z6VG++Me1r54Ym IrSqSP6eBnBsxTI18KX4epSqQgsTWjC/o6ZL8avcXszTxBoHi1rHOmE5Lqwcg9zwxyZbVHLK KL/LMr0Wv+xyxjLrFnPN0dKMc30n71xxzz4rtHLQ5QJN9NFIJ6300kw37fTTUEct9dRUV231 1VhnrfXWXHft9ddghy322GTf6VqJCUec3tApsz0bsQEbq5/bINO9td0a45213kBq/1ih3OEZ XbbHBCMYqqVmFffwQWrr3Netgx8UFuQb+bo4Yb+9GLCC/VYO+chBS0a5ekhR2mHiHFYKKHGj 3xh5gBS1DizUfMn+3uuwd4Qk6Epu5fvvwAcv/PBcOf4dhBRKSBnqDBvvdO0i8v7TwRIy7uTj sz9dmu2uDytw3Gc3r7KzVLfam/Q4I8d99s/r7hf6NS+2fojlwzX/2sTnr//+/Pe//2ZGgh+k bhY2vvHLgFZDoL0UWD/BLY2BU4NguyQYNQqey4LaI+DLMNg+ByqNg00DobZE+EANsoyEHzRh 21TYNRQuy4VIg6GA/Ma8v3kQV7jD2MwIdTnrsTA/2wlf9f8sRcQYKfByCyrig1zERMBta4fX gdvAGmcfBAJsYVQUlAyJtkWS/fBuX8xbGPc2Rop10WdYgpAa18jGNrrxjXBUnZvOuLMsCZBR dEyfWO64qDzGr4wHBGQCBblAQjbQeSE0ZAQVOUFGVtCRF4RkBm8YQ0l2EJFM86PMNNkoTp7Q kt3yJAA7JkpFifJ+LwTlCFX5QP/pL4ewjKUsZ0nLWtrylrjMpS53ycte+vKXwAymMIdJzGIa 85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685uKu6LyZANOWAoRYYcTUCkT5cpX yod66CSnOlkJrXXmRIqYE1/LaEf/T6ngM53+seehBHoxghbKoIGk5NEQmi+GarGflVQoFyG6 UHrSsFJZ/AvnTsQ8lzh0XiREojxv08ORGmaP7UypSlfK0pa69KUwzYpEOVJSJ36mpko8KcHG wscVUgmVQCzL37CYOY6mM6M585zkdPk+oBKOJJrTXE5Nk7gaYtSGOuUV+XIZGlfF7pDJYR1T dXO/nppSNE7dzFjH11WwHimtR1prs5IFVq/ikKuPe4tZEWUVTMZySnBdYWB1OJ5zLg6p3BFZ TBfbPy3VZbBLTY9h42bSudmFp25VTIH2apNJNUVDKbLR7jIrHHGx5582texchUZa0sxKsnKM Z/KwGlCt/waVnwQSK14JZLNF2pawtZQVzHwrLvnJ1bWmJS6uHnNczequtUpV625/mlTc2o+x 2M0u/3ok3X1O0q+w/OjqKDrRmaKRvKFDb6nE20jz1lG973WvHuUrNvb6yb6RpO8m4Ttf8CYN v+QC8J4EHEr+PorAq9TvBg28XwV/0sFeQzCeJFxPBnfSwg/2b0Q1/DoK28nD1cJwH0VsMhDT ycS1QrGcVLxeErPTxaSE8UBlXFAaH9TGCeVweXU8OBbPEccNBfJ0Noq4yoLEx5lCMl5wauQn enfIshki+LgLYYgdtYiIJenmFpJllQk5JZOdFJCOuGWGdNlgRiXnmb1cZb14Vv9hPiwSIZlM 2QeZbnmuORgUC7dE64Vvqvrks8PS3MQDf1moYlZQR40IyKqe7qq05euh28vj87YZjJcWY6bJ uGkzTlpdSh5TqC/c6SDG8dSoTrWq3WiSVbv61bCOtaxnTeta27rWlY5vrsc26i71esSf5tOv zxrsARcbXCJT7pNnmWypDfvF5uGsoZ4t6VIH2dpVo3aStD3tY+uJ2zfGNki9neBd/1Hcyhb0 I9HtbHJP2N0VZjeo4Z1KeefX3AWkd53ALTF9n9jfKQb4igXeYnsHmOCc4recDX7JPTd82bJU OI0kHiiKhxbhSca4mU4pbTBZ/HoMf0/Hfa1xUZec1Pg7XnDIM3lykq+8nKHULmRhTvOa2/zm OM+5znfO8577/OdAD7rQh070ohv96EhPutKXzvSmO/3pUL9JQAAAOw== --------------050408050602050403070707-- --------------040308010008050907070202-- From liu.guoman@zte.com.cn Fri Jul 3 00:59:33 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080D73A6C3E for ; Fri, 3 Jul 2009 00:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGdCTBtmhMP1 for ; Fri, 3 Jul 2009 00:59:31 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id A176E3A6CB1 for ; Fri, 3 Jul 2009 00:59:05 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101397396305; Fri, 3 Jul 2009 15:47:12 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.99] with StormMail ESMTP id 92379.3171924358; Fri, 3 Jul 2009 15:45:26 +0800 (CST) In-Reply-To: <4A4DB0ED.3020605@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 3 Jul 2009 15:46:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-03 15:52:26, Serialize complete at 2009-07-03 15:52:26 Content-Type: multipart/related; boundary="=_related 002AAEA9482575E8_=" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 07:59:33 -0000 This is a multipart message in MIME format. --=_related 002AAEA9482575E8_= Content-Type: multipart/alternative; boundary="=_alternative 002AAEA9482575E8_=" --=_alternative 002AAEA9482575E8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3Rld2FydKO6IA0KICBhY2NvcmRpbmcgdG8geW91ciBhbnN3ZXIsICBJIGhhdmUgYSBmZXcgICBj b21tZW50czoNCiAgIDEgaG93ICB0byBlbnN1cmUgdGhlIHNhbWUgcHcgbGFiZWwgaW4gbXVsdGlw bGUgTFNQcyA/ICBpdCBzYXlzLCBtYXliZSANCnRoaXMgcHcgbGFiZWwgdXNlZCBmb3IgQUMgc2Vy dmljZSwgaGF2ZSBiZWVuIGFzc2lnbmVkIHRvIGFub3RoZXIgQUMgDQpzZXJ2aWNlIGluIGEgTFNQ IG9mIHRoZSBtdWx0aXBsZSBMU1BzLg0KDQogICAyIGZvciBzaW5rIHBvaW50cy4gSU1PICwgZmxv dyBsYWJlbCBhbmQgcHcgbGFiZWwgY2FuJ3QgYmUgZGlzdGluZ3Vpc2hlZCANCm9ubHkgYnkgTGFi ZWwgU3RhY2sgTGV2ZWwuIGl0IHNheXMgLCB0aGVyZSBpcyBhICBwb3NzaWJpbGl0eSB0byByZWdh cmRzIA0KdGhlIGZsb3cgDQogICBsYWJlbCBhcyBhbm90aGVyIHB3IGxhYmVsICxzbyBpdCAgcHJv Y2Vzc2VkICB0aGlzIGZsb3cgbGFiZWwgYnkgDQptaXN0YWtlcy4NCg0KDQogIGJlc3QgcmVnYXJk cw0KICBsaXUNCiANCg0KDQoNClN0ZXdhcnQgQnJ5YW50IDxzdGJyeWFudEBjaXNjby5jb20+IA0K MjAwOS0wNy0wMyAxNToxOQ0Kx+u08Li0ILj4DQpzdGJyeWFudEBjaXNjby5jb20NCg0KDQrK1bz+ yMsNCmxpdS5ndW9tYW5AenRlLmNvbS5jbg0Ks63LzQ0KInB3ZTNAaWV0Zi5vcmciIDxwd2UzQGll dGYub3JnPg0K1vfM4g0KUmU6IFtQV0UzXSBhIHF1ZXN0aW9uIG9mIGRyYWZ0LWlldGYtcHdlMy1m YXQtcHctMDANCg0KDQoNCg0KDQoNCkxpdQ0KDQpUaGVyZSBpcyBvbmx5IG9uZSBQVyBiZXR3ZWVu IHRoZSBBQzEgcGFpciAoUFcxKS4NCg0KVGhlcmUgYXJlIGhvd2V2ZXIgbXVsdGlwbGUgTFNQcyBv dmVyIHdoaWNoIHRoZSBQVzEgY291bGQgaGF2ZSBiZWVuDQpyb3V0ZWQgZHVlIHRvIEVDTVAgKHJl bWVtYmVyIHRoaXMgaXMgaG9wIGJ5IGhvcCBmb3J3YXJkaW5nDQppbiBhbiBMRFAgZW52aXJvbm1l bnQgaW4gd2hpY2ggdGhlIHJvdXRlcyBhcmUgaW5oZXJpdGVkIGZyb20gdGhlIElHUCkuDQpXaGF0 IHRoZSBkcmFmdCBkb2VzIGlzIHRvIHNwcmVhZCB0aGUgUFcxIHRyYWZmaWMgb3ZlciB0aG9zZSAN CnBhdGhzIGluIGEgd2F5IHRoYXQgZG9lcyBub3QgZGFtYWdlIHRoZSB1c2VyIHRyYWZmaWMuIA0K DQpQVzIgZG9lcyBub3QgZXhpc3QuDQoNClRoZXJlIGlzIGEgc3RhdGlzdGljYWwgY2hhbmNlIHRo YXQgUFczIHdpbGwgYmUgY28tcm91dGVkLCBidXQgdGhhdA0KaXMgd2hhdCBoYXBwZW5zIGluIGEg aG9wIGJ5IGhvcCBzeXN0ZW0uDQoNClBXMSBwa3RzIGFyZSBkaXN0aW5ndWlzaGVkIGZyb20gUFcz IHBrdHMgYnkgdGhlaXIgUFcNCmxhYmVscyB3aGljaCBhcmUgYWx3YXlzIHByZXNlbnQuIFRoZSBm bG93IGxhYmVsIGlzIGFuDQphZGRpdGlvbmFsIGxhYmVsLg0KDQotIFN0ZXdhcnQNCg0KDQpsaXUu Z3VvbWFuQHp0ZS5jb20uY24gd3JvdGU6IA0KDQoNCg0KDQoNCmhpLGFsbCANCiBmb3IgdGhlIGRy YWZ0LEkgaGF2ZSBhIHF1ZXN0aW9uIG9mIGZsb3cgbGFiZWwuIGZvciBleGFtcGxlICB0aGVyZSBp cyBhIA0Kc2l0dWF0aW9uIGFzIHRoZSBmb2xsb3dpbmcgOiANCiAgICANCmFjY29yZGluZyB0aGUg c29sdXRpb25zIGluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGEgZ3JlYXQgdHJhZmZpYyBBQzEgLHdo aWNoIA0KbWF5IGJlIHRyYW5zcG9ydGVkIGluIHR3byBwdyBwYXRoLCBlLmcuIFBXMSxQVzIuIGFu ZCBhdCByZXNvdXJjZSBhbmQgc2luayANCnBvaW50cywgdGhlcmUgaXMgdGhlIHNhbWUgZmxvdyBs YWJlbCAuIG5vdyB3ZSBzdXBwb3NlZCB0aGVyZSBpcyBhbm90aGVyIA0KdHJhZmZpYyBBQzIgLHdo aWNoIG1heSBiZSB0cmFuc3BvcnRlZCBieSBlbmNhcHN1bGF0aW9uIGluIHB3My4gICANCg0KcXVl c3Rpb246IGlmICBwdzMgbGFiZWwgaXMgdGhlIHNhbWUgQUMxIGZsb3cgbGFiZWwuIGhvdyB0byBk aXN0aW5ndWlzaCANCnRoZW0gdmVyeSB3ZWxsLiB3aGV0aGVyIEFDMSBzZXJ2aWNlIHBhY2tldHMg bWF5IGJlIHdyb25nIHJlZ2FyZGVkIGFzIEFDMiANCnNlcnZpY2VzIHBhY2tldHMuIA0KICANCg0K YmVzdCByZWdhcmRzIA0KbGl1DQoNCg0KDQoNCg0KDQpJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcg DQq3orz+yMs6ICBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDA5LTA3LTAyIDE2OjE1IA0KDQoN CsrVvP7Iyw0KaS1kLWFubm91bmNlQGlldGYub3JnIA0Ks63LzQ0KcHdlM0BpZXRmLm9yZyANCtb3 zOINCltQV0UzXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAudHh0DQoNCg0K DQoNCg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBQc2V1ZG93aXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVkZ2UgV29ya2luZyAN Ckdyb3VwIG9mIHRoZSBJRVRGLg0KDQoNCiAgICAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAg OiBGbG93IEF3YXJlIFRyYW5zcG9ydCBvZiBQc2V1ZG93aXJlcyBvdmVyIA0KYW4gTVBMUyBQU04N CiAgICAgICAgICAgICAgICBBdXRob3IocykgICAgICAgOiBTLiBCcnlhbnQsIGV0IGFsLg0KICAg ICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAu dHh0DQogICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTgNCiAgICAgICAgICAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDA5LTA3LTAxDQoNCldoZXJlIHRoZSBwYXlsb2FkIGNhcnJp ZWQgb3ZlciBhIHBzZXVkb3dpcmUgY2FycmllcyBhIG51bWJlciBvZg0KaWRlbnRpZmlhYmxlIGZs b3dzIGl0IGNhbiBpbiBzb21lIGNpcmN1bXN0YW5jZXMgYmUgZGVzaXJhYmxlIHRvIGNhcnJ5DQp0 aG9zZSBmbG93cyBvdmVyIHRoZSBlcXVhbCBjb3N0IG11bHRpcGxlIHBhdGhzIChFQ01QcykgdGhh dCBleGlzdCBpbg0KdGhlIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrLiAgTW9zdCBmb3J3YXJkaW5n IGVuZ2luZXMgYXJlIGFibGUgdG8NCmhhc2ggYmFzZWQgb24gbGFiZWwgc3RhY2tzIGFuZCB1c2Ug dGhpcyB0byBiYWxhbmNlIGZsb3dzIG92ZXIgRUNNUHMuDQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyBh IG1ldGhvZCBvZiBpZGVudGlmeWluZyB0aGUgZmxvd3MsIG9yIGZsb3cNCmdyb3VwcywgdG8gdGhl IGxhYmVsIHN3aXRjaGVkIHJvdXRlcnMgYnkgaW5jbHVkaW5nIGFuIGFkZGl0aW9uYWwNCmxhYmVs IGluIHRoZSBsYWJlbCBzdGFjay4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6 DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXB3ZTMtZmF0 LXB3LTAwLnR4dA0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxv dyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVh ZGVyDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2 ZXJzaW9uIG9mIHRoZQ0KSW50ZXJuZXQtRHJhZnQuDQpmdHA6Ly9hbm9ueW1vdXNAZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXB3ZTMtZmF0LXB3LTAwLnR4dA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBs aXN0DQpwd2UzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3B3ZTMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNl bmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBv ZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFs IHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQogDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3ZTMNCiANCg0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 002AAEA9482575E8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXdhcnSjuiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBhY2NvcmRpbmcgdG8geW91 ciBhbnN3ZXIsICZuYnNwO0kNCmhhdmUgYSBmZXcgJm5ic3A7IGNvbW1lbnRzOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOzEgaG93ICZuYnNw O3RvIGVuc3VyZSB0aGUNCnNhbWUgcHcgbGFiZWwgaW4gbXVsdGlwbGUgTFNQcyA/ICZuYnNwO2l0 IHNheXMsIG1heWJlIHRoaXMgcHcgbGFiZWwgdXNlZA0KZm9yIEFDIHNlcnZpY2UsIGhhdmUgYmVl biBhc3NpZ25lZCB0byBhbm90aGVyIEFDIHNlcnZpY2UgaW4gYSBMU1Agb2YgdGhlDQptdWx0aXBs ZSBMU1BzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOzIgZm9yIHNpbmsgcG9pbnRzLiBJTU8NCiwgZmxvdyBsYWJlbCBhbmQgcHcg bGFiZWwgY2FuJ3QgYmUgZGlzdGluZ3Vpc2hlZCBvbmx5IGJ5IExhYmVsIFN0YWNrIExldmVsLg0K aXQgc2F5cyAsIHRoZXJlIGlzIGEgJm5ic3A7cG9zc2liaWxpdHkgdG8gcmVnYXJkcyB0aGUgZmxv dyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDtsYWJlbCBhcyBhbm90aGVyIHB3IGxhYmVsDQosc28gaXQgJm5ic3A7cHJvY2Vzc2VkICZuYnNw O3RoaXMgZmxvdyBsYWJlbCBieSBtaXN0YWtlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBiZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBsaXU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5TdGV3YXJ0IEJyeWFudCAmbHQ7c3Ri cnlhbnRAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4yMDA5LTA3LTAzIDE1OjE5PC9mb250Pg0KPHRhYmxlIGJvcmRlcj4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRlcj48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+x+u08Li0ILj4PGJyPg0Kc3RicnlhbnRAY2lzY28uY29t PC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+bGl1Lmd1b21hbkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mcXVvdDtwd2UzQGlldGYub3JnJnF1b3Q7ICZsdDtwd2UzQGlldGYub3JnJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+UmU6IFtQV0UzXSBhIHF1ZXN0aW9uIG9mIGRyYWZ0LWlldGYtcHdlMy1m YXQtcHctMDA8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+TGl1PGJyPg0KPGJyPg0KVGhlcmUgaXMgb25seSBvbmUg UFcgYmV0d2VlbiB0aGUgQUMxIHBhaXIgKFBXMSkuPGJyPg0KPGJyPg0KVGhlcmUgYXJlIGhvd2V2 ZXIgbXVsdGlwbGUgTFNQcyBvdmVyIHdoaWNoIHRoZSBQVzEgY291bGQgaGF2ZSBiZWVuPGJyPg0K cm91dGVkIGR1ZSB0byBFQ01QIChyZW1lbWJlciB0aGlzIGlzIGhvcCBieSBob3AgZm9yd2FyZGlu Zzxicj4NCmluIGFuIExEUCBlbnZpcm9ubWVudCBpbiB3aGljaCB0aGUgcm91dGVzIGFyZSBpbmhl cml0ZWQgZnJvbSB0aGUgSUdQKS48YnI+DQpXaGF0IHRoZSBkcmFmdCBkb2VzIGlzIHRvIHNwcmVh ZCB0aGUgUFcxIHRyYWZmaWMgb3ZlciB0aG9zZSA8YnI+DQpwYXRocyBpbiBhIHdheSB0aGF0IGRv ZXMgbm90IGRhbWFnZSB0aGUgdXNlciB0cmFmZmljLiA8YnI+DQo8YnI+DQpQVzIgZG9lcyBub3Qg ZXhpc3QuPGJyPg0KPGJyPg0KVGhlcmUgaXMgYSBzdGF0aXN0aWNhbCBjaGFuY2UgdGhhdCBQVzMg d2lsbCBiZSBjby1yb3V0ZWQsIGJ1dCB0aGF0PGJyPg0KaXMgd2hhdCBoYXBwZW5zIGluIGEgaG9w IGJ5IGhvcCBzeXN0ZW0uPGJyPg0KPGJyPg0KUFcxIHBrdHMgYXJlIGRpc3Rpbmd1aXNoZWQgZnJv bSBQVzMgcGt0cyBieSB0aGVpciBQVzxicj4NCmxhYmVscyB3aGljaCBhcmUgYWx3YXlzIHByZXNl bnQuIFRoZSBmbG93IGxhYmVsIGlzIGFuPGJyPg0KYWRkaXRpb25hbCBsYWJlbC48YnI+DQo8YnI+ DQotIFN0ZXdhcnQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzpsaXUuZ3Vv bWFuQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PHU+bGl1Lmd1b21hbkB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPg0Kd3JvdGU6IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQgd2lk dGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpoaSxhbGw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBmb3IgdGhl IGRyYWZ0LEkgaGF2ZSBhIHF1ZXN0aW9uIG9mIGZsb3cgbGFiZWwuIGZvciBleGFtcGxlICZuYnNw O3RoZXJlDQppcyBhIHNpdHVhdGlvbiBhcyB0aGUgZm9sbG93aW5nIDogPGJyPg0KICZuYnNwOyAm bmJzcDs8L2ZvbnQ+PGltZyBzcmM9Y2lkOl8xXzEwQkIyNDJDMTBCQTE5MkMwMDJBQUVBOTQ4MjU3 NUU4Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQphY2NvcmRpbmcgdGhlIHNv bHV0aW9ucyBpbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBhIGdyZWF0IHRyYWZmaWMgQUMxICZuYnNw Oyx3aGljaA0KbWF5IGJlIHRyYW5zcG9ydGVkIGluIHR3byBwdyBwYXRoLCBlLmcuIFBXMSxQVzIu IGFuZCBhdCByZXNvdXJjZSBhbmQgc2luaw0KcG9pbnRzLCB0aGVyZSBpcyB0aGUgc2FtZSBmbG93 IGxhYmVsIC4gbm93IHdlIHN1cHBvc2VkIHRoZXJlIGlzIGFub3RoZXINCnRyYWZmaWMgQUMyICx3 aGljaCBtYXkgYmUgdHJhbnNwb3J0ZWQgYnkgZW5jYXBzdWxhdGlvbiBpbiBwdzMuICZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCnF1ZXN0aW9uOiBpZiAmbmJzcDtwdzMgbGFi ZWwgaXMgdGhlIHNhbWUgQUMxIGZsb3cgbGFiZWwuIGhvdyB0byBkaXN0aW5ndWlzaA0KdGhlbSB2 ZXJ5IHdlbGwuIHdoZXRoZXIgQUMxIHNlcnZpY2UgcGFja2V0cyBtYXkgYmUgd3JvbmcgcmVnYXJk ZWQgYXMgQUMyDQpzZXJ2aWNlcyBwYWNrZXRzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZu YnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpiZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCmxpdTwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRk IHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGEgaHJlZj0ibWFpbHRvOkludGVy bmV0LURyYWZ0c0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+PHU+SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPC91PjwvYj48L2ZvbnQ+PC9hPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCreivP7IyzogJm5ic3A7PC9mb250 PjxhIGhyZWY9Im1haWx0bzpwd2UzLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnB3ZTMtYm91bmNlc0BpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTAyIDE2OjE1PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTExJT4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZCB3aWR0aD04OCU+PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9y ZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aS1kLWFubm91 bmNlQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxhIGhyZWY9 bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+cHdlM0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1BXRTNdIEktRCBBY3Rpb246ZHJhZnQt aWV0Zi1wd2UzLWZhdC1wdy0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRo PTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQc2V1 ZG93aXJlIEVtdWxhdGlvbiBFZGdlIHRvIEVkZ2UgV29ya2luZw0KR3JvdXAgb2YgdGhlIElFVEYu PGJyPg0KPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtUaXRsZSAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyA6IEZsb3cgQXdhcmUgVHJhbnNwb3J0IG9mIFBzZXVkb3dpcmVzIG92ZXIgYW4gTVBMUw0KUFNO PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtBdXRob3IocykgJm5ic3A7DQombmJzcDsgJm5ic3A7IDogUy4gQnJ5YW50LCBldCBhbC48 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0ZpbGVuYW1lICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtcHdl My1mYXQtcHctMDAudHh0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyA6IDE4PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtEYXRlICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzogMjAwOS0wNy0wMTxicj4NCjxicj4NCldoZXJlIHRoZSBwYXlsb2FkIGNhcnJpZWQgb3Zl ciBhIHBzZXVkb3dpcmUgY2FycmllcyBhIG51bWJlciBvZjxicj4NCmlkZW50aWZpYWJsZSBmbG93 cyBpdCBjYW4gaW4gc29tZSBjaXJjdW1zdGFuY2VzIGJlIGRlc2lyYWJsZSB0byBjYXJyeTxicj4N CnRob3NlIGZsb3dzIG92ZXIgdGhlIGVxdWFsIGNvc3QgbXVsdGlwbGUgcGF0aHMgKEVDTVBzKSB0 aGF0IGV4aXN0IGluPGJyPg0KdGhlIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3JrLiAmbmJzcDtNb3N0 IGZvcndhcmRpbmcgZW5naW5lcyBhcmUgYWJsZSB0bzxicj4NCmhhc2ggYmFzZWQgb24gbGFiZWwg c3RhY2tzIGFuZCB1c2UgdGhpcyB0byBiYWxhbmNlIGZsb3dzIG92ZXIgRUNNUHMuPGJyPg0KVGhp cyBkcmFmdCBkZXNjcmliZXMgYSBtZXRob2Qgb2YgaWRlbnRpZnlpbmcgdGhlIGZsb3dzLCBvciBm bG93PGJyPg0KZ3JvdXBzLCB0byB0aGUgbGFiZWwgc3dpdGNoZWQgcm91dGVycyBieSBpbmNsdWRp bmcgYW4gYWRkaXRpb25hbDxicj4NCmxhYmVsIGluIHRoZSBsYWJlbCBzdGFjay48YnI+DQo8YnI+ DQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8L3R0PjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZT48dHQ+PHU+PGJyPg0KPC91PjwvdHQ+PC9mb250PjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAu dHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wd2UzLWZhdC1wdy0wMC50eHQ8L3U+PC90dD48L2Zv bnQ+PC9hPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjwvdHQ+PC9mb250Pjxmb250IHNpemU9 MiBjb2xvcj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90dD48L2ZvbnQ+PGEgaHJlZj0iZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0 dD48dT5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvdT48L3R0PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQo8YnI+DQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3 aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyPGJyPg0KaW1wbGVtZW50YXRp b24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+ DQpJbnRlcm5ldC1EcmFmdC48L3R0PjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9ImZ0cDovL2Fub255bW91 c0BmdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcHdlMy1mYXQtcHctMDAu dHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5mdHA6Ly9h bm9ueW1vdXNAZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXB3ZTMtZmF0 LXB3LTAwLnR4dDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mj48dHQ+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwd2UzIG1haWxpbmcgbGlzdDwv dHQ+PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD48dT48YnI+DQo8L3U+PC90dD48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHdlM0BpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZT48dHQ+PHU+cHdlM0BpZXRmLm9yZzwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWU+PHR0Pjx1Pjxicj4NCjwvdT48L3R0PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48 dHQ+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPC91PjwvdHQ+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGln YXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KICZu YnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+PGJyPg0KPC90dD48L2ZvbnQ+ DQo8aHI+PGZvbnQgc2l6ZT0zPjx0dD48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KPC90dD48L2Zv bnQ+PGEgaHJlZj1tYWlsdG86cHdlM0BpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48 dHQ+PHU+cHdlM0BpZXRmLm9yZzwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD48 YnI+DQo8L3R0PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcHdlMz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzPC91PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+PHR0Pjxicj4NCiAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj4NCjxicj4NCjxicj48cHJlPg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhl Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt YWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtj b21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZu YnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNw O21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Bl cm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNw O29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRo aXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0 ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQm bmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8m bmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNw O3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2lu Jm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5h dG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5i c3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNw O3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZu YnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRp LVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002AAEA9482575E8_=-- --=_related 002AAEA9482575E8_= Content-Type: image/gif Content-ID: <_1_10BB242C10BA192C002AAEA9482575E8> Content-Transfer-Encoding: base64 R0lGODlhNQICAecAAP///wAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAANQICAUAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKhRlAIIJgWQtOlAAVCP0gxAtarVq1izar0qtatXgwFOhv16EurSgk6f mj1LVuXYkm/byh0ad2TduXjzNrwbkq9eomuXsjU4mKVfjFUJHv7LWO9dqh8XgzwrGK3SxnMlA4CM GLPnxpodck4Y+rNpuwNHRz59kW3ltEwvs15NMvHs22Ilqn5YGrfvm73BBg/+uzhE4sfjIjfOfOXj 5QyhN5+uODf161OtY98uWjv37269g/8fX92kdPLoj4tPD/58RPfs4yOEz1s+efrd7evvbH7/d/x7 +SfgRABGNyBLsA1W2VPr9cVdYII5FZVAax04X4MbFRaYWhNa+FKBC4EoV2EUxsbgiR6mhiFGlKHY IoopOrdijBaKSBqNxtl4IY486rgjj7f5CBaQOApZ0G5EfmZkeUl6uKSKTbL2pEBTRolZlVVaOROW Wh7IZZeefQnmfmKO+VeZNSFpZpozrukVmm7GKeecdNZp55145qnnnnz26eefgAYq6KCEFmrooYgm quiijDbqqKNwkkdiVB2W6GWbj6YUaaZtbYpngpbB2JKnnL6J6UegJkTin+fZZmCpeQ3/J12WsO6o Jke01nrqRZDlqiuTP/KH3qqwiTogiLf6+iuVGmmm7LIO7uXes7+SCq1Q1l5LG1zamtpft7tmRC24 zYZLLq/mnmtTtuoKW1u7RLELb0Xyzpvdt/Z6VG++Me1r54YmIrSqSP6eBnBsxTI18KX4epSqQgsT WjC/o6ZL8avcXszTxBoHi1rHOmE5Lqwcg9zwxyZbVHLKKL/LMr0Wv+xyxjLrFnPN0dKMc30n71xx zz4rtHLQ5QJN9NFIJ6300kw37fTTUEct9dRUV2311VhnrfXWXHft9ddghy322GTf6VqJCUec3tAp sz0bsQEbq5/bINO9td0a45213kBq/1ih3OEZXbbHBCMYqqVmFffwQWrr3Netgx8UFuQb+bo4Yb+9 GLCC/VYO+chBS0a5ekhR2mHiHFYKKHGj3xh5gBS1DizUfMn+3uuwd4Qk6Epu5fvvwAcv/PBcOf4d hBRKSBnqDBvvdO0i8v7TwRIy7uTjsz9dmu2uDytw3Gc3r7KzVLfam/Q4I8d99s/r7hf6NS+2fojl wzX/2sTnr//+/Pe//2ZGgh+kbhY2vvHLgFZDoL0UWD/BLY2BU4NguyQYNQqey4LaI+DLMNg+ByqN g00DobZE+EANsoyEHzRh21TYNRQuy4VIg6GA/Ma8v3kQV7jD2MwIdTnrsTA/2wlf9f8sRcQYKfBy Cyrig1zERMBta4fXgdvAGmcfBAJsYVQUlAyJtkWS/fBuX8xbGPc2Rop10WdYgpAa18jGNrrxjXBU nZvOuLMsCZBRdEyfWO64qDzGr4wHBGQCBblAQjbQeSE0ZAQVOUFGVtCRF4RkBm8YQ0l2EJFM86PM NNkoTp7Qkt3yJAA7JkpFifJ+LwTlCFX5QP/pL4ewjKUsZ0nLWtrylrjMpS53ycte+vKXwAymMIdJ zGIa85jITKYyl8nMZjrzmdCMpjSnSc1qWvOa2MymNrfJzW5685uKu6LyZANOWAoRYYcTUCkT5cpX yod66CSnOlkJrXXmRIqYE1/LaEf/T6ngM53+seehBHoxghbKoIGk5NEQmi+GarGflVQoFyG6UHrS sFJZ/AvnTsQ8lzh0XiREojxv08ORGmaP7UypSlfK0pa69KUwzYpEOVJSJ36mpko8KcHGwscVUgmV QCzL37CYOY6mM6M585zkdPk+oBKOJJrTXE5Nk7gaYtSGOuUV+XIZGlfF7pDJYR1TdXO/nppSNE7d zFjH11WwHimtR1prs5IFVq/ikKuPe4tZEWUVTMZySnBdYWB1OJ5zLg6p3BFZTBfbPy3VZbBLTY9h 42bSudmFp25VTIH2apNJNUVDKbLR7jIrHHGx5582texchUZa0sxKsnKMZ/KwGlCt/waVnwQSK14J ZLNF2pawtZQVzHwrLvnJ1bWmJS6uHnNczequtUpV625/mlTc2o+x2M0u/3ok3X1O0q+w/OjqKDrR maKRvKFDb6nE20jz1lG973WvHuUrNvb6yb6RpO8m4Ttf8CYNv+QC8J4EHEr+PorAq9TvBg28XwV/ 0sFeQzCeJFxPBnfSwg/2b0Q1/DoK28nD1cJwH0VsMhDTycS1QrGcVLxeErPTxaSE8UBlXFAaH9TG CeVweXU8OBbPEccNBfJ0Noq4yoLEx5lCMl5wauQnenfIshki+LgLYYgdtYiIJenmFpJllQk5JZOd FJCOuGWGdNlgRiXnmb1cZb14Vv9hPiwSIZlM2QeZbnmuORgUC7dE64Vvqvrks8PS3MQDf1moYlZQ R40IyKqe7qq05euh28vj87YZjJcWY6bJuGkzTlpdSh5TqC/c6SDG8dSoTrWq3WiSVbv61bCOtaxn Teta27rWlY5vrsc26i71esSf5tOvzxrsARcbXCJT7pNnmWypDfvF5uGsoZ4t6VIH2dpVo3aStD3t Y+uJ2zfGNki9neBd/1Hcyhb0I9HtbHJP2N0VZjeo4Z1KeefX3AWkd53ALTF9n9jfKQb4igXeYnsH mOCc4recDX7JPTd82bJUOI0kHiiKhxbhSca4mU4pbTBZ/HoMf0/Hfa1xUZec1Pg7XnDIM3lykq+8 nKHULmRhTvOa2/zmOM+5znfO8577/OdAD7rQh070ohv96EhPutKXzvSmO/3pUL9JQAAAOw== --=_related 002AAEA9482575E8_=-- From stbryant@cisco.com Fri Jul 3 02:20:42 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6833A6CC3 for ; Fri, 3 Jul 2009 02:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxbTu9lZlqMl for ; Fri, 3 Jul 2009 02:20:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3202B3A6E09 for ; Fri, 3 Jul 2009 02:20:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,340,1243814400"; d="scan'208";a="44286807" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2009 09:21:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n639L3dJ014718; Fri, 3 Jul 2009 11:21:03 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n639L2XC007580; Fri, 3 Jul 2009 09:21:02 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n639L1D04310; Fri, 3 Jul 2009 10:21:02 +0100 (BST) Message-ID: <4A4DCD7D.8000200@cisco.com> Date: Fri, 03 Jul 2009 10:21:01 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: liu.guoman@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1031; t=1246612863; x=1247476863; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20a=20question=20of=20draft-ietf -pwe3-fat-pw-00 |Sender:=20; bh=Y1TvEj2VfgHwyemCR1AgGj+0g7j89PdlUNpFKIcaaEI=; b=ZKoK2l8I/5yX1GmYX6Jf5mLPnEGhTemusKJAjf7IGI/gz7BhEjgQ9uNtua cDJgU0BJtrtredCEVr+o2+wMG4fLQE22S+HXXCViVJvowDhmr2wUf8+cgewS w0tg+bNdvP; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "pwe3@ietf.org" Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:20:42 -0000 liu.guoman@zte.com.cn wrote: > > Stewart£º > according to your answer, I have a few comments: > 1 how to ensure the same pw label in multiple LSPs ? it says, maybe > this pw label used for AC service, have been assigned to another AC > service in a LSP of the multiple LSPs. You assign PW labels exactly as you do today. You pick LB labels by any method you wish regardless of whether the same label is used more than once. The flow label is simply a hint to the ECMP code, and has no significance to anyone. > > 2 for sink points. IMO , flow label and pw label can't be > distinguished only by Label Stack Level. it says , there is a > possibility to regards the flow > label as another pw label ,so it processed this flow label by mistakes. Sure, but this is a problem in any MPLS system - push or pop one label too many and the result is undetermined. You should know (from the PW label) whether you expect to see a LB label and if you are expecting one you simply toss the next label. Stewart From lmartini@cisco.com Fri Jul 3 22:19:57 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E564F3A68E1 for ; Fri, 3 Jul 2009 22:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ-Yotrx3KXZ for ; Fri, 3 Jul 2009 22:19:55 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 8B3EB3A6847 for ; Fri, 3 Jul 2009 22:19:55 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n645INe3019880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 23:18:24 -0600 (MDT) Message-ID: <4A4EE61F.40306@cisco.com> Date: Fri, 03 Jul 2009 23:18:23 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: frederic.jounay@orange-ftgroup.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: pwe3@ietf.org Subject: Re: [PWE3] LDP P2MP PW drafts discussion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 05:19:58 -0000 Fred, Comments below. frederic.jounay@orange-ftgroup.com wrote: > > Luca, > > Please find some comments on the new draft > _http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00_. > > From a general point of view it seems that your proposal relies on > almost the same basic principles as the draft > _http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02_ > (posted 2 years ago and presented during the last IETF meeting), with > the main difference that it is restricted to the SS-PW case. > I disagree. In general draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 is a general sketch of a possible solution. There are many TBDs , and text that states: " The P2MP PW Downstream Label Assignment and detailed procedures for setting up a P2MP PW over a P2P LSP will be described in a future version." Since we have waited a long time , and your draft does not describe an implementable solution. You define many unnecessary parameters as follows: - TAII ( does not convey any useful information. The NMS will handle this functionality, not the protocol ) - P2MP Id ( this can be incorporated into the SAII , or AGI , it just more bits for those values ) - There is no need to send a status code in the FEC. ( this was done in rfc4447 only for negotiation/backward compatibility reason ) - There is no need for a pw status negotiation procedure mentioned in 4.5.2, but not defined. - Leaf Attachment Notification Message. ( This is an NMS function , there is no action to be taken by the PE, this message not necessary) > The solution defined for P2MP SS-PW must be designed with the capacity > to support also P2MP MS-PW. This is the case in the draft jounay-niger. > The draft jounay-niger does not describe this capability either. > The v00 presented the procedure for MS-PW. We removed the MS-PW part > from the last version for sake of simplification in order to focus on > the basic protocol elements, but the capacity to support P2MP MS-PW > remains unchanged. > > As indicated in the introduction your draft is focused on the SS-PW > case and in its current state does not allow the support of MS-PW for > the following reasons : > > - The Group ID does not carry information about leaves identification > (e.g. @ AII) and the signalling messages initiated by the root could > not be routed to the leaves. In our proposal the S-PE forwards the > signaling based on the TAII (leaf node @) transported in the TAII Leaf > sub-TLV, > Again the TAII is redundant. The leaf PE is identified by the LDP router-ID and the LDP session on which the message came in. This is the normal operation of LDP , even for IP FECs. > -The downstream assigned label proposed for upstream traffic (from > leaf to root) can be used in SS-PW to identify the leaf node itself. > However this can not be the case for MS-PW due to the merging point > (S-PE) for upstream traffic. > S-PE are part of MS-PW architecture. So I am not clear of what you are talking about here. The downstream-assigned label ( L-PE to R-PE traffic direction ) is assigned by the root PE. How it is assigned , is a matter of local policy. It may be the same for all L-PEs or maybe not. This is not something relevant to the protocol specification. > I think that's worth coming back to the last point since it appears to > be the main difference with the jounay-niger draft. This requirement > has not yet been defined in the P2MP PW REQ draft. The leaf can report > some OAM/PW status based on LDP Notification messages, but so far it > has not been identified as necessary to allow leaves to send traffic > to the root. Is it a strong requirement? for which applications? If > yes, we need to address it first in the P2MP PW REQ draft. > For a simple P2MP PW, a return path toward the root is sometimes necessary, especially if there is no VPLS associated with this tree. > In the "incompatibilty issues" section (4.1), you propose to follow > the same procedure as defined for P2P (bidirectionnal), i.e. the Leaf > node initiates a LDP status with "PW not forwarding" when the PW type, > CW or int/ parameters does not match with local configuration. We > don't think it appropriate for a P2MP connectivity, because a pb on a > given Leaf node shoud not impact other leaves belonging to the PW > tree. We propose in the draft the definition of new status codes which > allow the Ingress PE to determine exactly the issue (PW type non > compliant code, i/f. Parameters incompatibility code, > Unassigned/unrecognized AGI/P2MP ID). > There is no effect from one leaf to another. The action that the R-PE takes upon receiving a pw status message has not yet been defined in our document. We are still discussing how to map the status messages to the ACs. ( similar to the oam-message-mapping draft ). Remember that we do not transmit NMS related messages in the LDP protocol. > > For the i/f parameters, there is some difference with P2P PW > procedure, please refer the jounay-niger draft (section 4.5.6) or the > draft P2MP PW REQ (section 3.4.2). > I disagree with the procedures in sec 4.5.6. Signaling of interface parameters must be mandatory. Also there is no need to mention every interface parameter in the document , or it will become obsolete very quickly as soon as a new PW type is defined. > Since the beginning of the P2MP PW work our proposal has been closely > designed with the L2VPN WG, and in particular with the VPMS draft. > From this joint work a definition of an optimized P2MP PW FEC has > emerged with the definition of a P2MP ID. The P2MP ID is proposed to > overcome some future operational contrainsts. Indeed in the case we > want to provide similar protection scheme as PW redundancy, we need to > differentiate the primary P2MP PW from the backup P2MP PW in terms of > PW identifier. Such a piece is missing in your proposal Please refer > to section 4.7. or slides presented during the last IETF PWE3 meeting. > > Eventually You define a new Transport LSP TLV, used to indicate to the > leaf node the PSN tunnel the P2MP PW is supported over. This is > required due to the P2MP PW upstream label assignment. There is > already a draft which introduces such an Interface ID (Please refer to > _http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-03_). In > order to avoid refining a new TLV for a common purpose it seems > preferable to extend it to include MLDP P2MP LSP TLV as new Interface > ID, as proposed in our draft. > That document is expired, and I believe that RFC5331, RFC5332, and draft-ietf-mpls-ldp-p2mp-06 describe the proposed standard to be followed. > > Considering all these points we invite you to read the jounay-niger > draft, and since this draft proposes a more general solution, > extensible to MS-PW, we propose to work together to integrate in this > proposal already on the table the new feature described in your draft > (i.e. the P2P return connectivity from leaf to root). > Luca > Best Regards, > Fred > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From liu.guoman@zte.com.cn Sat Jul 4 02:58:16 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A713A6A21 for ; Sat, 4 Jul 2009 02:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.648 X-Spam-Level: X-Spam-Status: No, score=-96.648 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nspzpqWLORM for ; Sat, 4 Jul 2009 02:58:15 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id A29903A6A09 for ; Sat, 4 Jul 2009 02:58:14 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Sat, 4 Jul 2009 16:09:43 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.99] with StormMail ESMTP id 92379.3171924358; Sat, 4 Jul 2009 16:18:54 +0800 (CST) In-Reply-To: <4A4DCD7D.8000200@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Sat, 4 Jul 2009 16:25:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-04 16:25:55, Serialize complete at 2009-07-04 16:25:55 Content-Type: multipart/alternative; boundary="=_alternative 002E5317482575E9_=" Cc: "pwe3@ietf.org" Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 09:58:16 -0000 This is a multipart message in MIME format. --=_alternative 002E5317482575E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c3Rld2FydDoNCiAgdGhhbmsgeW91IGZvciB5b3VyIGV4cGxhaW5pbmcsIEkgaGF2ZSBhbHJlYWR5 IHVuZGVyc3Rvb2QgeW91ciBtZWFuaW5nIGluIA0KIHlvdXIgZHJhZnQNCg0KYmVzdCByZWdhcmRz DQpsaXUNCg0KDQoNCg0KDQoNCg0KU3Rld2FydCBCcnlhbnQgPHN0YnJ5YW50QGNpc2NvLmNvbT4g DQoyMDA5LTA3LTAzIDE3OjIxDQrH67TwuLQguPgNCnN0YnJ5YW50QGNpc2NvLmNvbQ0KDQoNCsrV vP7Iyw0KbGl1Lmd1b21hbkB6dGUuY29tLmNuDQqzrcvNDQoicHdlM0BpZXRmLm9yZyIgPHB3ZTNA aWV0Zi5vcmc+DQrW98ziDQpSZTogW1BXRTNdIGEgcXVlc3Rpb24gb2YgZHJhZnQtaWV0Zi1wd2Uz LWZhdC1wdy0wMA0KDQoNCg0KDQoNCg0KbGl1Lmd1b21hbkB6dGUuY29tLmNuIHdyb3RlOg0KPg0K PiBTdGV3YXJ0o7oNCj4gYWNjb3JkaW5nIHRvIHlvdXIgYW5zd2VyLCBJIGhhdmUgYSBmZXcgY29t bWVudHM6DQo+IDEgaG93IHRvIGVuc3VyZSB0aGUgc2FtZSBwdyBsYWJlbCBpbiBtdWx0aXBsZSBM U1BzID8gaXQgc2F5cywgbWF5YmUNCj4gdGhpcyBwdyBsYWJlbCB1c2VkIGZvciBBQyBzZXJ2aWNl LCBoYXZlIGJlZW4gYXNzaWduZWQgdG8gYW5vdGhlciBBQw0KPiBzZXJ2aWNlIGluIGEgTFNQIG9m IHRoZSBtdWx0aXBsZSBMU1BzLg0KDQpZb3UgYXNzaWduIFBXIGxhYmVscyBleGFjdGx5IGFzIHlv dSBkbyB0b2RheS4NCg0KWW91IHBpY2sgTEIgbGFiZWxzIGJ5IGFueSBtZXRob2QgeW91IHdpc2gg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBzYW1lDQpsYWJlbCBpcyB1c2VkIG1vcmUgdGhhbiBv bmNlLg0KDQpUaGUgZmxvdyBsYWJlbCBpcyBzaW1wbHkgYSBoaW50IHRvIHRoZSBFQ01QIGNvZGUs IGFuZCBoYXMgbm8NCnNpZ25pZmljYW5jZSB0byBhbnlvbmUuDQoNCj4NCj4gMiBmb3Igc2luayBw b2ludHMuIElNTyAsIGZsb3cgbGFiZWwgYW5kIHB3IGxhYmVsIGNhbid0IGJlDQo+IGRpc3Rpbmd1 aXNoZWQgb25seSBieSBMYWJlbCBTdGFjayBMZXZlbC4gaXQgc2F5cyAsIHRoZXJlIGlzIGENCj4g cG9zc2liaWxpdHkgdG8gcmVnYXJkcyB0aGUgZmxvdw0KPiBsYWJlbCBhcyBhbm90aGVyIHB3IGxh YmVsICxzbyBpdCBwcm9jZXNzZWQgdGhpcyBmbG93IGxhYmVsIGJ5IG1pc3Rha2VzLg0KU3VyZSwg YnV0IHRoaXMgaXMgYSBwcm9ibGVtIGluIGFueSBNUExTIHN5c3RlbSAtIHB1c2ggb3IgcG9wIG9u ZSBsYWJlbA0KdG9vIG1hbnkgYW5kIHRoZSByZXN1bHQgaXMgdW5kZXRlcm1pbmVkLg0KDQpZb3Ug c2hvdWxkIGtub3cgKGZyb20gdGhlIFBXIGxhYmVsKSB3aGV0aGVyIHlvdSBleHBlY3QgdG8gc2Vl IGEgTEIgbGFiZWwNCmFuZCBpZiB5b3UgYXJlIGV4cGVjdGluZyBvbmUgeW91IHNpbXBseSB0b3Nz IHRoZSBuZXh0IGxhYmVsLg0KDQpTdGV3YXJ0DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002E5317482575E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnN0ZXdhcnQ6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgdGhhbmsgeW91IGZvciB5b3Vy IGV4cGxhaW5pbmcsDQpJIGhhdmUgYWxyZWFkeSB1bmRlcnN0b29kIHlvdXIgbWVhbmluZyBpbiAm bmJzcDt5b3VyIGRyYWZ0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5iZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPmxpdTxicj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249 Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+U3Rld2FydCBCcnlhbnQgJmx0O3N0YnJ5YW50QGNpc2Nv LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAwOS0wNy0wMyAxNzoyMTwvZm9udD4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCBiZ2NvbG9yPXdoaXRlPg0KPGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsfrtPC4tCC4+Dxicj4NCnN0YnJ5YW50QGNpc2NvLmNvbTwvZm9udD48L2Rp dj48L3RhYmxlPg0KPGJyPg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPmxpdS5ndW9tYW5AenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 cHdlM0BpZXRmLm9yZyZxdW90OyAmbHQ7cHdlM0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbUFdFM10gYSBxdWVzdGlvbiBvZiBkcmFmdC1pZXRmLXB3ZTMtZmF0LXB3LTAwPC9m b250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5s aXUuZ3VvbWFuQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgU3Rld2FydKO6 PGJyPg0KJmd0OyBhY2NvcmRpbmcgdG8geW91ciBhbnN3ZXIsIEkgaGF2ZSBhIGZldyBjb21tZW50 czo8YnI+DQomZ3Q7IDEgaG93IHRvIGVuc3VyZSB0aGUgc2FtZSBwdyBsYWJlbCBpbiBtdWx0aXBs ZSBMU1BzID8gaXQgc2F5cywgbWF5YmU8YnI+DQomZ3Q7IHRoaXMgcHcgbGFiZWwgdXNlZCBmb3Ig QUMgc2VydmljZSwgaGF2ZSBiZWVuIGFzc2lnbmVkIHRvIGFub3RoZXIgQUM8YnI+DQomZ3Q7IHNl cnZpY2UgaW4gYSBMU1Agb2YgdGhlIG11bHRpcGxlIExTUHMuPGJyPg0KPGJyPg0KWW91IGFzc2ln biBQVyBsYWJlbHMgZXhhY3RseSBhcyB5b3UgZG8gdG9kYXkuPGJyPg0KPGJyPg0KWW91IHBpY2sg TEIgbGFiZWxzIGJ5IGFueSBtZXRob2QgeW91IHdpc2ggcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZSBzYW1lPGJyPg0KbGFiZWwgaXMgdXNlZCBtb3JlIHRoYW4gb25jZS48YnI+DQo8YnI+DQpUaGUg ZmxvdyBsYWJlbCBpcyBzaW1wbHkgYSBoaW50IHRvIHRoZSBFQ01QIGNvZGUsIGFuZCBoYXMgbm88 YnI+DQpzaWduaWZpY2FuY2UgdG8gYW55b25lLjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IDIg Zm9yIHNpbmsgcG9pbnRzLiBJTU8gLCBmbG93IGxhYmVsIGFuZCBwdyBsYWJlbCBjYW4ndCBiZTxi cj4NCiZndDsgZGlzdGluZ3Vpc2hlZCBvbmx5IGJ5IExhYmVsIFN0YWNrIExldmVsLiBpdCBzYXlz ICwgdGhlcmUgaXMgYTxicj4NCiZndDsgcG9zc2liaWxpdHkgdG8gcmVnYXJkcyB0aGUgZmxvdzxi cj4NCiZndDsgbGFiZWwgYXMgYW5vdGhlciBwdyBsYWJlbCAsc28gaXQgcHJvY2Vzc2VkIHRoaXMg ZmxvdyBsYWJlbCBieSBtaXN0YWtlcy48YnI+DQpTdXJlLCBidXQgdGhpcyBpcyBhIHByb2JsZW0g aW4gYW55IE1QTFMgc3lzdGVtIC0gcHVzaCBvciBwb3Agb25lIGxhYmVsPGJyPg0KdG9vIG1hbnkg YW5kIHRoZSByZXN1bHQgaXMgdW5kZXRlcm1pbmVkLjxicj4NCjxicj4NCllvdSBzaG91bGQga25v dyAoZnJvbSB0aGUgUFcgbGFiZWwpIHdoZXRoZXIgeW91IGV4cGVjdCB0byBzZWUgYSBMQiBsYWJl bDxicj4NCmFuZCBpZiB5b3UgYXJlIGV4cGVjdGluZyBvbmUgeW91IHNpbXBseSB0b3NzIHRoZSBu ZXh0IGxhYmVsLjxicj4NCjxicj4NClN0ZXdhcnQ8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 002E5317482575E9_=-- From lizhong.jin@nsn.com Mon Jul 6 02:47:29 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A2E3A69B3 for ; Mon, 6 Jul 2009 02:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCIbOY2jXig0 for ; Mon, 6 Jul 2009 02:47:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D0BEE3A6A2A for ; Mon, 6 Jul 2009 02:47:26 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n669LmRq007137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Jul 2009 11:21:48 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n669Ljh3010631; Mon, 6 Jul 2009 11:21:48 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 11:21:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jul 2009 17:21:35 +0800 Message-ID: <328B9F5068825A48A4B8422A350B9047767F9A@CNBEEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] LDP P2MP PW drafts discussion Thread-Index: Acn82bddQe86cIyCTV6vUemJYO50OQBDRvQg References: From: "Jin, Lizhong (NSN - CN/Shanghai)" To: , X-OriginalArrivalTime: 06 Jul 2009 09:21:45.0013 (UTC) FILETIME=[2E3D9650:01C9FE1B] Cc: pwe3@ietf.org Subject: Re: [PWE3] LDP P2MP PW drafts discussion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:47:29 -0000 =20 Hi Luca: According to your description, FEC defined in draft-martini-pwe3-p2mp-pw-00 is much like the P2MP-PWid FEC defined in draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01. P2MP Pwid FEC does not have TAII and P2MP PW-id. We are not intend to define two kind of FEC same as P2P PW, which makes some confusion for vendors, so we remove P2MP Pwid in the second version of draft-jounay-niger-pwe3-source-initiated-p2mp-pw for simplicity. P2MP GID FEC is more scalable than P2MP Pwid, and TAII is necessary for autodiscovery. Also we remove the P2MP MS-PW in this release, because we want to implement P2MP SS-PW for the first step. IMO, Leaf Attachment Notification is necessary, in order to make root node know the leaf node status, then the root node can adjust P2MP PSN tunnel topology. Anyway, draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 needs the WG experts to give comments, and work together to achieve P2MP PW standardization. Best Regards Lizhong Jin -----Original Message----- ---------------------------------------------------------------------- Message: 1 Date: Fri, 03 Jul 2009 23:18:23 -0600 From: Luca Martini Subject: Re: [PWE3] LDP P2MP PW drafts discussion To: frederic.jounay@orange-ftgroup.com Cc: pwe3@ietf.org Message-ID: <4A4EE61F.40306@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Fred, Comments below. frederic.jounay@orange-ftgroup.com wrote: > > Luca, > > Please find some comments on the new draft=20 > _http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00_. > > From a general point of view it seems that your proposal relies on=20 > almost the same basic principles as the draft=20 > _http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2m p-pw-02_=20 > (posted 2 years ago and presented during the last IETF meeting), with=20 > the main difference that it is restricted to the SS-PW case. > I disagree. In general=20 draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 is a general sketch=20 of a possible solution. There are many TBDs , and text that states: " The P2MP PW Downstream Label Assignment and detailed procedures for setting up a P2MP PW over a P2P LSP will be described in a future version." Since we have waited a long time , and your draft does not describe an=20 implementable solution. You define many unnecessary parameters as follows: - TAII ( does not convey any useful information. The NMS will handle=20 this functionality, not the protocol ) - P2MP Id ( this can be incorporated into the SAII , or AGI , it just=20 more bits for those values ) - There is no need to send a status code in the FEC. ( this was done in=20 rfc4447 only for negotiation/backward compatibility reason ) - There is no need for a pw status negotiation procedure mentioned in=20 4.5.2, but not defined. - Leaf Attachment Notification Message. ( This is an NMS function ,=20 there is no action to be taken by the PE, this message not necessary) > The solution defined for P2MP SS-PW must be designed with the capacity > to support also P2MP MS-PW. This is the case in the draft jounay-niger. > The draft jounay-niger does not describe this capability either. > The v00 presented the procedure for MS-PW. We removed the MS-PW part=20 > from the last version for sake of simplification in order to focus on=20 > the basic protocol elements, but the capacity to support P2MP MS-PW=20 > remains unchanged. > > As indicated in the introduction your draft is focused on the SS-PW=20 > case and in its current state does not allow the support of MS-PW for=20 > the following reasons : > > - The Group ID does not carry information about leaves identification=20 > (e.g. @ AII) and the signalling messages initiated by the root could=20 > not be routed to the leaves. In our proposal the S-PE forwards the=20 > signaling based on the TAII (leaf node @) transported in the TAII Leaf > sub-TLV, > Again the TAII is redundant. The leaf PE is identified by the LDP=20 router-ID and the LDP session on which the message came in. This is the normal operation of LDP , even for IP FECs. > -The downstream assigned label proposed for upstream traffic (from=20 > leaf to root) can be used in SS-PW to identify the leaf node itself.=20 > However this can not be the case for MS-PW due to the merging point=20 > (S-PE) for upstream traffic. > S-PE are part of MS-PW architecture. So I am not clear of what you are=20 talking about here. The downstream-assigned label ( L-PE to R-PE traffic direction ) is assigned by the root PE. How it is assigned , is a matter of local policy. It may be the same for all L-PEs or maybe not. This is=20 not something relevant to the protocol specification. > I think that's worth coming back to the last point since it appears to > be the main difference with the jounay-niger draft. This requirement=20 > has not yet been defined in the P2MP PW REQ draft. The leaf can report > some OAM/PW status based on LDP Notification messages, but so far it=20 > has not been identified as necessary to allow leaves to send traffic=20 > to the root. Is it a strong requirement? for which applications? If=20 > yes, we need to address it first in the P2MP PW REQ draft. > For a simple P2MP PW, a return path toward the root is sometimes=20 necessary, especially if there is no VPLS associated with this tree. > In the "incompatibilty issues" section (4.1), you propose to follow=20 > the same procedure as defined for P2P (bidirectionnal), i.e. the Leaf=20 > node initiates a LDP status with "PW not forwarding" when the PW type, > CW or int/ parameters does not match with local configuration. We=20 > don't think it appropriate for a P2MP connectivity, because a pb on a=20 > given Leaf node shoud not impact other leaves belonging to the PW=20 > tree. We propose in the draft the definition of new status codes which > allow the Ingress PE to determine exactly the issue (PW type non=20 > compliant code, i/f. Parameters incompatibility code,=20 > Unassigned/unrecognized AGI/P2MP ID). > There is no effect from one leaf to another. The action that the R-PE=20 takes upon receiving a pw status message has not yet been defined in our document. We are still discussing how to map the status messages to the=20 ACs. ( similar to the oam-message-mapping draft ). Remember that we do=20 not transmit NMS related messages in the LDP protocol. > > For the i/f parameters, there is some difference with P2P PW=20 > procedure, please refer the jounay-niger draft (section 4.5.6) or the=20 > draft P2MP PW REQ (section 3.4.2). > I disagree with the procedures in sec 4.5.6. Signaling of interface=20 parameters must be mandatory. Also there is no need to mention every=20 interface parameter in the document , or it will become obsolete very=20 quickly as soon as a new PW type is defined. > Since the beginning of the P2MP PW work our proposal has been closely=20 > designed with the L2VPN WG, and in particular with the VPMS draft.=20 > From this joint work a definition of an optimized P2MP PW FEC has=20 > emerged with the definition of a P2MP ID. The P2MP ID is proposed to=20 > overcome some future operational contrainsts. Indeed in the case we=20 > want to provide similar protection scheme as PW redundancy, we need to > differentiate the primary P2MP PW from the backup P2MP PW in terms of=20 > PW identifier. Such a piece is missing in your proposal Please refer=20 > to section 4.7. or slides presented during the last IETF PWE3 meeting. > > Eventually You define a new Transport LSP TLV, used to indicate to the > leaf node the PSN tunnel the P2MP PW is supported over. This is=20 > required due to the P2MP PW upstream label assignment. There is=20 > already a draft which introduces such an Interface ID (Please refer to > _http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-03_). In=20 > order to avoid refining a new TLV for a common purpose it seems=20 > preferable to extend it to include MLDP P2MP LSP TLV as new Interface=20 > ID, as proposed in our draft. =20 > That document is expired, and I believe that RFC5331, RFC5332, and=20 draft-ietf-mpls-ldp-p2mp-06 describe the proposed standard to be followed. > > Considering all these points we invite you to read the jounay-niger=20 > draft, and since this draft proposes a more general solution,=20 > extensible to MS-PW, we propose to work together to integrate in this=20 > proposal already on the table the new feature described in your draft=20 > (i.e. the P2P return connectivity from leaf to root). > Luca > Best Regards, > Fred > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > =20 ------------------------------ Message: 2 Date: Sat, 4 Jul 2009 16:25:57 +0800 From: liu.guoman@zte.com.cn Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 To: stbryant@cisco.com Cc: "pwe3@ietf.org" Message-ID: =09 Content-Type: text/plain; charset=3D"gb2312" stewart: thank you for your explaining, I have already understood your meaning in=20 your draft best regards liu Stewart Bryant =20 2009-07-03 17:21 ??? ? stbryant@cisco.com ??? liu.guoman@zte.com.cn ?? "pwe3@ietf.org" ?? Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 liu.guoman@zte.com.cn wrote: > > Stewart? > according to your answer, I have a few comments: > 1 how to ensure the same pw label in multiple LSPs ? it says, maybe > this pw label used for AC service, have been assigned to another AC > service in a LSP of the multiple LSPs. You assign PW labels exactly as you do today. You pick LB labels by any method you wish regardless of whether the same label is used more than once. The flow label is simply a hint to the ECMP code, and has no significance to anyone. > > 2 for sink points. IMO , flow label and pw label can't be > distinguished only by Label Stack Level. it says , there is a > possibility to regards the flow > label as another pw label ,so it processed this flow label by mistakes. Sure, but this is a problem in any MPLS system - push or pop one label too many and the result is undetermined. You should know (from the PW label) whether you expect to see a LB label and if you are expecting one you simply toss the next label. Stewart -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 End of pwe3 Digest, Vol 63, Issue 6 *********************************** From loa@pi.nu Mon Jul 6 03:40:17 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F90B3A6BB9; Mon, 6 Jul 2009 03:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0oj-IrrmtgW; Mon, 6 Jul 2009 03:40:16 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 4839F3A6ACD; Mon, 6 Jul 2009 03:40:16 -0700 (PDT) Received: from [127.0.0.1] (wdhcp-158-111.verkstad.net [192.36.158.111]) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPA id 57CC3D4048; Mon, 6 Jul 2009 12:40:36 +0200 (CEST) Message-ID: <4A51D4A1.9010804@pi.nu> Date: Mon, 06 Jul 2009 12:40:33 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] poll on making the mpls-tp process document a working group draft - update X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:40:17 -0000 All, I started this poll, but since I'm one of the authors of the document I do not feel comfortable to judge the consensus on the poll. I have therefore asked our AD (Adrian Farrel) to step in and together with George make the consensus call. /Loa Loa Andersson wrote: > > All, > > > > we have an individual draft, draft-andersson-mpls-tp-process-03.txt, > > that describes additions to the mpls working group process to allow > > ITU-T to give input on MPLS-TP Internet Drafts. > > > > It pretty much captures current practice, and from the start we had no > > intention to ever progress, but recently there has been comments that > > it would have a better and clearer sttus if it were a working group > > document. > > > > We have had no plans to ever make it an RFC, but it has been pointed > > out that it would be possible to publish as an Historical RFC. Whether > > we execute on that or not is not yet decided. > > > > Therefore, is is to start at two week poll on making > > draft-andersson-mpls-tp-process-03.txt an MPLS working group document. > > > > The poll ends on July 14. > > > > Please send your comments to the mpls-tp list. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 8 632 77 14 From stbryant@cisco.com Tue Jul 7 09:56:47 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B8D28C2AC for ; Tue, 7 Jul 2009 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.975 X-Spam-Level: X-Spam-Status: No, score=-9.975 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VowWfNN3kdy for ; Tue, 7 Jul 2009 09:56:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A48213A6955 for ; Tue, 7 Jul 2009 09:56:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,363,1243814400"; d="scan'208";a="44579242" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jul 2009 16:57:03 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n67Gv31x025791; Tue, 7 Jul 2009 18:57:03 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n67Gv3xm003267; Tue, 7 Jul 2009 16:57:03 GMT Received: from dhcp-gpk02-vlan300-64-103-65-23.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n67Gv2D29644; Tue, 7 Jul 2009 17:57:02 +0100 (BST) Message-ID: <4A537E5E.4090800@cisco.com> Date: Tue, 07 Jul 2009 17:57:02 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pwe3 , BOCCI Matthew , David Sinicrope Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=155; t=1246985823; x=1247849823; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Slots=20for=20PWE3=20at=20IETF=20Stockholm |Sender:=20; bh=yeEUVaFC+ZAaZ24Md+kszce4fWqsFMLaB98yAwMx/kk=; b=kpbtMpMnM/nVgUaaqTxM3IKQTYW5z2AbNcID+px/FKG4Z4PMp6bZdDQSTs PWXy8Ili57jC6NmmoXumPB9lPyVavocoYND97pkX9A9JYVr9Yk6/l+naOj4P BMRP3ohUzu; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [PWE3] Slots for PWE3 at IETF Stockholm X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 16:56:47 -0000 Now that we have a workable time-slot for the PWE3 meeting I would like to check that everyone that needs a slot has requested it. Thanks Stewart From albert.john@zte.com.cn Tue Jul 7 18:11:30 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04723A6805; Tue, 7 Jul 2009 18:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.103 X-Spam-Level: X-Spam-Status: No, score=-101.103 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZFvp+a8V9ts; Tue, 7 Jul 2009 18:11:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 35AAC3A6934; Tue, 7 Jul 2009 18:11:29 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111643491178658; Wed, 8 Jul 2009 08:55:04 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 12012.6421010960; Wed, 8 Jul 2009 09:04:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n681Bfkc089065; Wed, 8 Jul 2009 09:11:41 +0800 (CST) (envelope-from albert.john@zte.com.cn) In-Reply-To: <4A537E5E.4090800@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: albert.john@zte.com.cn Date: Wed, 8 Jul 2009 09:11:18 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-08 09:11:36, Serialize by Notes Client on JiangXiaoWei181977/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-08 09:11:36, Serialize complete at 2009-07-08 09:11:36, S/MIME Sign failed at 2009-07-08 09:11:36: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-08 09:11:35, Serialize complete at 2009-07-08 09:11:35 Content-Type: multipart/alternative; boundary="=_alternative 00068E5D482575ED_=" X-MAIL: mse1.zte.com.cn n681Bfkc089065 Cc: pwe3-bounces@ietf.org, pwe3 , BOCCI Matthew Subject: Re: [PWE3] Slots for PWE3 at IETF Stockholm X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:11:30 -0000 This is a multipart message in MIME format. --=_alternative 00068E5D482575ED_= Content-Type: text/plain; charset="US-ASCII" Sir, I've requested a normal time slot (which is 10 min) for a new draft LDP GR for PW with presentation sent to Mr. Sinicrope. I'd like to confirm my request. I have some update for my presentation slides submitted before, should I resend the slides to Mr. Sinicrope? Thank you. RD Albert Stewart Bryant : pwe3-bounces@ietf.org 2009-07-08 00:57 stbryant@cisco.com pwe3 , BOCCI Matthew , David Sinicrope [PWE3] Slots for PWE3 at IETF Stockholm Now that we have a workable time-slot for the PWE3 meeting I would like to check that everyone that needs a slot has requested it. Thanks Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00068E5D482575ED_= Content-Type: text/html; charset="US-ASCII"
Sir,

I've requested a normal time slot (which is 10 min) for a new draft LDP GR for PW with presentation sent to Mr. Sinicrope.

I'd like to confirm my request.

I have some update for my presentation slides submitted before, should I resend the slides to Mr. Sinicrope?

Thank you.

RD
Albert



 


Stewart Bryant <stbryant@cisco.com>
:  pwe3-bounces@ietf.org

2009-07-08 00:57

stbryant@cisco.com
pwe3 <pwe3@ietf.org>, BOCCI Matthew <Matthew.Bocci@alcatel-lucent.com>, David Sinicrope <euddasi@redback.com>
[PWE3] Slots for PWE3 at IETF Stockholm





Now that we have a workable time-slot for the PWE3
meeting I would like to check that everyone that
needs a slot has requested it.

Thanks

Stewart
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00068E5D482575ED_=-- From xueli@huawei.com Tue Jul 7 19:00:23 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B503A6A3F; Tue, 7 Jul 2009 19:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+wOKqgo9-Yj; Tue, 7 Jul 2009 19:00:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F1A373A6955; Tue, 7 Jul 2009 19:00:21 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF00BFGXKW4Z@szxga04-in.huawei.com>; Wed, 08 Jul 2009 10:00:32 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF00JYEXKV72@szxga04-in.huawei.com>; Wed, 08 Jul 2009 10:00:31 +0800 (CST) Received: from x68103 ([10.111.12.100]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMF00CPDXKVOE@szxml06-in.huawei.com>; Wed, 08 Jul 2009 10:00:31 +0800 (CST) Date: Wed, 08 Jul 2009 10:00:31 +0800 From: Sherry Xue In-reply-to: <03a801c9fef4$21f772b0$b3d80e0a@coe.ntt.com> To: l2vpn@ietf.org, pwe3@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acno9HF22RyjaEt/TzOkSMhWnoSeBAV/xJWgAB4DlyA= Cc: 'Yuji KAMITE' , tochio@labs.fujitsu.com Subject: Re: [PWE3] Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 02:00:23 -0000 Hi, Tochio and Yuji Kamite,=20 I agree with the description of reverse traffic should be relaxed here, = and=20 I appreciate the consideration of the reverse traffic requirements. IMO, there are several options to achieve the reverse traffic in VPMS instance, such as VPMS(forward traffic)+P2P(reverse traffic), = VPMS(forward traffic)+mp2p instance(reverse traffic), also may be bidirectional VPMS(should redefine VPMS maybe).Actually, we have taken the = implementation of the reverse traffic into account. And a bidirectional VPMS instance should be a better method IMO.=20 Here bidirectional VPMS should be defined as P2MP (forward traffic)+multi-p2p(backward traffic). What about your opinion? Anyway, I appreciate the further work for reverse traffic and will be concerned about it. Regards Sherry =20 Quote {> <> > I-D says: > =A1=A1The simplest way to accomplish this is to provide > =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE = is a > =A1=A1receiver of another VPMS instance. >=20 > Since there are some alternatives for this way such that=20 > providing multiple VPWS (as reverse) or mp2p instance So I=20 > ask for relaxing the descrption, i.e. replace "the simplest=20 > way" by "the example" >=20 >Agreed. > I-D says: > Such bi-directional instances can be easily created if two=20 > distinct ACs are provisioned for sending and receiving exclusively >=20 > I am not sure this assumption (=3D exclusively) is easiest. > I also ask for relaxing the descrption. >=20 >=20 >It mostly depends on the implementation matter if a particular >approach is the easiest or not, so I'll edit it >not to cause misunderstanding. Basically, I guess exlusive using (Tx and Rx) might be easy from PE perspective, but from CE's view it could not be so simple. Anyway, authors now think that the consideration of reverse traffic needs more study. We're proposing new text in the next revision.} > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of > Yuji KAMITE > Sent: Tuesday, July 07, 2009 7:15 PM > To: tochio@labs.fujitsu.com; l2vpn@ietf.org > Subject: RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements" >=20 > Hi, Mr. Tochio, >=20 > Thank you for your interest and reviewing. > I wrote comments below inline. >=20 > > > > Dear Editors and all, > > > > FYI: > > Here are my comments on this I-D through offline discussion > > with Yuji (Mr. Kamite) though some had been posted by Greg > > > > <> > > I-D says: > > As far as synchronization in a PSN environment is concerned, > > different mechanisms can be considered to provide frequency > > and phase clock > > > > "clock" should be replaced by "synchronization" > > Or in generic manner, "to provide frequency and phase clock " > > may be removed. > > >=20 > Ok, I'll change the word to avoid confusion. >=20 >=20 > > > > <> > > In general, It seems that contents of those clauses are > > overlapped to each other so that editorial clean up should be > > required. > > > > I think first these sentences are enough in 6.1.2 and the > > rest of those in 6.1.2 with figure 2 should be merged to 6.4 > > >=20 > I'm going to merge it. >=20 >=20 > > A solution MUST support multiple sender topologies in one > > VPMS instance, where a common receiver group is reachable > > from two or more senders. This means that a solution needs to > > support having multiple P2MP topologies in the backbone whose > > roots are located apart in a common service. Thus a solution > > will also need to support protection and restoration > > mechanism combining these multiple P2MP topologies. (See > > section 6.4 too). > > > > > > And even if in clause 6.1.2., more clarification of Figure 2 > > should be considered. The most important is to clarify AC3 & > > 4 or PE3 & PE4. > > AC3 or 4 seems to share VPMS instance from either PE1 or PE2. > > This point should be clarified. > > > > For example, proposed is > > > > Replace > > > > Note that every receiver has only to have one AC connected to > > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively). > > Thus a solution will also need to support protection and > > restoration mechanism combining these multiple P2MP > > topologies. (See section 6.4 too). > > > > by > > > > Note that every receiver has only to have one AC connected to > > each PE to receive traffic. In the case of Figure 2, PE3 and > > PE4 should select traffic from PE1 or PE2 and AC3 and AC4 > > should be single as attached to PE3 and PE4 respectively. > > Thus a solution will also need to support protection and > > restoration mechanism combining these multiple P2MP > > topologies. (See section 6.4.2 too). > > > > Of cource, this could be better in align with 6.4.1.2 > > >=20 > What you mean by "traffic selection" makes sense. > This point will be described in the next revision. > It will still need some of wording arrangement though. >=20 >=20 > > > > <> > > I-D says: > > =A1=A1The simplest way to accomplish this is to provide > > =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE = is a > > =A1=A1receiver of another VPMS instance. > > > > Since there are some alternatives for this way such that > > providing multiple VPWS (as reverse) or mp2p instance So I > > ask for relaxing the descrption, i.e. replace "the simplest > > way" by "the example" > > >=20 > Agreed. >=20 > > I-D says: > > Such bi-directional instances can be easily created if two > > distinct ACs are provisioned for sending and receiving exclusively > > > > I am not sure this assumption (=3D exclusively) is easiest. > > I also ask for relaxing the descrption. > > > > >=20 > It mostly depends on the implementation matter if a particular > approach is the easiest or not, so I'll edit it > not to cause misunderstanding. >=20 > Basically, I guess exlusive using (Tx and Rx) might be easy from > PE perspective, but from CE's view it could not be so simple. >=20 > Anyway, authors now think that the consideration of reverse traffic > needs more study. We're proposing new text in the next revision. >=20 >=20 > > <> > > In general, I think these subclauses should focus on > > - Protetion/redundancy topology support as 6.1.4.1 > > - Traffic support in Protetion/redundancy as 6.1.4.1 As I > > wrote above, this is overlapped with 6.1.2 Figure 2 should be > > moved here and text should be merged with latter of 6.1.2 > > >=20 > Agreed with your idea in general. >=20 > I'd appreciate it if you could check again > when we submit the next version. >=20 >=20 > > > > <> > > There are some areas that form protection/redundancy: > > (1) (Sender) CE to (Sender/Ingress) PEs > > (2) VPMS instances or inside PSN > > (3) (Receiver) PEs to Receiver CE > > > > This clause should indicate this point, where > > protection/redundancy is required. (The use of dual home may miss = (2)) > > >=20 > I'll make sure the next revision will explain > the category of the protection briefly . >=20 > Regarding (2), I think it needs to describe something for detail: >=20 > "VPMS instance": This requirement is related to the PW signaling > (and discovery etc) between PE nodes. > Hence this will have common aspect of (1)/(3) in terms of solution = level. >=20 > "Inside PSN": This requirement will be satisfied by PSN protection mechanism. >=20 >=20 > > > > <> > > As I wrote above, this is overlapped with 6.1.2 Figure 2 > > should be moved to this clause here and text should be merged > > with latter of 6.1.2 > > >=20 > All right. >=20 >=20 > > > > Regards, > > Yuji Tochio > > > > >=20 > Thanks. >=20 > Best ragards, > Yuji Kamite >=20 >=20 > > -----Original Message----- > > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] > > On Behalf Of Yuji Tochio > > Sent: Tuesday, June 09, 2009 8:21 PM > > To: l2vpn@ietf.org > > Subject: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements" > > > > Dear Editors and all, > > > > FYI: > > Here are my comments on this I-D through offline discussion > > with Yuji (Mr. Kamite) though some had been posted by Greg > > > > <> > > I-D says: > > As far as synchronization in a PSN environment is concerned, > > different mechanisms can be considered to provide frequency > > and phase clock > > > > "clock" should be replaced by "synchronization" > > Or in generic manner, "to provide frequency and phase clock " > > may be removed. > > > > > > <> > > In general, It seems that contents of those clauses are > > overlapped to each other so that editorial clean up should be > > required. > > > > I think first these sentences are enough in 6.1.2 and the > > rest of those in 6.1.2 with figure 2 should be merged to 6.4 > > > > A solution MUST support multiple sender topologies in one > > VPMS instance, where a common receiver group is reachable > > from two or more senders. This means that a solution needs to > > support having multiple P2MP topologies in the backbone whose > > roots are located apart in a common service. Thus a solution > > will also need to support protection and restoration > > mechanism combining these multiple P2MP topologies. (See > > section 6.4 too). > > > > > > And even if in clause 6.1.2., more clarification of Figure 2 > > should be considered. The most important is to clarify AC3 & > > 4 or PE3 & PE4. > > AC3 or 4 seems to share VPMS instance from either PE1 or PE2. > > This point should be clarified. > > > > For example, proposed is > > > > Replace > > > > Note that every receiver has only to have one AC connected to > > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively). > > Thus a solution will also need to support protection and > > restoration mechanism combining these multiple P2MP > > topologies. (See section 6.4 too). > > > > by > > > > Note that every receiver has only to have one AC connected to > > each PE to receive traffic. In the case of Figure 2, PE3 and > > PE4 should select traffic from PE1 or PE2 and AC3 and AC4 > > should be single as attached to PE3 and PE4 respectively. > > Thus a solution will also need to support protection and > > restoration mechanism combining these multiple P2MP > > topologies. (See section 6.4.2 too). > > > > Of cource, this could be better in align with 6.4.1.2 > > > > > > <> > > I-D says: > > =A1=A1The simplest way to accomplish this is to provide > > =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE = is a > > =A1=A1receiver of another VPMS instance. > > > > Since there are some alternatives for this way such that > > providing multiple VPWS (as reverse) or mp2p instance So I > > ask for relaxing the descrption, i.e. replace "the simplest > > way" by "the example" > > > > I-D says: > > Such bi-directional instances can be easily created if two > > distinct ACs are provisioned for sending and receiving exclusively > > > > I am not sure this assumption (=3D exclusively) is easiest. > > I also ask for relaxing the descrption. > > > > > > <> > > In general, I think these subclauses should focus on > > - Protetion/redundancy topology support as 6.1.4.1 > > - Traffic support in Protetion/redundancy as 6.1.4.1 As I > > wrote above, this is overlapped with 6.1.2 Figure 2 should be > > moved here and text should be merged with latter of 6.1.2 > > > > > > <> > > There are some areas that form protection/redundancy: > > (1) (Sender) CE to (Sender/Ingress) PEs > > (2) VPMS instances or inside PSN > > (3) (Receiver) PEs to Receiver CE > > > > This clause should indicate this point, where > > protection/redundancy is required. (The use of dual home may miss = (2)) > > > > > > <> > > As I wrote above, this is overlapped with 6.1.2 Figure 2 > > should be moved to this clause here and text should be merged > > with latter of 6.1.2 > > > > > > Regards, > > Yuji Tochio > > > > From wwwrun@core3.amsl.com Wed Jul 8 10:20:01 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AEA173A6A92; Wed, 8 Jul 2009 10:20:01 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090708172001.AEA173A6A92@core3.amsl.com> Date: Wed, 8 Jul 2009 10:20:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] Last Call: draft-ietf-pwe3-mpls-transport (Application of X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:20:01 -0000 Ethernet Pseudowires to MPLS Transport Networks) to Informational RFC The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Application of Ethernet Pseudowires to MPLS Transport Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16038&rfc_flag=0 From lmartini@cisco.com Wed Jul 8 10:21:09 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C7B3A69DB for ; Wed, 8 Jul 2009 10:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXZAMFGAbbaF for ; Wed, 8 Jul 2009 10:21:07 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 153F43A6AD1 for ; Wed, 8 Jul 2009 10:21:06 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n68HKoni016647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 11:20:52 -0600 (MDT) Message-ID: <4A54D572.1080807@cisco.com> Date: Wed, 08 Jul 2009 11:20:50 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: "Jin, Lizhong (NSN - CN/Shanghai)" References: <328B9F5068825A48A4B8422A350B9047767F9A@CNBEEXC006.nsn-intra.net> In-Reply-To: <328B9F5068825A48A4B8422A350B9047767F9A@CNBEEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: pwe3@ietf.org Subject: Re: [PWE3] LDP P2MP PW drafts discussion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 17:21:09 -0000 Jin, Lizhong (NSN - CN/Shanghai) wrote: > > Hi Luca: > According to your description, FEC defined in > draft-martini-pwe3-p2mp-pw-00 is much like the P2MP-PWid FEC defined in > draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01. P2MP Pwid FEC does > not have TAII and P2MP PW-id. We are not intend to define two kind of > FEC same as P2P PW, which makes some confusion for vendors, so we remove > P2MP Pwid in the second version of > draft-jounay-niger-pwe3-source-initiated-p2mp-pw for simplicity. P2MP > GID FEC is more scalable than P2MP Pwid, and TAII is necessary for > autodiscovery. Also we remove the P2MP MS-PW in this release, because we > want to implement P2MP SS-PW for the first step. > > Can you explain how you would use the TAI for autodiscovery ? Multicast does not have a concept of "Target" so I'm unclear on what the TAI is for. > IMO, Leaf Attachment Notification is necessary, in order to make root > node know the leaf node status, then the root node can adjust P2MP PSN > tunnel topology. > > I think that we can agree that in the case of mLDP , this is not necessary. As for the case where we use a root initiated P2MP RSVP-TE tunnel we do need a specific message if we want to automate the LSP setup process. So we probably need an LDP message that requests a P2MP RSVP-TE LSP extension to the leaf sending the request message, Thanks for your comments . Luca > Anyway, draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 needs the WG > experts to give comments, and work together to achieve P2MP PW > standardization. > > Best Regards > Lizhong Jin > > > -----Original Message----- > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 03 Jul 2009 23:18:23 -0600 > From: Luca Martini > Subject: Re: [PWE3] LDP P2MP PW drafts discussion > To: frederic.jounay@orange-ftgroup.com > Cc: pwe3@ietf.org > Message-ID: <4A4EE61F.40306@cisco.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Fred, > > Comments below. > > frederic.jounay@orange-ftgroup.com wrote: > >> Luca, >> >> Please find some comments on the new draft >> _http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00_. >> >> From a general point of view it seems that your proposal relies on >> almost the same basic principles as the draft >> >> > _http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2m > p-pw-02_ > >> (posted 2 years ago and presented during the last IETF meeting), with >> the main difference that it is restricted to the SS-PW case. >> >> > I disagree. In general > draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 is a general sketch > of a possible solution. There are many TBDs , and text that states: > > " The P2MP PW Downstream Label Assignment and detailed procedures for > setting up a P2MP PW over a P2P LSP will be described in a future > version." > > Since we have waited a long time , and your draft does not describe an > implementable solution. > You define many unnecessary parameters as follows: > > - TAII ( does not convey any useful information. The NMS will handle > this functionality, not the protocol ) > - P2MP Id ( this can be incorporated into the SAII , or AGI , it just > more bits for those values ) > - There is no need to send a status code in the FEC. ( this was done in > rfc4447 only for negotiation/backward compatibility reason ) > - There is no need for a pw status negotiation procedure mentioned in > 4.5.2, but not defined. > - Leaf Attachment Notification Message. ( This is an NMS function , > there is no action to be taken by the PE, this message not necessary) > > > >> The solution defined for P2MP SS-PW must be designed with the capacity >> > > >> to support also P2MP MS-PW. This is the case in the draft >> > jounay-niger. > > The draft jounay-niger does not describe this capability either. > > >> The v00 presented the procedure for MS-PW. We removed the MS-PW part >> from the last version for sake of simplification in order to focus on >> the basic protocol elements, but the capacity to support P2MP MS-PW >> remains unchanged. >> >> As indicated in the introduction your draft is focused on the SS-PW >> case and in its current state does not allow the support of MS-PW for >> the following reasons : >> >> - The Group ID does not carry information about leaves identification >> (e.g. @ AII) and the signalling messages initiated by the root could >> not be routed to the leaves. In our proposal the S-PE forwards the >> signaling based on the TAII (leaf node @) transported in the TAII Leaf >> > > >> sub-TLV, >> >> > Again the TAII is redundant. The leaf PE is identified by the LDP > router-ID and the LDP session on which the message came in. This is the > > normal operation of LDP , even for IP FECs. > > >> -The downstream assigned label proposed for upstream traffic (from >> leaf to root) can be used in SS-PW to identify the leaf node itself. >> However this can not be the case for MS-PW due to the merging point >> (S-PE) for upstream traffic. >> >> > S-PE are part of MS-PW architecture. So I am not clear of what you are > talking about here. The downstream-assigned label ( L-PE to R-PE traffic > > direction ) is assigned by the root PE. How it is assigned , is a matter > > of local policy. It may be the same for all L-PEs or maybe not. This is > not something relevant to the protocol specification. > > >> I think that's worth coming back to the last point since it appears to >> > > >> be the main difference with the jounay-niger draft. This requirement >> has not yet been defined in the P2MP PW REQ draft. The leaf can report >> > > >> some OAM/PW status based on LDP Notification messages, but so far it >> has not been identified as necessary to allow leaves to send traffic >> to the root. Is it a strong requirement? for which applications? If >> yes, we need to address it first in the P2MP PW REQ draft. >> >> > For a simple P2MP PW, a return path toward the root is sometimes > necessary, especially if there is no VPLS associated with this tree. > > >> In the "incompatibilty issues" section (4.1), you propose to follow >> the same procedure as defined for P2P (bidirectionnal), i.e. the Leaf >> node initiates a LDP status with "PW not forwarding" when the PW type, >> > > >> CW or int/ parameters does not match with local configuration. We >> don't think it appropriate for a P2MP connectivity, because a pb on a >> given Leaf node shoud not impact other leaves belonging to the PW >> tree. We propose in the draft the definition of new status codes which >> > > >> allow the Ingress PE to determine exactly the issue (PW type non >> compliant code, i/f. Parameters incompatibility code, >> Unassigned/unrecognized AGI/P2MP ID). >> >> > There is no effect from one leaf to another. The action that the R-PE > takes upon receiving a pw status message has not yet been defined in our > > document. We are still discussing how to map the status messages to the > ACs. ( similar to the oam-message-mapping draft ). Remember that we do > not transmit NMS related messages in the LDP protocol. > >> For the i/f parameters, there is some difference with P2P PW >> procedure, please refer the jounay-niger draft (section 4.5.6) or the >> draft P2MP PW REQ (section 3.4.2). >> >> > I disagree with the procedures in sec 4.5.6. Signaling of interface > parameters must be mandatory. Also there is no need to mention every > interface parameter in the document , or it will become obsolete very > quickly as soon as a new PW type is defined. > > >> Since the beginning of the P2MP PW work our proposal has been closely >> designed with the L2VPN WG, and in particular with the VPMS draft. >> From this joint work a definition of an optimized P2MP PW FEC has >> emerged with the definition of a P2MP ID. The P2MP ID is proposed to >> overcome some future operational contrainsts. Indeed in the case we >> want to provide similar protection scheme as PW redundancy, we need to >> > > >> differentiate the primary P2MP PW from the backup P2MP PW in terms of >> PW identifier. Such a piece is missing in your proposal Please refer >> to section 4.7. or slides presented during the last IETF PWE3 meeting. >> >> Eventually You define a new Transport LSP TLV, used to indicate to the >> > > >> leaf node the PSN tunnel the P2MP PW is supported over. This is >> required due to the P2MP PW upstream label assignment. There is >> already a draft which introduces such an Interface ID (Please refer to >> > > >> _http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-03_). In >> order to avoid refining a new TLV for a common purpose it seems >> preferable to extend it to include MLDP P2MP LSP TLV as new Interface >> ID, as proposed in our draft. >> >> > That document is expired, and I believe that RFC5331, RFC5332, and > draft-ietf-mpls-ldp-p2mp-06 describe the proposed standard to be > followed. > >> Considering all these points we invite you to read the jounay-niger >> draft, and since this draft proposes a more general solution, >> extensible to MS-PW, we propose to work together to integrate in this >> proposal already on the table the new feature described in your draft >> (i.e. the P2P return connectivity from leaf to root). >> >> > Luca > > >> Best Regards, >> Fred >> >> >> > ------------------------------------------------------------------------ > >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > > > > ------------------------------ > > Message: 2 > Date: Sat, 4 Jul 2009 16:25:57 +0800 > From: liu.guoman@zte.com.cn > Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 > To: stbryant@cisco.com > Cc: "pwe3@ietf.org" > Message-ID: > > > Content-Type: text/plain; charset="gb2312" > > stewart: > thank you for your explaining, I have already understood your meaning > in > your draft > > best regards > liu > > > > > > > > Stewart Bryant > 2009-07-03 17:21 > ??? ? > stbryant@cisco.com > > > ??? > liu.guoman@zte.com.cn > ?? > "pwe3@ietf.org" > ?? > Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 > > > > > > > liu.guoman@zte.com.cn wrote: > >> Stewart? >> according to your answer, I have a few comments: >> 1 how to ensure the same pw label in multiple LSPs ? it says, maybe >> this pw label used for AC service, have been assigned to another AC >> service in a LSP of the multiple LSPs. >> > > You assign PW labels exactly as you do today. > > You pick LB labels by any method you wish regardless of whether the same > label is used more than once. > > The flow label is simply a hint to the ECMP code, and has no > significance to anyone. > > >> 2 for sink points. IMO , flow label and pw label can't be >> distinguished only by Label Stack Level. it says , there is a >> possibility to regards the flow >> label as another pw label ,so it processed this flow label by >> > mistakes. > Sure, but this is a problem in any MPLS system - push or pop one label > too many and the result is undetermined. > > You should know (from the PW label) whether you expect to see a LB label > and if you are expecting one you simply toss the next label. > > Stewart > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > is solely property of the sender's organization. This mail communication > is confidential. Recipients named above are obligated to maintain > secrecy and are not permitted to disclose the contents of this > communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > /attachment.htm> > > ------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > End of pwe3 Digest, Vol 63, Issue 6 > *********************************** > > From lizhong.jin@nsn.com Fri Jul 10 01:25:27 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2529A3A6DF7 for ; Fri, 10 Jul 2009 01:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynbW77TB71yd for ; Fri, 10 Jul 2009 01:25:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 714653A6DA0 for ; Fri, 10 Jul 2009 01:25:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6A8PmBu003473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2009 10:25:48 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6A8Plw5019044; Fri, 10 Jul 2009 10:25:48 +0200 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 10:25:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2009 16:25:27 +0800 Message-ID: <328B9F5068825A48A4B8422A350B90477B9C67@CNBEEXC006.nsn-intra.net> In-Reply-To: <4A54D572.1080807@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] LDP P2MP PW drafts discussion Thread-Index: Acn/8I7L1qxAZLTNRL22O/y9jajXDwBQYGiA References: <328B9F5068825A48A4B8422A350B9047767F9A@CNBEEXC006.nsn-intra.net> <4A54D572.1080807@cisco.com> From: "Jin, Lizhong (NSN - CN/Shanghai)" To: "ext Luca Martini" X-OriginalArrivalTime: 10 Jul 2009 08:25:47.0175 (UTC) FILETIME=[06772B70:01CA0138] Cc: pwe3@ietf.org Subject: Re: [PWE3] LDP P2MP PW drafts discussion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 08:25:27 -0000 Hi Luca: Thank you for your reply. Please see my comments with [Lizhong Jin]. Best Regards Lizhong Jin -----Original Message----- From: ext Luca Martini [mailto:lmartini@cisco.com]=20 Sent: Thursday, July 09, 2009 1:21 To: Jin, Lizhong (NSN - CN/Shanghai) Cc: frederic.jounay@orange-ftgroup.com; pwe3@ietf.org Subject: Re: [PWE3] LDP P2MP PW drafts discussion Jin, Lizhong (NSN - CN/Shanghai) wrote: > =20 > Hi Luca: > According to your description, FEC defined in > draft-martini-pwe3-p2mp-pw-00 is much like the P2MP-PWid FEC defined in > draft-jounay-niger-pwe3-source-initiated-p2mp-pw-01. P2MP Pwid FEC does > not have TAII and P2MP PW-id. We are not intend to define two kind of > FEC same as P2P PW, which makes some confusion for vendors, so we remove > P2MP Pwid in the second version of > draft-jounay-niger-pwe3-source-initiated-p2mp-pw for simplicity. P2MP > GID FEC is more scalable than P2MP Pwid, and TAII is necessary for > autodiscovery. Also we remove the P2MP MS-PW in this release, because we > want to implement P2MP SS-PW for the first step. > > =20 Can you explain how you would use the TAI for autodiscovery ? Multicast does not have a concept of "Target" so I'm unclear on what the TAI is for. [Lizhong Jin]: For P2MP MS-PW, TAI is needed for autodiscovery. For P2MP SS-PW, you are right, TAI is not necessary. We should define a FEC which can suitable for both P2MP MS-PW and P2MP SS-PW. > IMO, Leaf Attachment Notification is necessary, in order to make root > node know the leaf node status, then the root node can adjust P2MP PSN > tunnel topology. > > =20 I think that we can agree that in the case of mLDP , this is not necessary. As for the case where we use a root initiated P2MP RSVP-TE tunnel we do=20 need a specific message if we want to automate the LSP setup process. So we probably need an LDP message that requests a P2MP RSVP-TE LSP=20 extension to the leaf sending the request message, [Lizhong Jin]: in case of mLDP, when P2MP PW is multiplexing to an already existing mLDP P2MP LSP, the ingress PE also need the successful leaf information to choose a suitable existing mLDP P2MP LSP for multiplexing. The P2MP PW multiplexing is always root initiated for both RSVP-TE or mLDP. Thanks for your comments . Luca > Anyway, draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 needs the WG > experts to give comments, and work together to achieve P2MP PW > standardization. > > Best Regards > Lizhong Jin > > > -----Original Message----- > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 03 Jul 2009 23:18:23 -0600 > From: Luca Martini > Subject: Re: [PWE3] LDP P2MP PW drafts discussion > To: frederic.jounay@orange-ftgroup.com > Cc: pwe3@ietf.org > Message-ID: <4A4EE61F.40306@cisco.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Fred, > > Comments below. > > frederic.jounay@orange-ftgroup.com wrote: > =20 >> Luca, >> >> Please find some comments on the new draft=20 >> _http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00_. >> >> From a general point of view it seems that your proposal relies on=20 >> almost the same basic principles as the draft=20 >> >> =20 > _http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2m > p-pw-02_=20 > =20 >> (posted 2 years ago and presented during the last IETF meeting), with >> the main difference that it is restricted to the SS-PW case. >> >> =20 > I disagree. In general=20 > draft-jounay-niger-pwe3-source-initiated-p2mp-pw-02 is a general sketch=20 > of a possible solution. There are many TBDs , and text that states: > > " The P2MP PW Downstream Label Assignment and detailed procedures for > setting up a P2MP PW over a P2P LSP will be described in a future > version." > > Since we have waited a long time , and your draft does not describe an > implementable solution. > You define many unnecessary parameters as follows: > > - TAII ( does not convey any useful information. The NMS will handle=20 > this functionality, not the protocol ) > - P2MP Id ( this can be incorporated into the SAII , or AGI , it just=20 > more bits for those values ) > - There is no need to send a status code in the FEC. ( this was done in=20 > rfc4447 only for negotiation/backward compatibility reason ) > - There is no need for a pw status negotiation procedure mentioned in=20 > 4.5.2, but not defined. > - Leaf Attachment Notification Message. ( This is an NMS function ,=20 > there is no action to be taken by the PE, this message not necessary) > > > =20 >> The solution defined for P2MP SS-PW must be designed with the capacity >> =20 > > =20 >> to support also P2MP MS-PW. This is the case in the draft >> =20 > jounay-niger. > =20 > The draft jounay-niger does not describe this capability either. > > =20 >> The v00 presented the procedure for MS-PW. We removed the MS-PW part=20 >> from the last version for sake of simplification in order to focus on >> the basic protocol elements, but the capacity to support P2MP MS-PW=20 >> remains unchanged. >> >> As indicated in the introduction your draft is focused on the SS-PW=20 >> case and in its current state does not allow the support of MS-PW for >> the following reasons : >> >> - The Group ID does not carry information about leaves identification >> (e.g. @ AII) and the signalling messages initiated by the root could=20 >> not be routed to the leaves. In our proposal the S-PE forwards the=20 >> signaling based on the TAII (leaf node @) transported in the TAII Leaf >> =20 > > =20 >> sub-TLV, >> >> =20 > Again the TAII is redundant. The leaf PE is identified by the LDP=20 > router-ID and the LDP session on which the message came in. This is the > > normal operation of LDP , even for IP FECs. > > =20 >> -The downstream assigned label proposed for upstream traffic (from=20 >> leaf to root) can be used in SS-PW to identify the leaf node itself.=20 >> However this can not be the case for MS-PW due to the merging point=20 >> (S-PE) for upstream traffic. >> >> =20 > S-PE are part of MS-PW architecture. So I am not clear of what you are > talking about here. The downstream-assigned label ( L-PE to R-PE traffic > > direction ) is assigned by the root PE. How it is assigned , is a matter > > of local policy. It may be the same for all L-PEs or maybe not. This is=20 > not something relevant to the protocol specification. > > =20 >> I think that's worth coming back to the last point since it appears to >> =20 > > =20 >> be the main difference with the jounay-niger draft. This requirement=20 >> has not yet been defined in the P2MP PW REQ draft. The leaf can report >> =20 > > =20 >> some OAM/PW status based on LDP Notification messages, but so far it >> has not been identified as necessary to allow leaves to send traffic=20 >> to the root. Is it a strong requirement? for which applications? If=20 >> yes, we need to address it first in the P2MP PW REQ draft. >> >> =20 > For a simple P2MP PW, a return path toward the root is sometimes=20 > necessary, especially if there is no VPLS associated with this tree. > > =20 >> In the "incompatibilty issues" section (4.1), you propose to follow=20 >> the same procedure as defined for P2P (bidirectionnal), i.e. the Leaf >> node initiates a LDP status with "PW not forwarding" when the PW type, >> =20 > > =20 >> CW or int/ parameters does not match with local configuration. We=20 >> don't think it appropriate for a P2MP connectivity, because a pb on a >> given Leaf node shoud not impact other leaves belonging to the PW=20 >> tree. We propose in the draft the definition of new status codes which >> =20 > > =20 >> allow the Ingress PE to determine exactly the issue (PW type non=20 >> compliant code, i/f. Parameters incompatibility code,=20 >> Unassigned/unrecognized AGI/P2MP ID). >> >> =20 > There is no effect from one leaf to another. The action that the R-PE=20 > takes upon receiving a pw status message has not yet been defined in our > > document. We are still discussing how to map the status messages to the=20 > ACs. ( similar to the oam-message-mapping draft ). Remember that we do > not transmit NMS related messages in the LDP protocol. > =20 >> For the i/f parameters, there is some difference with P2P PW=20 >> procedure, please refer the jounay-niger draft (section 4.5.6) or the >> draft P2MP PW REQ (section 3.4.2). >> >> =20 > I disagree with the procedures in sec 4.5.6. Signaling of interface=20 > parameters must be mandatory. Also there is no need to mention every=20 > interface parameter in the document , or it will become obsolete very=20 > quickly as soon as a new PW type is defined. > > =20 >> Since the beginning of the P2MP PW work our proposal has been closely >> designed with the L2VPN WG, and in particular with the VPMS draft.=20 >> From this joint work a definition of an optimized P2MP PW FEC has=20 >> emerged with the definition of a P2MP ID. The P2MP ID is proposed to=20 >> overcome some future operational contrainsts. Indeed in the case we=20 >> want to provide similar protection scheme as PW redundancy, we need to >> =20 > > =20 >> differentiate the primary P2MP PW from the backup P2MP PW in terms of >> PW identifier. Such a piece is missing in your proposal Please refer >> to section 4.7. or slides presented during the last IETF PWE3 meeting. >> >> Eventually You define a new Transport LSP TLV, used to indicate to the >> =20 > > =20 >> leaf node the PSN tunnel the P2MP PW is supported over. This is=20 >> required due to the P2MP PW upstream label assignment. There is=20 >> already a draft which introduces such an Interface ID (Please refer to >> =20 > > =20 >> _http://tools.ietf.org/html/draft-ietf-mpls-ldp-upstream-03_). In=20 >> order to avoid refining a new TLV for a common purpose it seems=20 >> preferable to extend it to include MLDP P2MP LSP TLV as new Interface >> ID, as proposed in our draft. =20 >> >> =20 > That document is expired, and I believe that RFC5331, RFC5332, and=20 > draft-ietf-mpls-ldp-p2mp-06 describe the proposed standard to be > followed. > =20 >> Considering all these points we invite you to read the jounay-niger=20 >> draft, and since this draft proposes a more general solution,=20 >> extensible to MS-PW, we propose to work together to integrate in this >> proposal already on the table the new feature described in your draft >> (i.e. the P2P return connectivity from leaf to root). >> >> =20 > Luca > > =20 >> Best Regards, >> Fred >> >> >> =20 > ------------------------------------------------------------------------ > =20 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> =20 >> =20 > > > > ------------------------------ > > Message: 2 > Date: Sat, 4 Jul 2009 16:25:57 +0800 > From: liu.guoman@zte.com.cn > Subject: Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 > To: stbryant@cisco.com > Cc: "pwe3@ietf.org" > Message-ID: > =09 > > Content-Type: text/plain; charset=3D"gb2312" > > stewart: > thank you for your explaining, I have already understood your meaning > in=20 > your draft > > best regards > liu > > > > > > > > Stewart Bryant =20 > 2009-07-03 17:21 > ??? ? > stbryant@cisco.com > > > ??? > liu.guoman@zte.com.cn > ?? > "pwe3@ietf.org" > ?? > Re: [PWE3] a question of draft-ietf-pwe3-fat-pw-00 > > > > > > > liu.guoman@zte.com.cn wrote: > =20 >> Stewart? >> according to your answer, I have a few comments: >> 1 how to ensure the same pw label in multiple LSPs ? it says, maybe >> this pw label used for AC service, have been assigned to another AC >> service in a LSP of the multiple LSPs. >> =20 > > You assign PW labels exactly as you do today. > > You pick LB labels by any method you wish regardless of whether the same > label is used more than once. > > The flow label is simply a hint to the ECMP code, and has no > significance to anyone. > > =20 >> 2 for sink points. IMO , flow label and pw label can't be >> distinguished only by Label Stack Level. it says , there is a >> possibility to regards the flow >> label as another pw label ,so it processed this flow label by >> =20 > mistakes. > Sure, but this is a problem in any MPLS system - push or pop one label > too many and the result is undetermined. > > You should know (from the PW label) whether you expect to see a LB label > and if you are expecting one you simply toss the next label. > > Stewart > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > is solely property of the sender's organization. This mail communication > is confidential. Recipients named above are obligated to maintain > secrecy and are not permitted to disclose the contents of this > communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > /attachment.htm> > > ------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > End of pwe3 Digest, Vol 63, Issue 6 > *********************************** > > =20 From root@core3.amsl.com Sun Jul 12 16:30:02 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3B01A3A6C92; Sun, 12 Jul 2009 16:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090712233002.3B01A3A6C92@core3.amsl.com> Date: Sun, 12 Jul 2009 16:30:02 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-vccv-bfd-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 23:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, C. Pignataro Filename : draft-ietf-pwe3-vccv-bfd-06.txt Pages : 13 Date : 2009-07-12 This document describes Connectivity Verification (CV) types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-bfd-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-12162649.I-D@ietf.org> --NextPart-- From prvs=4386e2a23=euddasi@redback.com Mon Jul 13 08:16:36 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A55928C496; Mon, 13 Jul 2009 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP9ZAOedWrHQ; Mon, 13 Jul 2009 08:16:35 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 636FD28C48F; Mon, 13 Jul 2009 08:16:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,390,1243839600"; d="scan'208,217";a="3457209" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 13 Jul 2009 08:16:35 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B3B0EB5C578; Mon, 13 Jul 2009 08:16:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15269-07; Mon, 13 Jul 2009 08:16:35 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 92251B5C577; Mon, 13 Jul 2009 08:16:35 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Mon, 13 Jul 2009 08:16:35 -0700 From: David Sinicrope To: Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Mon, 13 Jul 2009 08:16:32 -0700 Thread-Topic: [mpls] poll to make draft-andersson-mpls-tp-process-03.txt a working group document Thread-Index: Acn5jfxuCir78JTxQNeGHqnC0oPwKAKPuq90 Message-ID: In-Reply-To: <4A4A1EFA.6040101@pi.nu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C680C8102B400euddasiredbackcom_" MIME-Version: 1.0 Subject: Re: [PWE3] [mpls] poll to make draft-andersson-mpls-tp-process-03.txt a working group document X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:20:49 -0000 --_000_C680C8102B400euddasiredbackcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support On 6/30/09 10:19 AM, "Loa Andersson" wrote: All, we have an individual draft, draft-andersson-mpls-tp-process-03.txt, that describes additions to the mpls working group process to allow ITU-T to give input on MPLS-TP Internet Drafts. It pretty much captures current practice, and from the start we had no intention to ever progress, but recently there has been comments that it would have a better and clearer sttus if it were a working group document. We have had no plans to ever make it an RFC, but it has been pointed out that it would be possible to publish as an Historical RFC. Whether we execute on that or not is not yet decided. Therefore, is is to start at two week poll on making draft-andersson-mpls-tp-process-03.txt an MPLS working group document. The poll ends on July 14. Please send your comments to the mpls-tp list. Please -- Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C680C8102B400euddasiredbackcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [mpls] poll to make draft-andersson-mpls-tp-process-03.txt a wor= king group document Support


On 6/30/09 10:19 AM, "Loa Andersson" <lo= a@pi.nu> wrote:

All,

we have an individual draft, draft-andersson-mpls-tp-process-03.txt,
that describes additions to the mpls working group process to allow
ITU-T to give input on MPLS-TP Internet Drafts.

It pretty much captures current practice, and from the start we had no
intention to ever progress, but recently there has been comments that
it would have a better and clearer sttus if it were a working group
document.

We have had no plans to ever make it an RFC, but it has been pointed
out that it would be possible to publish as an Historical RFC. Whether
we execute on that or not is not yet decided.

Therefore, is is to start at two week poll on making
draft-andersson-mpls-tp-process-03.txt an MPLS working group document.

The poll ends on July 14.

Please send your comments to the mpls-tp list.

Please





--


Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717= 52 13
Ericsson ///           &n= bsp;            = ;         +46 767 72 92 13

            &nb= sp;            =             &nb= sp;email:  loa.andersson@ericss= on.com
            &nb= sp;            =             &nb= sp;        lo= a@pi.nu
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

--_000_C680C8102B400euddasiredbackcom_-- From root@core3.amsl.com Mon Jul 13 10:15:01 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E54A728C57A; Mon, 13 Jul 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713171501.E54A728C57A@core3.amsl.com> Date: Mon, 13 Jul 2009 10:15:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-p2mp-pw-requirements-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Requirements for Point-to-Multipoint Pseudowire Author(s) : L. Wang, F. JOUNAY, P. Niger, Y. Kamite, S. DeLord, L. Martini Filename : draft-ietf-pwe3-p2mp-pw-requirements-01.txt Pages : 20 Date : 2009-7-13 This document presents a set of requirements for providing an unidirectional Point-to-Multipoint PWE3 (Pseudowire Emulation Edge to Edge) emulation. The requirements identified in this document are related to architecture, signaling and maintenance aspects of a Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast services as defined in the Layer 2 Virtual Private Network working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-p2mp-pw-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-p2mp-pw-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-7-13100301.I-D@ietf.org> --NextPart-- From eric.gray@ericsson.com Mon Jul 13 10:47:05 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2A528C4D8; Mon, 13 Jul 2009 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FS1CMU2H0Zp; Mon, 13 Jul 2009 10:47:05 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 9AECF28C564; Mon, 13 Jul 2009 10:45:20 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6DHjdV6008536; Mon, 13 Jul 2009 12:45:48 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 12:45:48 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 12:45:47 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF0582BAA1@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <4A4A1EFA.6040101@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document Thread-Index: Acn5jfay7tOMHR47QAeTkJexeDlq8wKU8PJg References: <4A4A1EFA.6040101@pi.nu> From: "Eric Gray" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 13 Jul 2009 17:45:48.0161 (UTC) FILETIME=[C173FF10:01CA03E1] Subject: Re: [PWE3] [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 17:47:06 -0000 Support.=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, June 30, 2009 10:20 AM To: mpls@ietf.org; mpls-tp@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [CCAMP] poll to make draft-andersson-mpls-tp-process-03.txt a working group document All, we have an individual draft, draft-andersson-mpls-tp-process-03.txt, that describes additions to the mpls working group process to allow ITU-T to give input on MPLS-TP Internet Drafts. It pretty much captures current practice, and from the start we had no intention to ever progress, but recently there has been comments that it would have a better and clearer sttus if it were a working group document. We have had no plans to ever make it an RFC, but it has been pointed out that it would be possible to publish as an Historical RFC. Whether we execute on that or not is not yet decided. Therefore, is is to start at two week poll on making draft-andersson-mpls-tp-process-03.txt an MPLS working group document. The poll ends on July 14. Please send your comments to the mpls-tp list. Please --=20 Loa Andersson Sr Strategy and Standards Manager phone: +46 10 717 52 13 Ericsson /// +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From prvs=4386e2a23=euddasi@redback.com Mon Jul 13 13:57:16 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1E628C3A3 for ; Mon, 13 Jul 2009 13:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0dEu7SxZ6Sh for ; Mon, 13 Jul 2009 13:57:13 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 36B3828C3BA for ; Mon, 13 Jul 2009 13:57:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,392,1243839600"; d="scan'208,217";a="3467180" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 13 Jul 2009 13:57:44 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 52483CF90A6 for ; Mon, 13 Jul 2009 13:57:44 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32271-03 for ; Mon, 13 Jul 2009 13:57:44 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 3552ECF90A5 for ; Mon, 13 Jul 2009 13:57:44 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Mon, 13 Jul 2009 13:57:43 -0700 From: David Sinicrope To: "pwe3@ietf.org" Date: Mon, 13 Jul 2009 13:57:41 -0700 Thread-Topic: [PWE3] Time slots for IETF 75 PWE3 meeting Thread-Index: AcmO1f4o4AcNXYD1F0eyztRRXFz+YBkfWd+XAVqDghECz8b9CQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68118052B4B2euddasiredbackcom_" MIME-Version: 1.0 Subject: Re: [PWE3] Time slots for IETF 75 PWE3 meeting X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:57:16 -0000 --_000_C68118052B4B2euddasiredbackcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Below are the slot requests I've gotten to date. Please let me know if I'v= e missed any requests. The meeting is set for Monday 7/27 from 15:20-17:20 local time. Thanks, Dave - Inter-Chassis Communication Protocol for L2VPN PE Redundancy - http://too= ls.ietf.org/html/draft-ietf-pwe3-iccp-00 - Luca Martini - Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP - http= ://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-00 - Luca Martini - Pseudowire Status for Static Pseudowires - http://tools.ietf.org/html/dra= ft-martini-pwe3-static-pw-status-00 - Luca Martini - LDP Graceful Restart for Pseudowire - http://tools.ietf.org/html/draft-ji= ang-pwe3-ldp-gr-00 - Albert John - BT Requirements for MPLS-TP features - http://tools.ietf.org/html/draft-j= enkins-mpls-tp-bt-requirements-00 - Ben Niven-Jenkins - Requirements for Point-to-Multipoint Pseudowire - http://tools.ietf.org/h= tml/draft-ietf-pwe3-p2mp-pw-requirements-01 - Fred Jounay - LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire - http= ://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03 = - Fred Jounay - Point-to-Multipoint Pseudo-Wire Encapsulation - http://tools.ietf.org/htm= l/draft-raggarwa-pwe3-p2mp-pw-encaps-00 - Rahul Aggarwal - Ethernet PW Congestion Handling Mechanisms - http://tools.ietf.org/html/d= raft-stein-pwe3-ethpwcong-00 - Yaakov Stein On 6/29/09 9:28 AM, "David Sinicrope" wrote: Hi All, Below are the requests for time slots I have received to date. If you woul= d like a time slot for the PWE3 meeting during IETF 75, please send me the desired duration, topic/title, and presenter for each draft. The initial IETF agenda had conflicts with PWE3 and MPLS as well as PWE3 meeting on Friday. Matthew and Stewart are working out the meeting dates and times with the agenda folks. As soon as firm dates and times are obtained, I'll update the agenda with time slot durations. - WG Status - Stewart Bryant and Matthew Bocci - draft-ietf-pwe3-iccp-00.txt changes from previous version - Luca Martini - draft-martini-pwe3-p2mp-pw-00.txt presentation and discussion - Luca Martini - draft-martini-pwe3-static-pw-status-00.txt forthcoming pw status for static pws - Luca Martini - draft-jiang-pwe3-ldp-gr-00.txt - Albert John On 6/22/09 12:06 PM, "David Sinicrope" wrote: > Hi All, > Please let me know if you would like a time slot for the PWE3 meeting dur= ing > IETF 75. > I'll need the desired duration, topic/title, and presenter for each reque= st. > Thanks! > Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_C68118052B4B2euddasiredbackcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [PWE3] Time slots for IETF 75 PWE3 meeting Hi All,
Below are the slot requests I’ve gotten to date.  Please let me = know if I’ve missed any requests.
The meeting is set for Monday 7/27 from 15:20-17:20 local time.
Thanks,
Dave

- Inter-Chassis Communication Protocol for L2VPN PE Redundancy - http://tools.ietf.org/= html/draft-ietf-pwe3-iccp-00 - Luca Martini
- Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP - http://too= ls.ietf.org/html/draft-martini-pwe3-p2mp-pw-00 - Luca Martini
- Pseudowire Status for Static Pseudowires - http://tools.ietf.org/html/= draft-martini-pwe3-static-pw-status-00 - Luca Martini
- LDP Graceful Restart for Pseudowire - http://tools.ietf.org/html/draft-jiang-pwe3-= ldp-gr-00 - Albert John
- BT Requirements for MPLS-TP features - http://tools.ietf.org/html/dr= aft-jenkins-mpls-tp-bt-requirements-00 - Ben Niven-Jenkins
- Requirements for Point-to-Multipoint Pseudowire - http://tools.ietf.o= rg/html/draft-ietf-pwe3-p2mp-pw-requirements-01 - Fred Jounay
- LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire - http://tools.ietf.org/html/draft-jounay-niger-pwe3-source-initi= ated-p2mp-pw-03 - Fred Jounay
- Point-to-Multipoint Pseudo-Wire Encapsulation - http://tools.ietf.org/h= tml/draft-raggarwa-pwe3-p2mp-pw-encaps-00 - Rahul Aggarwal
- Ethernet PW Congestion Handling Mechanisms - http://tools.ietf.org/html/draft-s= tein-pwe3-ethpwcong-00 - Yaakov Stein



On 6/29/09 9:28 AM, "David Sinicrope" <euddasi@redback.com> wrote:

Hi All,
Below are the requests for time slots I have received to date.  If you= would
like a time slot for the PWE3 meeting during IETF 75, please send me the desired duration, topic/title, and presenter for each draft.  The init= ial
IETF agenda had conflicts with PWE3 and MPLS as well as PWE3 meeting on
Friday.  Matthew and Stewart are working out the meeting dates and tim= es
with the agenda folks.  As soon as firm dates and times are obtained, = I'll
update the agenda with time slot durations.

- WG Status - Stewart Bryant and Matthew Bocci
- draft-ietf-pwe3-iccp-00.txt changes from previous version - Luca Martini<= BR> - draft-martini-pwe3-p2mp-pw-00.txt presentation and discussion - Luca
Martini
- draft-martini-pwe3-static-pw-status-00.txt forthcoming pw status for
static pws - Luca Martini
- draft-jiang-pwe3-ldp-gr-00.txt - Albert John


On 6/22/09 12:06 PM, "David Sinicrope" <euddasi@redback.com> wrote:

> Hi All,
> Please let me know if you would like a time slot for the PWE3 meeting = during
> IETF 75.
> I’ll need the desired duration, topic/title, and presenter for e= ach request.
> Thanks!
> Dave

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org= /mailman/listinfo/pwe3

--_000_C68118052B4B2euddasiredbackcom_-- From annamaria.fulignoli@ericsson.com Tue Jul 14 12:57:32 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74CA63A69D1; Tue, 14 Jul 2009 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[AWL=-1.862, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jUgFjVU+VDd; Tue, 14 Jul 2009 12:57:31 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 000813A6826; Tue, 14 Jul 2009 12:57:29 -0700 (PDT) X-AuditID: c1b4fb24-b7b2fae000000abb-50-4a5cdf60c227 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C7.4C.02747.06FDC5A4; Tue, 14 Jul 2009 21:41:20 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jul 2009 09:36:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jul 2009 09:36:26 +0200 Message-ID: <93DFCD4B101EB440B5B72997456C5F9404012218@esealmw118.eemea.ericsson.se> In-Reply-To: <4A51D4A1.9010804@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making the mpls-tp process document a working group draft - update Thread-Index: Acn+JjvNTNPDXAdDRPOMS+fs628KAwGLwNlg References: <4A51D4A1.9010804@pi.nu> From: "Annamaria Fulignoli" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 14 Jul 2009 07:36:27.0907 (UTC) FILETIME=[CC41B530:01CA0455] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PWE3] [mpls-tp] poll on making the mpls-tp process document a working group draft - update X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 19:57:32 -0000 I support BR Annamaria -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Loa Andersson Sent: luned=EC 6 luglio 2009 12.41 To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: [mpls-tp] poll on making the mpls-tp process document a working = group draft - update All, I started this poll, but since I'm one of the authors of the document I = do not feel comfortable to judge the consensus on the poll. I have therefore asked our AD (Adrian Farrel) to step in and together = with George make the consensus call. /Loa Loa Andersson wrote: > > All, > > > > we have an individual draft, = draft-andersson-mpls-tp-process-03.txt, > > that describes additions to the mpls working group process to allow = > > ITU-T to give input on MPLS-TP Internet Drafts. > > > > It pretty much captures current practice, and from the start we had = no > > intention to ever progress, but recently there has been comments = that > > it would have a better and clearer sttus if it were a working = group > > document. > > > > We have had no plans to ever make it an RFC, but it has been = pointed > > out that it would be possible to publish as an Historical = RFC. Whether > > we execute on that or not is not yet decided. > > > > Therefore, is is to start at two week poll on making > > = draft-andersson-mpls-tp-process-03.txt an MPLS working group document. > > > > The poll ends on July 14. > > > > Please send your comments to the mpls-tp list. --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 8 632 77 14 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From rfc-editor@rfc-editor.org Tue Jul 14 14:55:19 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047D83A6826; Tue, 14 Jul 2009 14:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.802 X-Spam-Level: X-Spam-Status: No, score=-16.802 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqMgRYt15oXd; Tue, 14 Jul 2009 14:55:18 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 4051A3A66B4; Tue, 14 Jul 2009 14:55:18 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 7C1772ED0A7; Tue, 14 Jul 2009 14:51:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090714215130.7C1772ED0A7@bosco.isi.edu> Date: Tue, 14 Jul 2009 14:51:30 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5603 on Ethernet Pseudowire (PW) Management Information Base (MIB) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:55:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5603 Title: Ethernet Pseudowire (PW) Management Information Base (MIB) Author: D. Zelig, Ed., T. Nadeau, Ed. Status: Standards Track Date: July 2009 Mailbox: davidz@oversi.com, tom.nadeau@bt.com Pages: 23 Characters: 44125 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-enet-mib-14.txt URL: http://www.rfc-editor.org/rfc/rfc5603.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jul 14 14:56:12 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8BB3A6B70; Tue, 14 Jul 2009 14:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.81 X-Spam-Level: X-Spam-Status: No, score=-16.81 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BbBit-K4kVY; Tue, 14 Jul 2009 14:56:12 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 13C2C3A67E1; Tue, 14 Jul 2009 14:56:12 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 1A9432ED0AB; Tue, 14 Jul 2009 14:52:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090714215208.1A9432ED0AB@bosco.isi.edu> Date: Tue, 14 Jul 2009 14:52:08 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5605 on Managed Objects for ATM over Packet Switched Networks (PSNs) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:56:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5605 Title: Managed Objects for ATM over Packet Switched Networks (PSNs) Author: O. Nicklass, T. Nadeau Status: Standards Track Date: July 2009 Mailbox: orlyn@radvision.com, tom.nadeau@bt.com Pages: 36 Characters: 69401 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-pw-atm-mib-06.txt URL: http://www.rfc-editor.org/rfc/rfc5605.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jul 14 14:56:14 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DD13A6BC1; Tue, 14 Jul 2009 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.812 X-Spam-Level: X-Spam-Status: No, score=-16.812 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKSOvZdBpm43; Tue, 14 Jul 2009 14:56:13 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 062D93A67E1; Tue, 14 Jul 2009 14:56:13 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 19C0D2ED0A9; Tue, 14 Jul 2009 14:51:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090714215149.19C0D2ED0A9@bosco.isi.edu> Date: Tue, 14 Jul 2009 14:51:49 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5604 on Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:56:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5604 Title: Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) Author: O. Nicklass Status: Standards Track Date: July 2009 Mailbox: orlyn@radvision.com Pages: 41 Characters: 80002 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-tdm-mib-11.txt URL: http://www.rfc-editor.org/rfc/rfc5604.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jul 14 15:28:55 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4143A6ADD; Tue, 14 Jul 2009 15:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.819 X-Spam-Level: X-Spam-Status: No, score=-16.819 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTd2he-372iN; Tue, 14 Jul 2009 15:28:54 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 302553A69F4; Tue, 14 Jul 2009 15:28:54 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 785C52ED09E; Tue, 14 Jul 2009 14:50:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090714215040.785C52ED09E@bosco.isi.edu> Date: Tue, 14 Jul 2009 14:50:40 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5601 on Pseudowire (PW) Management Information Base (MIB) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:28:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5601 Title: Pseudowire (PW) Management Information Base (MIB) Author: T. Nadeau, Ed., D. Zelig, Ed. Status: Standards Track Date: July 2009 Mailbox: thomas.nadeau@bt.com, davidz@oversi.com Pages: 67 Characters: 129328 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-pw-mib-14.txt URL: http://www.rfc-editor.org/rfc/rfc5601.txt This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From rfc-editor@rfc-editor.org Tue Jul 14 15:46:17 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195143A6B9E; Tue, 14 Jul 2009 15:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.821 X-Spam-Level: X-Spam-Status: No, score=-16.821 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nnx3I8lzj1fh; Tue, 14 Jul 2009 15:46:16 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 1EFB23A67FA; Tue, 14 Jul 2009 15:46:16 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id DB1422ED0A0; Tue, 14 Jul 2009 14:50:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090714215056.DB1422ED0A0@bosco.isi.edu> Date: Tue, 14 Jul 2009 14:50:56 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 5602 on Pseudowire (PW) over MPLS PSN Management Information Base (MIB) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:46:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5602 Title: Pseudowire (PW) over MPLS PSN Management Information Base (MIB) Author: D. Zelig, Ed., T. Nadeau, Ed. Status: Standards Track Date: July 2009 Mailbox: davidz@oversi.com, tom.nadeau@bt.com Pages: 31 Characters: 62005 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-pw-mpls-mib-14.txt URL: http://www.rfc-editor.org/rfc/rfc5602.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From frederic.jounay@orange-ftgroup.com Wed Jul 15 08:22:14 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B10328C10F for ; Wed, 15 Jul 2009 08:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0F4-tWpCiKO for ; Wed, 15 Jul 2009 08:22:13 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 3913628C0F3 for ; Wed, 15 Jul 2009 08:22:13 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 17:21:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 17:21:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPLS 2009 Conference, Washington DC, October 25-28 Thread-Index: AcoBRAdJSDfnR90zTUSmpEzx31fl/wEGzRSg From: To: X-OriginalArrivalTime: 15 Jul 2009 15:21:29.0837 (UTC) FILETIME=[ED8419D0:01CA055F] Subject: [PWE3] MPLS 2009 Conference, Washington DC, October 25-28 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 15:22:14 -0000 Since many of the topics in the annual MPLS conference have been of interest to members of the PWE3 working group in the past, I wanted to share with you the fact that the conference program and registration has been announced, as detailed below. Fred. PROGRAM ANNOUNCEMENT AND REGISTRATION FOR MPLS 2009 - OCTOBER 25-28, WASHINGTON DC Registration for MPLS2009 (October 25-28, Omni Shoreham Hotel in Washington), the 12th annualInternational Conference on MPLS and related new technologies is now open at: http://www.isocore.com/mpls2009/registration/attendees.htm=20 MPLS 2009 will include an extensive four day program consisting of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year's conference include: Scaling MPLS, MPLS transport profile, Carrier Ethernet/MPLS deployments and experiences, Future technologies, Multicast and MPLS, Mobile and wireless backhaul, Resiliency, and OAM aspects, GMPLS, and emerging applications. The complete program is available at: http://www.isocore.com/mpls2009/program/technical_sessions.htm=20 The event will also have an exhibit floor, where leading network equipment manufacturers will showcase their new offerings, the list of current sponsors is available at: http://www.isocore.com/mpls2009/sponsors/sponsors.htm=20 The conference hotel is the Omni Shoreham Hotel in Washington DC. Please note that there are only a limited number of rooms available this year at a reduced rate. Reservations can be made at: http://www.isocore.com/mpls2009/hotel.htm =20 Isocore once again will showcase live the readiness of leading network technologies at the Public Interop demonstration on October 29 at Isocore Internetworking Lab. The details are available at - http://www.isocore.com/mpls2009/program/inter_op.htm.=20 From prvs=441d2caf9=euddasi@redback.com Thu Jul 16 09:36:00 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA5B3A6C7F for ; Thu, 16 Jul 2009 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAhcvY+1Dypb for ; Thu, 16 Jul 2009 09:35:59 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id BCBD53A6891 for ; Thu, 16 Jul 2009 09:35:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,412,1243839600"; d="scan'208,217";a="3560890" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 16 Jul 2009 09:14:59 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8943075BBB for ; Thu, 16 Jul 2009 09:14:59 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32645-08 for ; Thu, 16 Jul 2009 09:14:59 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 7785175BBE for ; Thu, 16 Jul 2009 09:14:59 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Thu, 16 Jul 2009 09:14:59 -0700 From: David Sinicrope To: "pwe3@ietf.org" Date: Thu, 16 Jul 2009 09:14:58 -0700 Thread-Topic: IETF 75 PWE3 Presentations Thread-Index: AcoGMJAk+772y8o3fka9CZDa+AaI9Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C684CA422B69Deuddasiredbackcom_" MIME-Version: 1.0 Subject: [PWE3] IETF 75 PWE3 Presentations X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 18:24:42 -0000 --_000_C684CA422B69Deuddasiredbackcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, The agenda for the PWE3 session has been posted. Presenters, please send m= e your presentations for posting as soon as you can. Thanks, Dave --_000_C684CA422B69Deuddasiredbackcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 75 PWE3 Presentations Hi All,
The agenda for the PWE3 session has been posted.  Presenters, please s= end me your presentations for posting as soon as you can.
Thanks,
Dave
 --_000_C684CA422B69Deuddasiredbackcom_-- From dai.xuehui@zte.com.cn Fri Jul 17 19:03:17 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93913A69A3 for ; Fri, 17 Jul 2009 19:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGYe7q2APs+4 for ; Fri, 17 Jul 2009 19:03:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 714B03A67A5 for ; Fri, 17 Jul 2009 19:02:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Sat, 18 Jul 2009 09:46:00 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 46629.1397396305; Sat, 18 Jul 2009 09:55:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6I20ZVq050997 for ; Sat, 18 Jul 2009 10:00:35 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Sat, 18 Jul 2009 10:00:19 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-18 10:03:01, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-18 10:03:01, Serialize complete at 2009-07-18 10:03:01, S/MIME Sign failed at 2009-07-18 10:03:01: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-18 10:00:33, Serialize complete at 2009-07-18 10:00:33 Content-Type: multipart/alternative; boundary="=_alternative 000B436B482575F7_=" X-MAIL: mse1.zte.com.cn n6I20ZVq050997 Subject: [PWE3] questions on cv types in X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2009 02:03:18 -0000 This is a multipart message in MIME format. --=_alternative 000B436B482575F7_= Content-Type: text/plain; charset="US-ASCII" hi,Nadeau and Pignataro: recently, I have read the draft-ietf-pwe3-vccv-bfd-06.txt, and have a question on cv types, please see the lines below: in section 3.3, it describes that: BFD CV Types used for fault detection and status signaling (i.e., CV Types 0x08 and 0x20) SHOULD NOT be used when a control protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available that can signal the AC/PW status to the remote endpoint of the PW. Can the author explain why these two cv types can't be used in the situations described above. I will apreciate for your answer. Regards Dai -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000B436B482575F7_= Content-Type: text/html; charset="US-ASCII"
hi,Nadeau and Pignataro:

recently, I have read the draft-ietf-pwe3-vccv-bfd-06.txt, and have a question on cv types, please see the lines  below:

in section 3.3, it describes that:

BFD CV Types used for fault detection and status signaling (i.e.,
CV Types 0x08 and 0x20) SHOULD NOT be used when a control
protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available
that can signal the AC/PW status to the remote endpoint of the
PW.

Can the author explain why these two cv types can't be used in the situations
described above.

I will apreciate for your answer.

Regards
Dai
 



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000B436B482575F7_=-- From javi@trajano.us.es Tue Jul 21 01:55:30 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F152728C10E for ; Tue, 21 Jul 2009 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB9Uq2lKbOgn for ; Tue, 21 Jul 2009 01:55:24 -0700 (PDT) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id B95793A6AF8 for ; Tue, 21 Jul 2009 01:55:23 -0700 (PDT) Received: (qmail 26610 invoked from network); 21 Jul 2009 10:55:14 +0200 Received: from unknown (HELO us.es) (192.168.2.13) by us.es with SMTP; 21 Jul 2009 10:55:14 +0200 Received: (qmail 32308 invoked by uid 507); 21 Jul 2009 08:55:12 -0000 Received: from localhost by antivirus3 (envelope-from , uid 501) with qmail-scanner-2.06 (clamdscan: 0.95.2/9593. Clear:RC:1(127.0.0.1):. Processed in 0.034592 secs); 21 Jul 2009 08:55:12 -0000 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 21 Jul 2009 08:55:11 -0000 Received: (qmail 21906 invoked from network); 21 Jul 2009 10:55:11 +0200 Received: from trajano.us.es (193.147.162.130) by us.es with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2009 10:55:11 +0200 Received: from [193.147.162.138] (trajano.us.es [193.147.162.130]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id n6L8tBet025059; Tue, 21 Jul 2009 10:55:11 +0200 Message-ID: <4A658287.9070407@trajano.us.es> Date: Tue, 21 Jul 2009 10:55:35 +0200 From: Javi User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [PWE3] HDLCPW L2TPv3 (RFC 4349): Transport of LAPD frames X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:55:31 -0000 Chapter 4.1: Data Packet Encapsulation Since all packets are passed in a largely transparent manner over the HDLCPW, any protocol that has HDLC-like framing may utilize the HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay transport), X.25 (LAPB), etc. I have read many times: "LAPD (derived from LAPB) is a subset of the HDLC structure, although it has extensions beyond HDLC" Which are these extensions?. In any case, may does HDLCPW mode be used to transport LAPD frames?. Why yes or not? Thanks Javier Muñoz _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From stbryant@cisco.com Tue Jul 21 06:16:00 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517FD28C2AB for ; Tue, 21 Jul 2009 06:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.592 X-Spam-Level: X-Spam-Status: No, score=-9.592 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtJXJV39MiBl for ; Tue, 21 Jul 2009 06:15:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DEBE328C2AA for ; Tue, 21 Jul 2009 06:15:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcAAPxbZUqQ/uCKe2dsb2JhbACZXwEBFiQGnmiBFAgBhwaPXAWEDIFF X-IronPort-AV: E=Sophos;i="4.43,240,1246838400"; d="scan'208";a="45516813" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2009 13:15:42 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6LDFgdc011016; Tue, 21 Jul 2009 15:15:42 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6LDFgjG007639; Tue, 21 Jul 2009 13:15:42 GMT Received: from dhcp-gpk02-vlan300-64-103-65-7.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n6LDFfD07868; Tue, 21 Jul 2009 14:15:41 +0100 (BST) Message-ID: <4A65BF7D.3060709@cisco.com> Date: Tue, 21 Jul 2009 14:15:41 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Javi References: <4A658287.9070407@trajano.us.es> In-Reply-To: <4A658287.9070407@trajano.us.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1035; t=1248182142; x=1249046142; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20HDLCPW=20L2TPv3=20(RFC=204349) =3A=20Transport=20of=20LAPD=20frames |Sender:=20; bh=2Y4SLFRD760fT3aRFGUJtnOATxd10AZ/kE+9FTZwQcI=; b=PpaUl5EPukG5A9go4aV4sxsFSgx1A0Xv/+AQLXWLergMuBF4gWgQqGl57X Zp+YNiURzwQgOg7GUsSrDEfypEdTTtIPVLKYvHCLlLzOdaH3ut3wEDUtUubS Qpl7uBGHbg; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] HDLCPW L2TPv3 (RFC 4349): Transport of LAPD frames X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:16:00 -0000 I am not sure how much LAPD there is still in existence. LAPD would look like any other HDLC packet to an HDLC PW. Stewart Javi wrote: > Chapter 4.1: Data Packet Encapsulation > > Since all packets are passed in a largely transparent manner over the > HDLCPW, any protocol that has HDLC-like framing may utilize the > HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay > transport), X.25 (LAPB), etc. > > > I have read many times: "LAPD (derived from LAPB) is a subset of the > HDLC structure, although it has extensions beyond HDLC" > > > Which are these extensions?. In any case, may does HDLCPW mode be used > to transport LAPD frames?. Why yes or not? > > > Thanks > > Javier Muñoz > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > From javi@trajano.us.es Tue Jul 21 09:38:11 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26133A6A93 for ; Tue, 21 Jul 2009 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTjaIKWaqKDp for ; Tue, 21 Jul 2009 09:38:10 -0700 (PDT) Received: from mail.us.es (mail.us.es [193.147.175.20]) by core3.amsl.com (Postfix) with ESMTP id 59AE43A6813 for ; Tue, 21 Jul 2009 09:38:09 -0700 (PDT) Received: (qmail 31723 invoked from network); 21 Jul 2009 18:38:06 +0200 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 21 Jul 2009 18:38:06 +0200 Received: (qmail 11042 invoked by uid 507); 21 Jul 2009 16:38:04 -0000 Received: from localhost by antivirus1 (envelope-from , uid 501) with qmail-scanner-2.06 (clamdscan: 0.95.2/9601. Clear:RC:1(127.0.0.1):. Processed in 0.051518 secs); 21 Jul 2009 16:38:04 -0000 Received: from localhost (HELO us.es) (127.0.0.1) by us.es with SMTP; 21 Jul 2009 16:38:04 -0000 Received: (qmail 7564 invoked from network); 21 Jul 2009 18:38:04 +0200 Received: from trajano.us.es (193.147.162.130) by us.es with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Jul 2009 18:38:04 +0200 Received: from [193.147.162.138] (trajano.us.es [193.147.162.130]) (authenticated bits=0) by trajano.us.es (8.13.8/8.13.8/Debian-3) with ESMTP id n6LGc3lG005777; Tue, 21 Jul 2009 18:38:04 +0200 Message-ID: <4A65EF06.8010503@trajano.us.es> Date: Tue, 21 Jul 2009 18:38:30 +0200 From: Javi User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: stbryant@cisco.com References: <4A658287.9070407@trajano.us.es> <4A65BF7D.3060709@cisco.com> In-Reply-To: <4A65BF7D.3060709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pwe3@ietf.org Subject: Re: [PWE3] HDLCPW L2TPv3 (RFC 4349): Transport of LAPD frames X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:38:11 -0000 Stewart Bryant escribió: > I am not sure how much LAPD there is still in existence. There are many reasons to support LAPD. For example, the accommodation of legacy PSTN/ISDN terminals and/or interworking with the PSTN/ISDN is an important consideration with respect to NGN deployment (ITU-T Y.2012) > > LAPD would look like any other HDLC packet to an HDLC PW. However, LAPD is not mentioned in RFC 4349 neither other document about HDLCPW. Does HDLCPW support these extensions of LAPD beyond HDLC? Javier Muñoz > > > Stewart > > > > Javi wrote: >> Chapter 4.1: Data Packet Encapsulation >> >> Since all packets are passed in a largely transparent manner over the >> HDLCPW, any protocol that has HDLC-like framing may utilize the >> HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay >> transport), X.25 (LAPB), etc. >> >> >> I have read many times: "LAPD (derived from LAPB) is a subset of the >> HDLC structure, although it has extensions beyond HDLC" >> >> >> Which are these extensions?. In any case, may does HDLCPW mode be >> used to transport LAPD frames?. Why yes or not? >> >> >> Thanks >> >> Javier Muñoz >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > From cpignata@cisco.com Wed Jul 22 07:36:33 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CBC3A69FA for ; Wed, 22 Jul 2009 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwVf2cjDDMKw for ; Wed, 22 Jul 2009 07:36:32 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 20E683A6850 for ; Wed, 22 Jul 2009 07:36:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6MEa0Kq015749; Wed, 22 Jul 2009 10:36:00 -0400 (EDT) Received: from [64.102.157.12] (dhcp-64-102-157-12.cisco.com [64.102.157.12]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6MEZwwv027973; Wed, 22 Jul 2009 10:35:59 -0400 (EDT) Message-ID: <4A6723CD.2020607@cisco.com> Date: Wed, 22 Jul 2009 10:35:57 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: dai.xuehui@zte.com.cn References: In-Reply-To: X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org Subject: Re: [PWE3] questions on cv types in X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:36:33 -0000 Hello Dai, Those two CV Types include status signaling, and SHOULD NOT be used in those situations because there is already a protocol that is used to perform status signaling, to avoid synchronization issues and race conditions from the control protocol's status messages and BFD messages both signaling fault status information. Note that the paragraph you quote ends with the following sentence also: ... PW. More details can be found in [I-D.ietf-pwe3-oam-msg-map]. And I think the relevant text is in Section 8.1 (and S8.1.3), at Thanks, -- Carlos. On 7/17/2009 10:00 PM, dai.xuehui@zte.com.cn wrote: > > hi,Nadeau and Pignataro: > > recently, I have read the draft-ietf-pwe3-vccv-bfd-06.txt, and have a > question on cv types, please see the lines below: > > in section 3.3, it describes that: > > BFD CV Types used for fault detection and status signaling (i.e., > CV Types 0x08 and 0x20) SHOULD NOT be used when a control > protocol such as LDP [RFC4447] or L2TPV3 [RFC3931] is available > that can signal the AC/PW status to the remote endpoint of the > PW. > > Can the author explain why these two cv types can't be used in the > situations > described above. > > I will apreciate for your answer. > > Regards > Dai > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From cpignata@cisco.com Wed Jul 22 07:49:30 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334763A6949; Wed, 22 Jul 2009 07:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iP9aKYBUH8S; Wed, 22 Jul 2009 07:49:29 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1E9853A698C; Wed, 22 Jul 2009 07:49:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6MEi9jW016295; Wed, 22 Jul 2009 10:44:09 -0400 (EDT) Received: from [64.102.157.12] (dhcp-64-102-157-12.cisco.com [64.102.157.12]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n6MEi8eY009201; Wed, 22 Jul 2009 10:44:09 -0400 (EDT) Message-ID: <4A6725B8.8090600@cisco.com> Date: Wed, 22 Jul 2009 10:44:08 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Javi References: <4A658287.9070407@trajano.us.es> <4A65BF7D.3060709@cisco.com> <4A65EF06.8010503@trajano.us.es> In-Reply-To: <4A65EF06.8010503@trajano.us.es> X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "PWE3 WG \(E-mail\)" , l2tpext mailing list , stbryant@cisco.com Subject: Re: [PWE3] HDLCPW L2TPv3 (RFC 4349): Transport of LAPD frames X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:49:30 -0000 [moving to since the reference of RFC4349] Javier, As Stewart answered, LAPD would look like any other HDLC packet to an HDLC PW. All the data (address (SAPI/TEI), control, etc) is opaque to the HDLC PW; flags and trailing FCS are stripped, and there rest is transported. Thanks, -- Carlos. On 7/21/2009 12:38 PM, Javi wrote: > Stewart Bryant escribió: >> I am not sure how much LAPD there is still in existence. > There are many reasons to support LAPD. For example, the accommodation > of legacy PSTN/ISDN terminals and/or interworking with the PSTN/ISDN > is an important consideration with respect to NGN deployment (ITU-T Y.2012) >> LAPD would look like any other HDLC packet to an HDLC PW. > However, LAPD is not mentioned in RFC 4349 neither other document about > HDLCPW. > Does HDLCPW support these extensions of LAPD beyond HDLC? > > Javier Muñoz >> >> Stewart >> >> >> >> Javi wrote: >>> Chapter 4.1: Data Packet Encapsulation >>> >>> Since all packets are passed in a largely transparent manner over the >>> HDLCPW, any protocol that has HDLC-like framing may utilize the >>> HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay >>> transport), X.25 (LAPB), etc. >>> >>> >>> I have read many times: "LAPD (derived from LAPB) is a subset of the >>> HDLC structure, although it has extensions beyond HDLC" >>> >>> >>> Which are these extensions?. In any case, may does HDLCPW mode be >>> used to transport LAPD frames?. Why yes or not? >>> >>> >>> Thanks >>> >>> Javier Muñoz >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > From prvs=448012ab9=euddasi@redback.com Thu Jul 23 04:18:19 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84643A68FF for ; Thu, 23 Jul 2009 04:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCaPMKwYeaHC for ; Thu, 23 Jul 2009 04:18:17 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id D59183A685F for ; Thu, 23 Jul 2009 04:18:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,254,1246863600"; d="scan'208,217";a="3779394" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 23 Jul 2009 04:18:03 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A1EB49858F3 for ; Thu, 23 Jul 2009 04:18:03 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30573-10 for ; Thu, 23 Jul 2009 04:18:03 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 8DE4F9858F2 for ; Thu, 23 Jul 2009 04:18:03 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Thu, 23 Jul 2009 04:18:03 -0700 From: David Sinicrope To: "pwe3@ietf.org" Date: Thu, 23 Jul 2009 04:17:59 -0700 Thread-Topic: PWE3 Agenda and Presenations Thread-Index: AcoLhzwVhrHAhDsWT0yDyJ7J5zfHmw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68DBF271D02euddasiredbackcom_" MIME-Version: 1.0 Subject: [PWE3] PWE3 Agenda and Presenations X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 11:21:18 -0000 --_000_C68DBF271D02euddasiredbackcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I've posted the PWE3 agenda last week. See http://tools.ietf.org/wg/pwe3/a= genda. If you are making a presentation, please send it to me to be posted as soon= as possible. Thanks! Dave --_000_C68DBF271D02euddasiredbackcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PWE3 Agenda and Presenations Hi All,
I’ve posted the PWE3 agenda last week.  See http://tools.ietf.o= rg/wg/pwe3/agenda.
If you are making a presentation, please send it to me to be posted as soon= as possible.
Thanks!
Dave --_000_C68DBF271D02euddasiredbackcom_-- From lmartini@cisco.com Fri Jul 24 05:59:00 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BED2E3A6836 for ; Fri, 24 Jul 2009 05:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAWgFkphcRIs for ; Fri, 24 Jul 2009 05:58:59 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id B64563A6C9B for ; Fri, 24 Jul 2009 05:58:47 -0700 (PDT) Received: from rasputin.monoski.com (bgp-ext.core.365-24.net [217.151.192.10]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n6OCvUCX019380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 06:57:34 -0600 (MDT) Message-ID: <4A69AFBA.2050205@cisco.com> Date: Fri, 24 Jul 2009 06:57:30 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: Olen Stokes References: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> In-Reply-To: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> Content-Type: multipart/alternative; boundary="------------030404080806060609020401" X-Scanned-By: MIMEDefang 2.63 on 67.41.208.110 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:59:00 -0000 This is a multi-part message in MIME format. --------------030404080806060609020401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Olen, Sorry for the delay in response , somehow i missed this e-mail. More below. Olen Stokes wrote: > I have the following questions on draft-martini-pwe3-iccp-01.txt: > > 1) In Section 4.1, it states that "the redundancy mechanism employed towards the access node/network can be one of a multitude of technologies". Are there any restrictions on the access network? In particular, are there any restrictions about a given packet reaching both PE1 and PE2 from the access network in Figure 1? If not, is it true that a packet received on a PW at PE1 and sent toward the access network may reach PE2 via the access network? > > How the packet is sent to the PE on the AC is not dependent on ICCP. THe protocol used i nthe access network will dictate how we choose the active link, and how we forward the packet. > 2) In Section 5.2, it states, "The RG will not become operational until the corresponding RG Connect Message has been received." If a single node comes up and does not receive any ICCP capable announcements, does it become operational? What if it has been configured that a second node is supposed to be present? If so, what happens when a second node later advertises that it is ICCP capable? Is the RG operational between the second capability announcement and the subsequent connect message? > > ok, It takes at least 2 nodes to have an RG become operational. So if one node comes up and there are no other PEs advertising that particular RG, the RG never becomes operational. The capability in LDP is only used to for an LSR to be allowed to send an RG connect message. The RG becomes operational only when both PEs have sent the RG connect messages. Sec 4.2 in draft-ietf-pwe3-iccp-01.txt is quite clear on the procedures. > 3) In Section 6, it states the following: > > - BFD > Run a BFD session [BFD] between the PEs that are members of a > given RG, and use that to detect PE node failure. This assumes > that resiliency mechanisms are in place to protect connectivity > to the remote PE nodes, and hence loss of BFD periodic messages > from a given PE node can only mean that the node itself has > failed. > > How is this guaranteed? There can be n-links between two interconnected PEs in a Redundancy Group. If the BFD session between the two PEs goes down, all that is really known is that the two PEs cannot communicate over those n-links. How does this guarantee that the remote PE is not forwarding access network data to the core network over other links? > > There are no guarantees against multiple failure events. We are protecting against a single failure , and all we are saying here is that the PEs MUST have really good connectivity between each other to almost exclude the possibility to loose communication between the PEs. > Take a Redundancy Group as shown in Figure 1 where PE1 and PE2 are H-VPLS MTU-s switches with connections to the core. Assume that they have dedicated interconnection with n-links. If somehow all n-interconnect links fail, then will not both nodes assume that the remote node has failed? If so, then it appears that a loop is very possible. Losing connection to the core after a large number of failures would seem to be a better alternative than any risk of a loop. > > yes. the split brain problem cannot be completely avoided. This is why it is very important that only if all possible connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated , no looping is possible, however the service might no longer work. In a typical application the two PEs are directly connected and co-located. > 4) Section 8.1.5 - It states that a PW Id TLV is "used to communicate the configuration of PWs for VPWS." Is there some reason that this cannot be used with a (H)VPLS? For example, there could be redundant MTUs that are connecting to a core group of PEs as discussed above. > > no - this is only terminology. We meant to say "For PW" . Of course H-VPLS with PW access is a valid application. > 5) Section 8.1.5 - There is a Peer ID field included in the TLV. What is the intent of the Peer ID? > this is defined as "Four octet LDP Router ID of the peer at the far end of the PW" This is necessary to uniquely identify the PW when using FEC 128. > 6) Are there any provisions for when an access network might segment with part of the access network still having connectivity to one PE while the remainder of the network has connectivity to the other PE? I realize that how this condition is recognized may be out of the scope of this document, but how the PEs communicate this condition could potentially be included. > > this would have to be handled by the access network protocol. It is out of scope of ICCP. Thanks. Luca > Thanks for your attention. > > Cheers, > Olen > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --------------030404080806060609020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Olen,
Sorry for the delay in response , somehow i missed this e-mail.

More below.

Olen Stokes wrote: 
I have the following questions on draft-martini-pwe3-iccp-01.txt:

1)      In Section 4.1, it states that "the redundancy mechanism employed towards the access node/network can be one of a multitude of technologies".  Are there any restrictions on the access network?  In particular, are there any restrictions about a given packet reaching both PE1 and PE2 from the access network in Figure 1?  If not, is it true that a packet received on a PW at PE1 and sent toward the access network may reach PE2 via the access network?
How the packet is sent to the PE on the AC is not dependent on ICCP. THe protocol used i nthe access network will dictate how we choose the active link, and how we forward the packet.





2)      In Section 5.2, it states, "The RG will not become operational until the corresponding RG Connect Message has been received."  If a single node comes up and does not receive any ICCP capable announcements, does it become operational?  What if it has been configured that a second node is supposed to be present?  If so, what happens when a second node later advertises that it is ICCP capable?  Is the RG operational between the second capability announcement and the subsequent connect message?
ok, It takes at least 2 nodes to have an RG become operational. So if one node comes up and there are no other PEs advertising that particular RG, the RG never becomes operational.
The capability in LDP is only used to for an LSR to be allowed to send an RG connect message. The RG becomes operational only when both PEs have sent the RG connect messages. Sec 4.2 in draft-ietf-pwe3-iccp-01.txt is quite clear on the procedures.


3)      In Section 6, it states the following:

- BFD
       Run a BFD session [BFD] between the PEs that are members of a
       given RG, and use that to detect PE node failure. This assumes
       that resiliency mechanisms are in place to protect connectivity
       to the remote PE nodes, and hence loss of BFD periodic messages
       from a given PE node can only mean that the node itself has
       failed.

How is this guaranteed?  There can be n-links between two interconnected PEs in a Redundancy Group.  If the BFD session between the two PEs goes down, all that is really known is that the two PEs cannot communicate over those n-links.  How does this guarantee that the remote PE is not forwarding access network data to the core network over other links?
There are no guarantees against multiple failure events. We are protecting against a single failure , and all we are saying here is that the PEs MUST have really good connectivity between each other to almost exclude the possibility to loose communication between the PEs.
Take a Redundancy Group as shown in Figure 1 where PE1 and PE2 are H-VPLS MTU-s switches with connections to the core.  Assume that they have dedicated interconnection with n-links.  If somehow all n-interconnect links fail, then will not both nodes assume that the remote node has failed?  If so, then it appears that a loop is very possible.  Losing connection to the core after a large number of failures would seem to be a better alternative than any risk of a loop.
yes. the split brain problem cannot be completely avoided.  This is why it is very important that only if all possible connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated , no looping is possible, however the service might no longer work.
In a typical application the two PEs are directly connected and co-located. 
4)      Section 8.1.5 - It states that a PW Id TLV is "used to communicate the configuration of PWs for VPWS."  Is there some reason that this cannot be used with a (H)VPLS?  For example, there could be redundant MTUs that are connecting to a core group of PEs as discussed above.
no - this is only terminology. We meant to say "For PW" . Of course H-VPLS with PW access is a valid application.
5)      Section 8.1.5 - There is a Peer ID field included in the TLV.  What is the intent of the Peer ID?
this is defined as "Four octet LDP Router ID of the peer at the far end of the PW"
This is necessary to uniquely identify the PW when using FEC 128.

6)      Are there any provisions for when an access network might segment with part of the access network still having connectivity to one PE while the remainder of the network has connectivity to the other PE?  I realize that how this condition is recognized may be out of the scope of this document, but how the PEs communicate this condition could potentially be included.
this would have to be handled by the access network protocol. It is out of scope of ICCP.

Thanks.
Luca

Thanks for your attention.

Cheers,
Olen







  

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

--------------030404080806060609020401-- From lucyyong@huawei.com Fri Jul 24 13:29:47 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C36528C18B for ; Fri, 24 Jul 2009 13:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox-aMec4iLwP for ; Fri, 24 Jul 2009 13:29:43 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 2A5563A6930 for ; Fri, 24 Jul 2009 13:29:43 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNA00KMAZKWMS@usaga02-in.huawei.com> for pwe3@ietf.org; Fri, 24 Jul 2009 13:29:20 -0700 (PDT) Received: from Y73674 ([10.124.12.139]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNA00CXIZKVQ0@usaga02-in.huawei.com> for pwe3@ietf.org; Fri, 24 Jul 2009 13:29:19 -0700 (PDT) Date: Fri, 24 Jul 2009 15:29:19 -0500 From: Lucy Yong To: 'Stewart Bryant' Message-id: <00be01ca0c9d$6c1d51a0$8b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_poHKiYtoYSCCQGX3bIh/uA)" Thread-index: AcoMnWuoMsMwbeQcTiS8/Tdj7hKKjA== Cc: pwe3@ietf.org Subject: [PWE3] comments about draft-bryant-pwe3-packet-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 20:29:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_poHKiYtoYSCCQGX3bIh/uA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Bryant, I have some comments about this version. 1) It is necessary to state that packet pw works under ms-pw. [ms-pw-arch] A packet pw can work under ms-pw, from client network perspective, a single link (PPP) is supported by the packet PW, from server network perspective, the packet PW may be constructed through multi-segment PW, i.e. each segment may use different PW label (pw demultiplexer) but no change on the control word. 2) A LSP in a server network can also be used as a data-link in a client network. It is good to provide some comparison in the draft. One advantage to use packet pw is that LSP only applies to single IGP domain while PW has MS-PW. Another is that PW solution provides a data-link encapsulation by using CW. LSP does not have such schema. 3) Some Typos: 1. Introduction: "either a MPLS network of a network conforming to the MPLS-TP." - should be "or a network" "the same data-link type MUST be to attach the clients to the PEs" - should be " MUST be used" "that two adjacent MPLS LSPs do not simply exchange MPSL packets" -should be "two client" Figure 4: title is not correct 8. Client Network Layer Model: "Network Layer adjacency . between client equipment will the follow normal .", -should be "will follow" Regards, Lucy --Boundary_(ID_poHKiYtoYSCCQGX3bIh/uA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Bryant,

 

I have some comments about this version.

 

1)     It is necessary to state that packet pw works under ms-pw. [ms-pw-arch]  A packet pw can work under ms-pw, from client network perspective, a single link (PPP) is supported by the packet PW, from server network perspective, the packet PW may be constructed through multi-segment PW, i.e. each segment may use different PW label (pw demultiplexer) but no change on the control word.

2)     A LSP in a server network can also be used as a data-link in a client network. It is good to provide some comparison in the draft. One advantage to use packet pw is that LSP only applies to single IGP domain while PW has MS-PW. Another is that PW solution provides a data-link encapsulation by using CW. LSP does not have such schema.

3)     Some Typos:

 

1. Introduction: “either a MPLS network of a network conforming to the MPLS-TP.” – should be “or a network”

                    “the same data-link type MUST be to attach the clients to the PEs” – should be “ MUST be used”

                    “that two adjacent MPLS LSPs do not simply exchange MPSL packets” –should be “two client”

Figure 4: title is not correct

8. Client Network Layer Model: “Network Layer adjacency … between client equipment will the follow normal …”, -should be “will follow”

 

Regards,

Lucy

 

 

 

--Boundary_(ID_poHKiYtoYSCCQGX3bIh/uA)-- From adrian@olddog.co.uk Sat Jul 25 06:15:08 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9273D3A6BED; Sat, 25 Jul 2009 06:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ75rKyLJy-d; Sat, 25 Jul 2009 06:15:07 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 9B3023A67FF; Sat, 25 Jul 2009 06:15:05 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n6PDELEP017414; Sat, 25 Jul 2009 14:14:26 +0100 Received: from your029b8cecfe (bgp-ext.core.365-24.net [217.151.192.10]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n6PDEJPb017408; Sat, 25 Jul 2009 14:14:20 +0100 Message-ID: From: "Adrian Farrel" To: Date: Sat, 25 Jul 2009 14:14:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: pwe3@ietf.org Subject: [PWE3] ACH TLV alignment X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:15:08 -0000 Hi, The inclusion of TLVs in ACH messages are defined in RFC 5586. This says... Note that the Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding is required for individual TLVs or sub-TLVs. As we work on draft-ietf-mpls-tp-gach-dcn we would like to check that everyone is happy with this. That is, are we all OK that TLVs and sub-TLVs in ACH messages (typically handled in hardware) will not be 32-bit aligned. Silence is, I think, consent in this instance since it will represent following the status quo. Cheers, Adrian From stbryant@cisco.com Sat Jul 25 06:17:29 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127C93A6BED for ; Sat, 25 Jul 2009 06:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4TL-4Ilhyyu for ; Sat, 25 Jul 2009 06:17:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B156F3A67FF for ; Sat, 25 Jul 2009 06:17:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYAADKiakqQ/uCKe2dsb2JhbACZeAEBFiQGnwGBFAgBhwmPdAWEDIFM X-IronPort-AV: E=Sophos;i="4.43,268,1246838400"; d="scan'208";a="45826027" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2009 13:15:47 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6PDFlC5023452; Sat, 25 Jul 2009 15:15:47 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6PDFlQQ029723; Sat, 25 Jul 2009 13:15:47 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n6PDFkD21797; Sat, 25 Jul 2009 14:15:46 +0100 (BST) Message-ID: <4A6B0582.9090803@cisco.com> Date: Sat, 25 Jul 2009 14:15:46 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Lucy Yong References: <00be01ca0c9d$6c1d51a0$8b0c7c0a@china.huawei.com> In-Reply-To: <00be01ca0c9d$6c1d51a0$8b0c7c0a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1816; t=1248527747; x=1249391747; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20comments=20about=20draft-bryant-pwe3-pa cket-pw-01.txt |Sender:=20; bh=WEnzQxckrOpDRvLkLNIna8c1vy4Vy7CO9XSAkVD832A=; b=aUib+d2OG2Tmt36vdQgkABeWVNk3W4V3e9Gc9q2YvHRCyAZ+KrAA5t5tFS Mijs8D/zHexuAuulRpHE/tlYmBwglwqOtt+TB0mhAifGThaXOzVZLLQbWiXN 2o6aJYGwG/; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: pwe3@ietf.org Subject: Re: [PWE3] comments about draft-bryant-pwe3-packet-pw-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 13:17:29 -0000 Lucy > > Hi Bryant, > > I have some comments about this version. > > 1) It is necessary to state that packet pw works under ms-pw. > [ms-pw-arch] A packet pw can work under ms-pw, from client network > perspective, a single link (PPP) is supported by the packet PW, from > server network perspective, the packet PW may be constructed through > multi-segment PW, i.e. each segment may use different PW label (pw > demultiplexer) but no change on the control word. > Strictly it's not necessary to state this, since MS-PW MUST be able to carry any PW without change to the PW encapsulation. However we can add the clarification. > > 2) A LSP in a server network can also be used as a data-link in a > client network. It is good to provide some comparison in the draft. > One advantage to use packet pw is that LSP only applies to single IGP > domain while PW has MS-PW. Another is that PW solution provides a > data-link encapsulation by using CW. LSP does not have such schema. > I need to think about this some more, particularly in the light of some of the discussions that are taking place regarding MPLS-TP and clients. One way or another we will address this in the next version. > > 3) Some Typos: > > 1. Introduction: “either a MPLS network of a network conforming to the > MPLS-TP.” – should be “or a network” > > “the same data-link type MUST be to attach the clients to the PEs” – > should be “ MUST be used” > > “that two adjacent MPLS LSPs do not simply exchange MPSL packets” > –should be “two client” > > Figure 4: title is not correct > > 8. Client Network Layer Model: “Network Layer adjacency … between > client equipment will the follow normal …”, -should be “will follow” > > Thanks -we will fix that. Thanks for the comments Stewart From nitinb@juniper.net Sat Jul 25 11:48:57 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710A43A6820; Sat, 25 Jul 2009 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EzWur3JfjBm; Sat, 25 Jul 2009 11:48:56 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 772043A67DA; Sat, 25 Jul 2009 11:48:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSmtTl71LzFpoOejgVhhsvfeSYbxrhau2@postini.com; Sat, 25 Jul 2009 11:48:57 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Sat, 25 Jul 2009 11:43:11 -0700 From: Nitin Bahadur To: Adrian Farrel , "mpls-tp@ietf.org" Date: Sat, 25 Jul 2009 11:44:12 -0700 Thread-Topic: [mpls-tp] ACH TLV alignment Thread-Index: AcoNKfFcBTU8C6dPS7OPnsSKjF2HYAALfWAA Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] [mpls-tp] ACH TLV alignment X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 18:48:57 -0000 TLVs and sub-TLVs MUST be 32-bit aligned. Nitin On 7/25/09 6:14 AM, "Adrian Farrel" wrote: Hi, The inclusion of TLVs in ACH messages are defined in RFC 5586. This says... Note that the Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding is required for individual TLVs or sub-TLVs. As we work on draft-ietf-mpls-tp-gach-dcn we would like to check that everyone is happy with this. That is, are we all OK that TLVs and sub-TLVs in ACH messages (typically handled in hardware) will not be 32-bit aligned. Silence is, I think, consent in this instance since it will represent following the status quo. Cheers, Adrian _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From stbryant@cisco.com Sat Jul 25 14:01:14 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7A43A6858; Sat, 25 Jul 2009 14:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.337 X-Spam-Level: X-Spam-Status: No, score=-10.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXwSC0wQJg4k; Sat, 25 Jul 2009 14:01:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 870E43A681D; Sat, 25 Jul 2009 14:01:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAC8Pa0qQ/uCKe2dsb2JhbACZeQEBFiQGnHmBFAgBhwuPLQWEDYFN X-IronPort-AV: E=Sophos;i="4.43,270,1246838400"; d="scan'208";a="45835803" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2009 21:01:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6PL1Cl8014760; Sat, 25 Jul 2009 23:01:12 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6PL1CvU016352; Sat, 25 Jul 2009 21:01:12 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n6PL1CD06539; Sat, 25 Jul 2009 22:01:12 +0100 (BST) Message-ID: <4A6B7298.8030205@cisco.com> Date: Sat, 25 Jul 2009 22:01:12 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=229; t=1248555672; x=1249419672; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20[mpls-tp]=20ACH=20TLV=20alignm ent |Sender:=20; bh=0ej8m8FJI/967ulRKN5boRmVpEwxvrNr5YfMh4Qck8k=; b=uVShNElzqYzIg7pXqtCoLTRfK1jUIOtnDlj1aUyzhBRqdcJID82xC/KYcv iI9PHOVy0vNO3xAnkBlVrIY6K4LrXRX6zMRG5iBsJD5MVRZhDUVmSNRhZ+Z+ t4gv+u8kn3; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [PWE3] [mpls-tp] ACH TLV alignment X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 21:01:15 -0000 I originally thought this but it was pointed out packets received from an Ethernet do not preserve the 32bit alignment. - Stewart Nitin Bahadur wrote: > TLVs and sub-TLVs MUST be 32-bit aligned. > > Nitin > > From nitinb@juniper.net Sat Jul 25 16:37:29 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D683A6810; Sat, 25 Jul 2009 16:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiZ3SNO--5jz; Sat, 25 Jul 2009 16:37:28 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 2B7BA3A6774; Sat, 25 Jul 2009 16:37:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSmuXNtOcsi53ib971vg1APrhUKV/R4Za@postini.com; Sat, 25 Jul 2009 16:37:29 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Sat, 25 Jul 2009 16:34:50 -0700 From: Nitin Bahadur To: "stbryant@cisco.com" Date: Sat, 25 Jul 2009 16:35:52 -0700 Thread-Topic: [PWE3] [mpls-tp] ACH TLV alignment Thread-Index: AcoNawyiwIiBcemST9C42Hzxl33yUQAFZkIw Message-ID: In-Reply-To: <4A6B7298.8030205@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [PWE3] [mpls-tp] ACH TLV alignment X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 23:37:29 -0000 But the TLV and sub-TLV by itself should have a 4-byte boundary size. What I meant was that one should not allow a 5-byte sub-TLV. That Sub-tlv s= hould Be padded to 8-bytes. Maybe that was not the intention of Adrian's question. Nitin On 7/25/09 2:01 PM, "Stewart Bryant" wrote: I originally thought this but it was pointed out packets received from an Ethernet do not preserve the 32bit alignment. - Stewart Nitin Bahadur wrote: > TLVs and sub-TLVs MUST be 32-bit aligned. > > Nitin > > From stbryant@cisco.com Sun Jul 26 11:56:52 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FB03A6B45 for ; Sun, 26 Jul 2009 11:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD0DzLBZoexG for ; Sun, 26 Jul 2009 11:56:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 867AE3A6A31 for ; Sun, 26 Jul 2009 11:56:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAAGJDbEqQ/uCLe2dsb2JhbACZewEBFiQGm2WBFAgBhwuNXgWEDQ X-IronPort-AV: E=Sophos;i="4.43,272,1246838400"; d="scan'208";a="45859854" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2009 18:56:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6QIupgO030036 for ; Sun, 26 Jul 2009 20:56:51 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6QIuoZr002123 for ; Sun, 26 Jul 2009 18:56:50 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n6QIulD12103; Sun, 26 Jul 2009 19:56:48 +0100 (BST) Message-ID: <4A6CA6EF.9030306@cisco.com> Date: Sun, 26 Jul 2009 19:56:47 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=330; t=1248634611; x=1249498611; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Remote=20participation=20at=20IETF |Sender:=20; bh=FXI+xZFOlfh0fRX7hdso8OhOsAvarVJdlgtWyxPEYf4=; b=G9fZDl986NlVIgB03YKVJPlxjgYPXc51QP72I3MSNYE8JjNyjltFqF3VIx SqI72P5c5VRjcNWIBDXv2MQWzG4sSL2R2DM0ma2aAv8f0K7lYa4rqJ+ANeg1 yXPI/quw/k; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [PWE3] Remote participation at IETF X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 18:56:52 -0000 For those members of the WG that need to remotely participate in the WG discussions tomorrow, pointers to the audio and jabber can be found here: http://tools.ietf.org/agenda/75/ We will have some one watching the jabber and will take remote questions and comments back to the floor via the jabber system. - Stewart From prvs=45136c93f=euddasi@redback.com Sun Jul 26 13:18:06 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0E53A69A9 for ; Sun, 26 Jul 2009 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG+rQMzpGPzn for ; Sun, 26 Jul 2009 13:18:06 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id F32213A68C2 for ; Sun, 26 Jul 2009 13:18:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,272,1246863600"; d="scan'208";a="3866298" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 26 Jul 2009 13:18:07 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 62662767F41 for ; Sun, 26 Jul 2009 13:18:07 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02681-07 for ; Sun, 26 Jul 2009 13:18:07 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 51674767F40 for ; Sun, 26 Jul 2009 13:18:07 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Sun, 26 Jul 2009 13:18:07 -0700 From: David Sinicrope To: "pwe3@ietf.org" Date: Sun, 26 Jul 2009 13:18:06 -0700 Thread-Topic: PWE3 presentations Thread-Index: AcoOLi+Tm2BdbYKqQqW3fwU/eYTu1Q== Message-ID: <8D0494A4-C1DC-439F-B993-2AE3A90BBDFD@redback.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] PWE3 presentations X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 20:20:56 -0000 Hi All, I'm still missing several presentations for Mondays session. Please =20 send them as soon as possible. Thanks, Dave ------------------ David Sinicrope From root@core3.amsl.com Mon Jul 27 06:00:01 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D6F513A6994; Mon, 27 Jul 2009 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090727130001.D6F513A6994@core3.amsl.com> Date: Mon, 27 Jul 2009 06:00:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-vccv-bfd-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 13:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, C. Pignataro Filename : draft-ietf-pwe3-vccv-bfd-07.txt Pages : 14 Date : 2009-07-27 This document describes Connectivity Verification (CV) types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-bfd-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27054715.I-D@ietf.org> --NextPart-- From frederic.jounay@orange-ftgroup.com Mon Jul 27 08:20:36 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52223A6A7B for ; Mon, 27 Jul 2009 08:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2zYMi3ZUT3B for ; Mon, 27 Jul 2009 08:20:36 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id A29E13A6898 for ; Mon, 27 Jul 2009 08:20:35 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 17:20:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0ECD.C926C7C7" Date: Mon, 27 Jul 2009 17:20:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2MP PW REQ Stockholm discussion Thread-Index: AcoOzciyWqB8Q3nCTDyB37IcqRQ20Q== From: To: X-OriginalArrivalTime: 27 Jul 2009 15:20:35.0005 (UTC) FILETIME=[C9CA66D0:01CA0ECD] Subject: [PWE3] P2MP PW REQ Stockholm discussion X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 15:20:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0ECD.C926C7C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As explained during my presentation, the P2MP REQ draft has still a few open issues. Please let us know your thoughts about the following topics: 1\ P2MP PW MAY be bidirectional.=20 Initially this requirement is optional , since that does not address most of applications we get in mind (see VPMS draft). But please let us know if there are some reasons to consider this feature as mandatory 2\ Leaf attachment acknoledgement (so from the leaf to the root).=20 The Egress PE ack to the root is necessary for at least both reasons=20 - RSVP-TE P2MP LSP as underlying Layer: the root PE can update/extend the P2MP TE-LSP accordingly=20 - RSVP-TE or MLDP LSP as underlying Layer: multiplexing rules of P2MP PW/P2MP LSP (mapping 1:1 to N:1) However this ack does not represent exactly the leaves of the PW tree since the Egress PE may deliver the traffic to more than one attached AC (see Reference Model). We request the AC ack from the Ingress PE to the Egress PE for NMS purpose but that can be also relevant for specific protection scheme per AC.=20 Once more let us know your opinion=20 Thanks, Fred ------_=_NextPart_001_01CA0ECD.C926C7C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable P2MP PW REQ Stockholm discussion

Hi all,

As explained during my presentation, = the P2MP REQ draft has still a few open issues.
Please let us know your thoughts about = the following topics:

1\ P2MP PW MAY be bidirectional. =
Initially this requirement is optional = , since that does not address most of applications we get in mind (see = VPMS draft). But please let us know if there are some reasons to = consider this feature as mandatory

2\ Leaf attachment acknoledgement (so = from the leaf to the root).
The Egress PE ack to the root is = necessary for at least both reasons
        - RSVP-TE P2MP LSP as underlying Layer: the root PE can = update/extend the P2MP TE-LSP accordingly
        - RSVP-TE or MLDP LSP as underlying Layer: multiplexing = rules of P2MP PW/P2MP LSP (mapping 1:1 to N:1)
However this ack does not represent = exactly the leaves of the PW tree since the Egress PE may deliver the = traffic to more than one attached AC (see Reference Model).

We request the AC ack from the Ingress = PE to the Egress PE for NMS purpose but that can be also relevant for = specific protection scheme per AC.

Once more let us know your opinion =

Thanks,
Fred

------_=_NextPart_001_01CA0ECD.C926C7C7-- From Jonathan.Sadler@tellabs.com Mon Jul 27 09:59:19 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D257228C31D for ; Mon, 27 Jul 2009 09:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHihqVy97irC for ; Mon, 27 Jul 2009 09:59:18 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id EDFEE3A6C0E for ; Mon, 27 Jul 2009 09:58:57 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.43,277,1246838400"; d="scan'208,217";a="1291200522" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 27 Jul 2009 16:58:59 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Mon, 27 Jul 2009 11:58:59 -0500 From: "Sadler, Jonathan B." To: "lmartini@cisco.com" Date: Mon, 27 Jul 2009 11:58:59 -0500 Thread-Topic: ICCP draft and mLACP Thread-Index: AQHKDtuIpltLBHeWQkq69fp1WtMxhw== Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50@EX-NAP.tellabs-west.tellabsinc.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50EXNAPtellabsw_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" , Tony Jeffree , "stbryant@cisco.com" Subject: [PWE3] ICCP draft and mLACP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:59:19 -0000 --_000_5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50EXNAPtellabsw_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Luca, At PWE3 today, you asked the question if the technology specific details in= the ICCP draft (found at http://tools.ietf.org/html/draft-ietf-pwe3-iccp-0= 0) should be split out from the base document. I indicated my support for = a split and wanted to let you know my reasoning. Within the last 2-3 years, IEEE has identified that 802.3ad doesn't have a = requirement to be bound to Ethernet, nor does it need to be bound to a sing= le-node to single-node deployment. This has led to the agreement that work= on LAG be moved from 802.3 and into 802.1. As a result of the move in res= ponsibility, 802.3 has removed clause 43 from the 802.3 specification, and = 802.1 has placed the text into its own document: 802.1AX-2008. Extensions = to 802.1AX for Multi-Chassis LAG, etc. are expected to be developed for thi= s document. While the work on Multi-Chassis LAG (i.e. allowing LAG to operate in a mult= i-homed configuration as shown in the ICCP draft) is still on the "todo" li= st in 802.1 for 802.1AX, it requires essentially the same sort of informati= on that has been included in section 7.2 of the ICCP draft. Defining the p= rotocol to carry this information (e.g extensions to LDP/development of ICC= P) can be stated as something IETF is a master of, but the required data fo= r the application and NE behaviours are probably best co-developed with IEE= E=2E Not only would this get the correct experts involved in the developme= nt, it would allow for commonality with a non-MPLS based solution. By placing the technology specific bits into a separate I-D, the base ICCP = draft has any encumbrance removed and can progress quickly. If IEEE is not= interested in developing multi-chassis then I can understand IETF progress= ing the mLACP application work independantly. However, it would be bad (in= my mind) to have duplicate work done in IETF (developing an MPLS specific = solution) and in IEEE (developing an general Ethernet spec). I hope this helps. Jonathan Sadler =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50EXNAPtellabsw_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello L= uca,
 
At PWE3 today, you asked = the question if the technology specific details in the ICCP draft= (found at http://tools= .ietf.org/html/draft-ietf-pwe3-iccp-00) should be split out from the ba= se document.  I indicated my support for a split and wanted to le= t you know my reasoning.
 
Within the last 2-3 years= , IEEE has identified that 802.3ad doesn't have a requirement to be bound t= o Ethernet, nor does it need to be bound to a single-node to single-node de= ployment.  This has led to the agreement that work on LAG be moved from 802.3 and into 802.1.&n= bsp; As a result of the move in responsibility, 802.3 has removed = ;clause 43 from the 802.3 specification, and 802.1 has placed the text= into its own document: 802.1AX-2008.  Extensions to 802.1AX for = Multi-Chassis LAG, etc. are expected to be developed for this document.
 
While the work on Multi-C= hassis LAG (i.e. allowing LAG to operate in a multi-homed configuration as = shown in the ICCP draft) is still on the "todo" list in 802.1 for= 802.1AX, it requires essentially the same sort of information that has been included in section 7.2 of the ICCP draft.&nb= sp; Defining the protocol to carry this information (e.g extensions to=  LDP/development of ICCP) can be stated as something IETF is a master = of, but the required data for the application and NE behaviours are probably best co-developed with IEEE.  Not only&n= bsp;would this get the correct experts involved in the development, it= would allow for commonality with a non-MPLS based solution.=
 
By placing the techn= ology specific bits into a separate I-D, the base ICCP draft has any e= ncumbrance removed and can progress quickly.  If IEEE is not intereste= d in developing multi-chassis then I can understand IETF progressing the mLACP application work independantly.  However, = it would be bad (in my mind) to have duplicate work done in IETF (developin= g an MPLS specific solution) and in IEEE (developing an gene= ral Ethernet spec).
 
I hope this helps.=
 
Jonathan Sadler
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--_000_5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50EXNAPtellabsw_-- From dai.xuehui@zte.com.cn Mon Jul 27 18:21:39 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7BF93A69EB for ; Mon, 27 Jul 2009 18:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFUUa-MXo0xp for ; Mon, 27 Jul 2009 18:21:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 5F0D43A69CD for ; Mon, 27 Jul 2009 18:21:37 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641397396305; Tue, 28 Jul 2009 09:03:10 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 12290.3613950687; Tue, 28 Jul 2009 09:13:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6S1LNWb015146; Tue, 28 Jul 2009 09:21:23 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) To: lmartini@cisco.com, swallow@cisco.com, Matthew.Bocci@alcatel-lucent.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Tue, 28 Jul 2009 09:20:44 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 09:24:13, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 09:24:13, Serialize complete at 2009-07-28 09:24:13, S/MIME Sign failed at 2009-07-28 09:24:13: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 09:21:20, Serialize complete at 2009-07-28 09:21:20 Content-Type: multipart/related; boundary="=_related 0007B62A48257601_=" X-MAIL: mse2.zte.com.cn n6S1LNWb015146 Cc: "pwe3@ietf.org" Subject: [PWE3] one question on X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 01:21:40 -0000 This is a multipart message in MIME format. --=_related 0007B62A48257601_= Content-Type: multipart/alternative; boundary="=_alternative 0007B62A48257601_=" --=_alternative 0007B62A48257601_= Content-Type: text/plain; charset="US-ASCII" hi,martini: yestody,I saw your draft(draft-martini-pwe3-static-pw-status-01),and also your presectation file about this draft on IETF 75.Then,I find a difference on PW OAM message packet header. in draft-martini-pwe3-static-pw-status-01,It id defined as below: 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 | 0xZZ PW OAM Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh Timer | TLV Length |A| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH PW OAM Message Packet Header. But, in your presentation file ,it has a diffrent format,that is: Redards, Dai -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0007B62A48257601_= Content-Type: text/html; charset="US-ASCII"
hi,martini:

yestody,I saw your draft(draft-martini-pwe3-static-pw-status-01),and also your presectation file about this draft on IETF 75.Then,I find a difference on PW OAM message packet header.

in draft-martini-pwe3-static-pw-status-01,It id defined as below:
  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    | 0xZZ PW OAM Message           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         ACH TLV Header                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Refresh Timer         |  TLV Length   |A|   Flags     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                            TLVs                               ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 1: ACH PW OAM Message Packet Header.
But, in your presentation file ,it has a diffrent format,that is:

 
Redards,
Dai
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0007B62A48257601_=-- --=_related 0007B62A48257601_= Content-Type: image/gif Content-ID: <_1_05C9513005C94E800007B62948257601> Content-Transfer-Encoding: base64 R0lGODlhMwL8AOcAAAAAAPgAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAMwL8AEAI/wAFCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iTKl1qEQBBp0yPQo1adCpVqVezat3KtavXrwmtWkU41uDUsk8H oj24VqBYhWcZtnWbtuHctwvnCogbVq3Du3XJ+s1LeHDhvoYRKwZM1y7cwGwTC34sebLlvY7Bat7M ubPnzxL1Vr5MObPcv6hNH15dmrVi169by45Nm3TtyKpn275tNvXp3LwLihZaFoBxvceRHwd+1rhb 5xmH76aYXLpJ6CCHJ8+7fW93tt+XL/8Pi/25WufjzaIvDzqkdZ8BMMcXOJ9h/YX3FdbfL38gf/r+ BQjggAL8V6CABxIY33v4IWjggw5GqKCEIC1oH4UQEphQhgkixKGB+mEo4oQkdpjfVhaeiJR0LPr2 24uw4QajbjLG2Btw09VI440zBgfZjsK5COSPQ46mo49G8mgjUfE1GeB9TvIH5YFSEhTlkyZ2SGWW UzoJYJdcWrnll2J6uWWVWKJJpppnYpmmm2u+SaacY8Y5p511tnmnnnya2aeWV+4ZaJ6D+llonYYi CqiiYLJ5aKN0Jurniu1VmhZfQTa2WnFEBgbVd95hJ9550K3HoKVYUaUiqpx9iGCDJYL/uOGIWcb6 KqtfrUopjkfmqGSRmi7Zaa/E/opksMAieyxmvBrr67DOFptpj8u22Oy0wiaJ67bcduvttxGdilN3 1eFVWbnPlYdpbXx9Gup44uYUL7KcMksbupo6ZW699l6Elr7QUtcvvdvtm95J84Kr8MIMN7yVtdRK i22yEGer7LPaBqxxxhtfLDHHHkcr8sTVCkmxyRiHTHLKDrfs8ssw/5RwzDTXzPDMNues884893zz WKOa59fBPhdt9NFIJ90yzko37bRPTD8t9dRUJ8UhrVjbWmLWtWqptZhbfy1r1yde/TXXrmp49tpk G2R222HDDXbXaFNI69hv520322l7/0131eGCPBLRgRuGKWPMrssj0MLpe5fjNyl+bcf2zhs14Kxe qXmBAGzueZu6Ruq326CXHrrpo5eJ+qCzfu766lR2XnqIr9cO++m35247nZj37vvvwAcv/PDEF2/8 8cgnr/zyzDfvvPDm/k5475IDXj2uk/6eve/bY876ttGzPLCP7p5ceI2Ij5+YaNZVjBtyKNsYPmTp s/+Q+zfCP3mx86//mnafwZ3aZtUQAaaOdAV0iAENeMCCLFCBEEygBC80QVhRsIIhwiABL2jBDmaQ gx/0YAi5gj+WtS9+I6NcCT+mMhWiMIWCWyEMWxjDF7rQhjXcHw13qL7n+fCHymNckv/6Fyz7Tax8 7yoVeNgTPSQSkTrpwVd4qnOx8kmRcgLb1HmOxL6DAawtQsRMXADWFzJK0YtRJFdd8NWVywHxjXA0 mgxXxkIezvGGEZthD/V4RzxabI905CMO7ThIQuoQkH5MVhwXyUikuXGRhxvM9bC1LvbIiIzTQs8W 1fdIH3aykaAMJbj6aMhDkhKROcxjIFeZSPOpspUmLOQpT2hKWdoyKp9UCRXlYsnQaIeNqGzjRMrl uOZ8qpehGlwn/xXG6OzSO8SJSoqO0rdq3s2C1mTbUCwkkWxi85piu5VFpjlAcmLEm307iTmXMstC BvOd7aylPF8pOHjekp6l/GM856n/z3v+8SePUp2jGCVQ0UFKUAQ1aEERaqaAKvSheJJUmBQ60IYu yqIHJVRCI7rRP2VUohWdKEcxulCNkhSiHi2pQ/GUlFyK8qUKc6lLGAjTmuaMplBDok2vQzInYnGn LVEiUIdKVG/JtKhIBctRk8rUpo4LXVCNasGkKh6qloqYu8RqVrUKL65e1avpmqpYx2oqshbTrEks q1rXGlatthWrbyVmXM8I1rSeda13zWte7ZpWvlqVrXalK1fnutW6evWraJWrUxfL2B+C0X/5UhaD LCfUxc3mi7ExpqdKg8l7FbFfOnXNW9aCSdL6prP+w4tpG8va1rr2tbCNrWxnS9va/9r2trjNrW53 y9ve+va3wA2ucIdL3OIa941PtJ7xlro05kpleph7pvSgWzXqHve62OUOMlmZTO3+RTnWTRd5QKWe 7ZIKvAD0rnp5qV3zipcs0i0vennpXhqGt7vshQt5lzhe6+63ce79bx1xubH0vhCYQJpkwJKbxP/h 8z2PE/DIFKyt5MaXkg+GSITvqzIKd3jBEmYwD6UZQRBuMHRjmxuKxaniD57ugRr0UIm/eWIX27jG ON6gCGUc44PAuIEp3psDWSzkFo8wu0j+7T7/uWRX9pOfTn4yPu0J5ZJV2cpTbvKygqJl8XW5jl8W 5JVjOWYxZ9mfigwzd/OpSPh0dP+lKaUonOI8UpVeVKQpDame5wznPhN0zwzFs59PWmdAm1TQb040 SQ0NUj4rGtGLdnT3kkzpxjbzsUMssJIMdlX8FhbAx4TmT19kzFKX2jxVPeZZn6JJ98AIcqImkv4q l+nNNifW4In1FNPYVXWtJ6xKvcqlHXwZI8q6f/wCLf0iW0/ThFbZnITvaG7tai0mbrO0ZpcYOWs4 Zlvm2aq91Cap7dyalBslKvrxjn0MTrmhs8g4veC7w6nNj/x43jduoJHllm98pxMs8a60wIeqZiwW PJVSTniUF07mM5d5zVR+OCzB7E6gHHzEF4+4wrG8cY4znOISR3ia0ezxkg/85E3/PffyLClW/MoX mL2GbzGHqfLn1bwkN0deaS+pmn+1cIzPpKJqs8ranIdknYz1Jo35nWN/F3moSEe51JGacVo6/Ood BznWs25mrkO86vcjecO9XhWxDxjsIWezyc9u9q5/3O1r1zrZRb5lNxOazngPKKPvvPeP8h2lg4a0 4Ps+eEkXPtCEJzzgH514wyu+zouPNOKnTvmiGr0j7eJ1VT2teaDnpqvXBjY0ObyThDUT2ruZoq5/ HXRc+ysyIg5cst9FKlFfeHDCVsoYM2usfXHM541xF/B135RMbpLbPdy90LLtYZNFkiOrzVdpdary yx99KU6nt773nX1qVkTpTW/3/7/Hye4hd6T7Ad9I+ivPfk+2HeIaf/vX3z9xPcY/7vNP+/29TH+6 j52d/YdxAbh/cid/9Qd3/4d/B7iA9YR2W1d37ReBzmN9EnhbFPgRF1iBtJWB6tcfGviBAOIU6weC JFiCMWNF9DJqJriCKxFGKDhgLJgT3wNctrM7EjiDMZiDvsOBOphyudeD7ceDGoGDQEhpRFiESKg0 DviACdiEBaiADTiAS2iA/ueECPiE4mNxUhh2+jeFUKh2X0iAVziG+TdlYliGczdiAFV+c9OGA+Q3 6caGLFY2cviGdIhAbmiHeJiHcWh+fjiHewiIfyhOfZiHcFiHo1OIgmiIdziIif8YiHroiIcIiYoY iYyIiCOYhJq4gb10OM/HRJrWOI7xbG2FfJhFGspHF6gVJKcYfOImSa9oewsGi0NzfC/obe3VWdRX Obu4fD3Icq3merb3a0NjXkHji9I2jLtHXSyHSkwUaqO3XZ3mad1FjKqYOE4Ea8nIarAWRbU4c6zG HUJDNErUiuBojcK4ieq4juzYju74jvAYj/I4j/RYj/Z4j/iYj/q4j/zYj/74jwAZkAI5kARZkAZ5 kAiZkAq5kAzZkA75kBAZkZZGelIjhO1BkU2DkZ0RexV5PBZ5kaOkgknzkaBBkiD5LRz5NCbJGc2X kc3WKsaTiUYjkz4TZNgTkzj/STw0KZE82ZM++XoVFmAV9nuIZHXEhj6tgWkdJpQfZl9FyYVJeZSb FpXjdRiIYz+zRk9PtJXQwmAaSXxEqUP1RYrcOF+TI2GfVWxMqB6/YZb9ZUNoaWGh+GBG5JYyd0dx 2ZUds5LV5pT/BIa+4mFZaZQYli2T5U5X+UocWT9aeT5MhnxDsphSCYHsFF63d17rRRgRZhd9xGH3 hZYN9pb61SKbmV9aOZb1RXujaYyWmZouV16ciUOfiZq/9JVIMWlzJmO4c4R8wm64yZvAmSe+eSG7 uX24uSe6CWTCOWS/uZwlNZwvZpzSWZzUSZzK2ZzYeZ3aGZ07+ZPe+Z3gGZ4s/+iFYUieWHie9mee ZMiAgJmeW9iFTCFXf7VX8il0f0VY5HJY+NlrgxVYhZVY91mfZkWfAXqf/pmfhqWfB8qfbuVX9vmg qQagEIpXfSWgDApXC4pYDXpYqtafFkqhAAif77mW61mFJWqiaEiF7ZmiW6aeLJqFPKE3cSOj7oaH eCNkNHqj2lc3M4qjPrqjfPOjf8N0NVpOQqqjQ5qjPJqkR0qITRqkb2gUlfiIktiIl1ilkDiJjjil U6qlfIiJYEqJiOilTiqmZrqlY2qlZYqmZ/qlWaqmRtqma+qmWCqJ4nmneGqQw6aWfCpzU/mS2QF9 gCoSMmVsgNQuQ+ltiUk/2v+Ya65ZM3yZRZCFlH3qWWsEWaA4qdBWWe90Wp8VbpI0bKCajhthqLd4 LqT2jbx3jdcIGGYUi6HHqq44jiI5FJE6TIVJqbpqqbQYbVSZlpUkqNmGGMN3qb6qhqHxaseHqtTS ir+iWbhoWU/ZG6Maq5pxq8kKau21raOJesv6XtYYrtoYjNPYqbEZfJoEjrUXjZs2rtCIgZz5fOsq RqwJZkCjavQKRtA4Kurar9vWqsWIrRghsA8BZ8nZINVZg7qzsDZ4nBChsBDLsL3pEQ4bsZ/TOqiD sQpLOxILsbKzObninHk6siRbsiZbXC76ouipsid6hgY3omnosij6siJKovD/1xMfqlcVWqAT2qEb qqAcup8aiqE566ADurM9a7QRurQ+S7RA+7QJGrUSOrVMq7QUOp99laFNq1hBq7VCu7VIC5pcBrMx m7Ize7YCWLNlS7YtyrZWeLMx+qRaiqTjp6RxyqQ9CqREardzu6Z1K7eNSLd+u6SCe7eF27dQireK e7iBS7gkJqd3S6dXOrmLWLmWaLmRO6eam7mcS6WUe7mg67mYS6adC6eke7pcGqZsurqSi7ndebKw G7sgSLAuiW0KhoLJtqi4alu0W3FEtXMv13Pvk4ubGouc+q5O1buHRHWiwnPKymyztorKVq2DGkrK a4a/+67Nq67byL2kGo7K/yiK27ZzqWau1qsqIstUFmudG6uxHbuwTcWbsju/9Fu/9itKZou2Mrui 7Lm/nZq//gvAhFmeblsVPEu1bFW0XrvAXdvAUIvABJq0RTvBBurAUvuzF+y0EnzAVUvBG5y0DPzA GOyhIpzACJYqNkuzKay/AoyYBdyyLfzCLDvDQsG3jWu4jovDOoy4PGzDNjq4O3zDewu4PxzERTzE ebu4QNzDROyHjHvEQsy3SpG6kIu6qtu6pfumWlzFptvFW/y5WVynYEzFYuy6V7y5VszFX2zGalzF 9/vGcCyB1yutlAksp2op4vKCewqjzOER0YesqVq9LjHHbaYTqeitrjdanv9Clp1ya+m6RoQMt0eU P6K1yLLavOIbNT6Xkt+Vu8bbiwjzg7vCyKc3rcOqbbMqvZEsyT+CqKZMlocsOS3ZrOqCeZWqizAY HaL8XKEKdKFWy+WrWf51r+c4fb+8yuYLvrVHbd0qzOOGvOCKrwPLlvCCecXxjAB7zLqEvg67E+v7 zbPjvuAMskXRzaQTsRxrsR8LvxcReDs5zussv/aWvnFcz/Z8z/hcuyuctvscwDLcv/6stioa0AJN wMuLsxxswh+MViGcwVxbwg+90B2c0BEMwVlrwSTs0II1whMt0Qpt0Vi70Rqc0STN0SPd0WKrhQVt 0P0cw2bo0mu70m/bvxn/52ZJ/MROnMNMnNNGzNNIrMQ9zX1Q3MRC7dNRPNQ3vcRHbdRIDdQ7XdRQ LX5HPMVnHMZgnMZjXNVYjcVbHbpknNVtDNasy8ZjbdVkLdZc7cVlHLqnm89u/dbChcxwTRVyzcpz rYS7fNfBU9e1qtdHw9cs5deAI8+CXdiGfdjyIlXrapuInbyTbDgpDZ7QPFylTH2MfVyT7ZAuuKyc /JM2yVvdV4GfvU3YFdo32Niondq/q9rVldesrc/x+dpTA9iALNs0A9hRZ9s9k9tSqttO87q+HdzC 7TMATNAx3dIDaNwDDdMjJ9Mw7NozHYXOTcMsnNzMzdLHjdzT3deG/M80/+3d/Fvd4K3c2D3Q5B3d 4W2r433eK/vd2+3e2h3fMcvez33QPeHOjpffkLffecd4+t3fd4ffkzfgAH54h/Z4efbfjUbgC37g kWfgDR7hf8ffhD3cFn7hShZfOUdZ2ppM0PVpw3yv3Piay/yo1xHZyuxM3vtd84haaAQ5nWYqmNkj qfmqzvtt0drKtbhF9YpYZemzM+7hHWqVQX6Mq7ZrTImNviYq5JpGJG6Cqjyprvzjhip7HnO73ii9 KSir4/sYXxR0mvfjm3qZoleKpMXk4eGpbCR0kJzmSKiUzLyv9idZxuZTOS5r/4rjipqoeb5so9rk /AzZqHfH3bYYxwroyUyXayWIflzT1Ev3Nmw42tp3b1IdTiJIZJVepEPa1Iz+dKc96e0WY5Reb0wt b40e6ZkOfv2W6piO6qBeb8CN4bI+67Re67Z+67heEQEBADs= --=_related 0007B62A48257601_=-- From lmartini@cisco.com Tue Jul 28 02:09:27 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303A93A6DAA for ; Tue, 28 Jul 2009 02:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx76fRwfRLNy for ; Tue, 28 Jul 2009 02:09:26 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 0E1BD3A6E52 for ; Tue, 28 Jul 2009 02:08:53 -0700 (PDT) Received: from rasputin.monoski.com (dhcp-1644.meeting.ietf.org [130.129.22.68]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n6S98hOi003822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:08:46 -0600 (MDT) Message-ID: <4A6EC015.8040600@cisco.com> Date: Tue, 28 Jul 2009 03:08:37 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: dai.xuehui@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 67.41.208.110 Cc: swallow@cisco.com, Matthew.Bocci@alcatel-lucent.com, "pwe3@ietf.org" Subject: Re: [PWE3] one question on X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:09:27 -0000 Dai, I do not understand your question. The formats appear to be the same. The format on the -00 version of the draft was slightly different , but but the -01 version matches the presentation I gave in pwe3. Luca dai.xuehui@zte.com.cn wrote: > hi,martini: > > yestody,I saw your draft(draft-martini-pwe3-static-pw-status-01),and also > your presectation file about this draft on IETF 75.Then,I find a > difference on PW OAM message packet header. > > in draft-martini-pwe3-static-pw-status-01,It id defined as below: > 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 | 0xZZ PW OAM Message | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ACH TLV Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Refresh Timer | TLV Length |A| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ TLVs ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Figure 1: ACH PW OAM Message Packet Header. > > > But, in your presentation file ,it has a diffrent format,that is: > > > Redards, > Dai > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > From tony@jeffree.co.uk Mon Jul 27 12:02:33 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01833A69F4 for ; Mon, 27 Jul 2009 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID7A8i5H3a5G for ; Mon, 27 Jul 2009 12:02:32 -0700 (PDT) Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by core3.amsl.com (Postfix) with ESMTP id 6AAAF3A6988 for ; Mon, 27 Jul 2009 12:02:31 -0700 (PDT) Received: from [92.27.5.90] (port=61199 helo=imdev) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:1025) with esmtpa (authdaemon_login:tony@jeffree.co.uk) id 1MVUqu-0004vt-AZ (Exim 4.69) (return-path ); Mon, 27 Jul 2009 18:23:12 +0000 From: "Tony Jeffree" To: "'Sadler, Jonathan B.'" , References: <5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B5DD5F5EB50@EX-NAP.tellabs-west.tellabsinc.net> Date: Mon, 27 Jul 2009 19:23:11 +0100 Message-ID: <35B687F468904874BB4AF044A70E99B8@imdev> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Thread-Index: AQHKDtuIpltLBHeWQkq69fp1WtMxh5CJsH6w X-Mailman-Approved-At: Thu, 30 Jul 2009 00:12:44 -0700 Cc: pwe3@ietf.org, stbryant@cisco.com Subject: Re: [PWE3] ICCP draft and mLACP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony@jeffree.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:02:33 -0000 Jonathan - It is the policy of the IEEE SA and its working groups not to accept any communication that attempts to place any kind of burden on the recipient(s) with respect to confidentiality or copyright. On a personal level, I do not recognize or accept the burdens that any such disclaimers attempt to place upon me without my prior consent. If you wish to communicate with me via email, you will please do so without appending such disclaimers to your messages. Any further messages that contain such a notice will be ignored. Regards, Tony -----Original Message----- From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: 27 July 2009 17:59 To: lmartini@cisco.com Cc: stbryant@cisco.com; pwe3@ietf.org; Tony Jeffree Subject: ICCP draft and mLACP Hello Luca, At PWE3 today, you asked the question if the technology specific details in the ICCP draft (found at http://tools.ietf.org/html/draft-ietf-pwe3-iccp-00) should be split out from the base document. I indicated my support for a split and wanted to let you know my reasoning. Within the last 2-3 years, IEEE has identified that 802.3ad doesn't have a requirement to be bound to Ethernet, nor does it need to be bound to a single-node to single-node deployment. This has led to the agreement that work on LAG be moved from 802.3 and into 802.1. As a result of the move in responsibility, 802.3 has removed clause 43 from the 802.3 specification, and 802.1 has placed the text into its own document: 802.1AX-2008. Extensions to 802.1AX for Multi-Chassis LAG, etc. are expected to be developed for this document. While the work on Multi-Chassis LAG (i.e. allowing LAG to operate in a multi-homed configuration as shown in the ICCP draft) is still on the "todo" list in 802.1 for 802.1AX, it requires essentially the same sort of information that has been included in section 7.2 of the ICCP draft. Defining the protocol to carry this information (e.g extensions to LDP/development of ICCP) can be stated as something IETF is a master of, but the required data for the application and NE behaviours are probably best co-developed with IEEE. Not only would this get the correct experts involved in the development, it would allow for commonality with a non-MPLS based solution. By placing the technology specific bits into a separate I-D, the base ICCP draft has any encumbrance removed and can progress quickly. If IEEE is not interested in developing multi-chassis then I can understand IETF progressing the mLACP application work independantly. However, it would be bad (in my mind) to have duplicate work done in IETF (developing an MPLS specific solution) and in IEEE (developing an general Ethernet spec). I hope this helps. Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From root@core3.amsl.com Thu Jul 30 02:15:01 2009 Return-Path: X-Original-To: pwe3@ietf.org Delivered-To: pwe3@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D6BF3A7182; Thu, 30 Jul 2009 02:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090730091501.6D6BF3A7182@core3.amsl.com> Date: Thu, 30 Jul 2009 02:15:01 -0700 (PDT) Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-ms-pw-arch-07.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge Author(s) : M. Bocci, S. Bryant Filename : draft-ietf-pwe3-ms-pw-arch-07.txt Pages : 25 Date : 2009-07-30 This document describes an architecture for extending pseudowire emulation across multiple packet switched network segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, and where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-arch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pwe3-ms-pw-arch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-30020030.I-D@ietf.org> --NextPart-- From ostokes@extremenetworks.com Thu Jul 30 02:46:47 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A9728C1BA for ; Thu, 30 Jul 2009 02:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8qtry5Xhijl for ; Thu, 30 Jul 2009 02:46:36 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id 0A54D3A6C31 for ; Thu, 30 Jul 2009 02:46:35 -0700 (PDT) Received: from USEXCHANGE.corp.extremenetworks.com ([10.0.4.74]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Thu, 30 Jul 2009 02:46:37 -0700 From: Olen Stokes To: Luca Martini Date: Thu, 30 Jul 2009 02:50:40 -0700 Thread-Topic: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt Thread-Index: AcoMXltzgmahcGs+TJaVXaQ/rxpMXwEkfdrg Message-ID: <6738A78F51650A4FAEDCF6844B26C214135C68FE78@USEXCHANGE.corp.extremenetworks.com> References: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> <4A69AFBA.2050205@cisco.com> In-Reply-To: <4A69AFBA.2050205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6738A78F51650A4FAEDCF6844B26C214135C68FE78USEXCHANGEcor_" MIME-Version: 1.0 Cc: "pwe3@ietf.org" Subject: Re: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:46:47 -0000 --_000_6738A78F51650A4FAEDCF6844B26C214135C68FE78USEXCHANGEcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please consider the following network based on Figure 1 in the draft: +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | +-----+ | | +-----+ | | PE1 ||<----|---PW---|-->|| PE3 ||<-- PW --= > -|--| | | | | ||<-- PW --= > / | +-----+ | | +-----+ / | || | | ^ / | || ICCP | | | PW +---------+ / | || | | V +----+ | | / | +-----+ | | +-----+ | CE | | Access |/ | | PE2 ||<----|---PW---|-->|| PE4 ||<-- PW --= > | +---+ Network |-------|--| | | | | ||<-- PW --= > +----+ | | | +-----+ | | +-----+ | | | | | +---------+ | Redundancy | | H-VPLS ^ | Group | | Full-Mesh Core | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | Multi-homed Network PE1 and PE2 provide redundant access to an H-VPLS network. They effectivel= y combine to provide the function of a MTU-s as shown in Figure 3 of RFC 47= 62. They attach to different PEs to avoid a single point of failure in the= H-VPLS core. The access network is a generic Ethernet L2 network. A packet destined to = an unknown unicast MAC address sent from the CE will be delivered to both P= E1 and PE2. ICCP is used between PE1 and PE2 to determine the active PW to the H-VPLS c= ore. >From the responses below, the above network configuration seems to be a val= id use of ICCP. While it may be typical that PE1 and PE2 are directly connected and co-loca= ted, this is not always the case. It is definitely possible in some custom= er installations that the links between them may fail without PE1 or PE2 ge= tting a "loss of signal". Given the above type of network, the question becomes what happens when all= of the links between PE1 and PE2 fail? Will PE1 and PE2 both assume that = the other node has failed since the BFD session between them will go down? = If so, is there not a loop when the PWs from PE1 and PE2 are both active a= t the same time? I apologize, but I did not completely understand the statement: "yes. the split brain problem cannot be completely avoided. This is why it= is very important that only if all possible connectivity is lost, the ICCP= /BFD session goes down. If a PE is isolated , no looping is possible, howev= er the service might no longer work." In the above scenario, the two PEs are isolated from each other, but they a= re not isolated from the network. I apologize again, but I do not see how to distinguish with complete certai= nty in all network environments between: 1) The node with the active PW has crashed and therefore the secondary PW = should be activated, and 2) All of the links between the RG nodes have failed and therefore the sec= ondary PW should not be activated My concern is that in order to apply ICCP as it is defined today to generic= Ethernet access in an H-VPLS network, it has to be guaranteed that the ICC= P session cannot go down due to link failure while the RG nodes (MTU-s) sti= ll have connectivity to the H-VPLS core network. I am not sure how to make= that guarantee in the networks in which some customers want to deploy H-VP= LS. I understand that the Ethernet section of the draft has not completed and t= hat more insight into this discussion may appear at that time. Cheers, Olen From: Luca Martini [mailto:lmartini@cisco.com] Sent: Friday, July 24, 2009 8:58 AM To: Olen Stokes Cc: pwe3@ietf.org Subject: Re: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt Olen, Sorry for the delay in response , somehow i missed this e-mail. More below. Olen Stokes wrote: I have the following questions on draft-martini-pwe3-iccp-01.txt: 1) In Section 4.1, it states that "the redundancy mechanism employed t= owards the access node/network can be one of a multitude of technologies". = Are there any restrictions on the access network? In particular, are ther= e any restrictions about a given packet reaching both PE1 and PE2 from the = access network in Figure 1? If not, is it true that a packet received on a= PW at PE1 and sent toward the access network may reach PE2 via the access = network? How the packet is sent to the PE on the AC is not dependent on ICCP. THe pr= otocol used i nthe access network will dictate how we choose the active lin= k, and how we forward the packet. 2) In Section 5.2, it states, "The RG will not become operational unti= l the corresponding RG Connect Message has been received." If a single nod= e comes up and does not receive any ICCP capable announcements, does it bec= ome operational? What if it has been configured that a second node is supp= osed to be present? If so, what happens when a second node later advertise= s that it is ICCP capable? Is the RG operational between the second capabi= lity announcement and the subsequent connect message? ok, It takes at least 2 nodes to have an RG become operational. So if one n= ode comes up and there are no other PEs advertising that particular RG, the= RG never becomes operational. The capability in LDP is only used to for an LSR to be allowed to send an R= G connect message. The RG becomes operational only when both PEs have sent = the RG connect messages. Sec 4.2 in draft-ietf-pwe3-iccp-01.txt is quite cl= ear on the procedures. 3) In Section 6, it states the following: - BFD Run a BFD session [BFD] between the PEs that are members of a given RG, and use that to detect PE node failure. This assumes that resiliency mechanisms are in place to protect connectivity to the remote PE nodes, and hence loss of BFD periodic messages from a given PE node can only mean that the node itself has failed. How is this guaranteed? There can be n-links between two interconnected PE= s in a Redundancy Group. If the BFD session between the two PEs goes down,= all that is really known is that the two PEs cannot communicate over those= n-links. How does this guarantee that the remote PE is not forwarding acc= ess network data to the core network over other links? There are no guarantees against multiple failure events. We are protecting = against a single failure , and all we are saying here is that the PEs MUST = have really good connectivity between each other to almost exclude the poss= ibility to loose communication between the PEs. Take a Redundancy Group as shown in Figure 1 where PE1 and PE2 are H-VPLS M= TU-s switches with connections to the core. Assume that they have dedicate= d interconnection with n-links. If somehow all n-interconnect links fail, = then will not both nodes assume that the remote node has failed? If so, th= en it appears that a loop is very possible. Losing connection to the core = after a large number of failures would seem to be a better alternative than= any risk of a loop. yes. the split brain problem cannot be completely avoided. This is why it = is very important that only if all possible connectivity is lost, the ICCP/= BFD session goes down. If a PE is isolated , no looping is possible, howeve= r the service might no longer work. In a typical application the two PEs are directly connected and co-located. 4) Section 8.1.5 - It states that a PW Id TLV is "used to communicate = the configuration of PWs for VPWS." Is there some reason that this cannot = be used with a (H)VPLS? For example, there could be redundant MTUs that ar= e connecting to a core group of PEs as discussed above. no - this is only terminology. We meant to say "For PW" . Of course H-VPLS = with PW access is a valid application. 5) Section 8.1.5 - There is a Peer ID field included in the TLV. What= is the intent of the Peer ID? this is defined as "Four octet LDP Router ID of the peer at the far end of = the PW" This is necessary to uniquely identify the PW when using FEC 128. 6) Are there any provisions for when an access network might segment w= ith part of the access network still having connectivity to one PE while th= e remainder of the network has connectivity to the other PE? I realize tha= t how this condition is recognized may be out of the scope of this document= , but how the PEs communicate this condition could potentially be included. this would have to be handled by the access network protocol. It is out of = scope of ICCP. Thanks. Luca Thanks for your attention. Cheers, Olen ________________________________ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_6738A78F51650A4FAEDCF6844B26C214135C68FE78USEXCHANGEcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please consider the following network based on Figure 1 in t= he draft:

 

 

           = ;            &n= bsp;    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=         +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

           = ;            &n= bsp;    |       &nbs= p;       |        |    =             &nb= sp;        

           = ;            &n= bsp;    |  +-----+      |      =   |    +-----+

           = ;            &n= bsp;    |  | PE1 ||<----|---PW---|-->|| PE3 ||<-- PW -->=

           = ;            &n= bsp;   -|--|     |      |       = |    |     ||<-- PW -->

           = ;            &n= bsp;  / |  +-----+      |    &nbs= p;   |    +-----+

           = ;            &n= bsp; /  |     ||        |&nb= sp;       |       ^

           = ;            &n= bsp;/   |     || ICCP   |    &nbs= p;   |       | PW

          +----= -----+  /    |     ||        |     = ;   |       V

 +----+   |      &nb= sp;  | /     |  +-----+      |&n= bsp;       |    +-----+ 

 | CE |   | Access  |/    = ;  |  | PE2 ||<----|---PW---|-->|| PE4 ||<-- PW -->=

 |    +---+ Network |-------|--|     |      | = ;       |    |     ||<-- PW -->=

 +----+   |      &nb= sp;  |       |  +-----+      |    &nbs= p;   |    +-----+

          |&nbs= p;        |     = ;  |            &n= bsp;  |        |

          +----= -----+       |   Redundancy  |        = |     H-VPLS

           = ; ^               |   &n= bsp; Group     |        | Full-Mesh Core

           = ; |               +=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+        +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

           = ; |

     Multi-homed Network

 

 

PE1 and PE2 provide redundant access to an H-VPLS network.&n= bsp; They effectively combine to provide the function of a MTU-s as shown in Fig= ure 3 of RFC 4762.  They attach to different PEs to avoid a single point o= f failure in the H-VPLS core.

 

The access network is a generic Ethernet L2 network.  A packet destined to an unknown unicast MAC address sent from the CE will be = delivered to both PE1 and PE2.

 

ICCP is used between PE1 and PE2 to determine the active PW = to the H-VPLS core.

 

From the responses below, the above network configuration se= ems to be a valid use of ICCP. 

 

While it may be typical that PE1 and PE2 are directly connec= ted and co-located, this is not always the case.  It is definitely possibl= e in some customer installations that the links between them may fail without PE= 1 or PE2 getting a “loss of signal”.

 

Given the above type of network, the question becomes what happens when all of the links between PE1 and PE2 fail?  Will PE1 and = PE2 both assume that the other node has failed since the BFD session between th= em will go down?  If so, is there not a loop when the PWs from PE1 and PE2 are both active at the same time?

 

I apologize, but I did not completely understand the stateme= nt:

 

“yes. the split brain problem cannot be complet= ely avoided.  This is why it is very important that only if all possible connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated ,= no looping is possible, however the service might no longer work.”<= o:p>

 

In the above scenario, the two PEs are isolated from each ot= her, but they are not isolated from the network.

 

I apologize again, but I do not see how to distinguish with complete certainty in all network environments between:

 

1)&n= bsp; The node= with the active PW has crashed and therefore the secondary PW should be activate= d, and

2)&n= bsp; All of t= he links between the RG nodes have failed and therefore the secondary PW shoul= d not be activated

 

My concern is that in order to apply ICCP as it is defined t= oday to generic Ethernet access in an H-VPLS network, it has to be guaranteed th= at the ICCP session cannot go down due to link failure while the RG nodes (MTU= -s) still have connectivity to the H-VPLS core network.  I am not sure how to ma= ke that guarantee in the networks in which some customers want to deploy H-VPL= S.

 

I understand that the Ethernet section of the draft has not completed and that more insight into this discussion may appear at that time. 

 

Cheers,

Olen

 

 

 

From: Luca Martini [mailto:lmartini@cisco.com]
Sent: Friday, July 24, 2009 8:58 AM
To: Olen Stokes
Cc: pwe3@ietf.org
Subject: Re: [PWE3] Questions on draft-martini-pwe3-iccp-01.txt=

 

Olen,
Sorry for the delay in response , somehow i missed this e-mail.

More below.

Olen Stokes wrote: 

I have the following questions on draft-martini-pwe3-iccp-01.txt:=

 
1)    &nbs=
p; In Section 4.1, it states that "the redundancy mechanism employed t=
owards the access node/network can be one of a multitude of technologies&qu=
ot;.  Are there any restrictions on the access network?  In parti=
cular, are there any restrictions about a given packet reaching both PE1 an=
d PE2 from the access network in Figure 1?  If not, is it true that a =
packet received on a PW at PE1 and sent toward the access network may reach=
 PE2 via the access network?
 
 

How the packet is sent to the PE on the AC is not depe= ndent on ICCP. THe protocol used i nthe access network will dictate how we choose= the active link, and how we forward the packet.






2)      In Section 5.2, it states, "The =
RG will not become operational until the corresponding RG Connect Message h=
as been received."  If a single node comes up and does not receiv=
e any ICCP capable announcements, does it become operational?  What if=
 it has been configured that a second node is supposed to be present? =
 If so, what happens when a second node later advertises that it is ICCP ca=
pable?  Is the RG operational between the second capability announceme=
nt and the subsequent connect message?
 
 

ok, It takes at least 2 nodes to have an RG become operational. So if one node comes up and there are no other PEs advertising= that particular RG, the RG never becomes operational.
The capability in LDP is only used to for an LSR to be allowed to send an R= G connect message. The RG becomes operational only when both PEs have sent th= e RG connect messages. Sec 4.2 in draft-ietf-pwe3-iccp-01.txt is quite clear on = the procedures.



3)      In Section 6, it states the following=
:
 
- BFD
       Run a BFD session [BFD] between the= PEs that are members of a
    &nb=
sp;  given RG, and use that to detect PE node failure. This assumes
       that resiliency mec=
hanisms are in place to protect connectivity
 &nb=
sp;     to the remote PE nodes, and hence loss of BFD p=
eriodic messages
       =
from a given PE node can only mean that the node itself has
       failed.
 
How is this guaranteed?  There can be n-links=
 between two interconnected PEs in a Redundancy Group.  If the BFD ses=
sion between the two PEs goes down, all that is really known is that the tw=
o PEs cannot communicate over those n-links.  How does this guarantee =
that the remote PE is not forwarding access network data to the core networ=
k over other links?
 
 =
 



There are no guarantees against multiple failure event=
s. We
are protecting against a single failure , and all we are saying here is tha=
t
the PEs MUST have really good connectivity between each other to almost exc=
lude
the possibility to loose communication between the PEs.







Take a Redundancy Group as shown in Figure 1 where PE1 and PE2 are H-V=
PLS MTU-s switches with connections to the core.  Assume that they hav=
e dedicated interconnection with n-links.  If somehow all n-interconne=
ct links fail, then will not both nodes assume that the remote node has fai=
led?  If so, then it appears that a loop is very possible.  Losin=
g connection to the core after a large number of failures would seem to be =
a better alternative than any risk of a loop.
&nb=
sp;
  



yes. the split brain problem cannot be completely
avoided.  This is why it is very important that only if all possible
connectivity is lost, the ICCP/BFD session goes down. If a PE is isolated ,=
 no
looping is possible, however the service might no longer work.

In a typical application the two PEs are directly connected and co-located.=
 







4)      Section 8.1.5 - It states that a PW I=
d TLV is "used to communicate the configuration of PWs for VPWS."=
  Is there some reason that this cannot be used with a (H)VPLS?  =
For example, there could be redundant MTUs that are connecting to a core gr=
oup of PEs as discussed above.
 
=

  



no - this is only terminology. We meant to say "F=
or
PW" . Of course H-VPLS with PW access is a valid application.







5)      Section 8.1.5 - There is a Peer ID fi=
eld included in the TLV.  What is the intent of the Peer ID?
  



this is defined as "Four octet LDP Router ID of t=
he
peer at the far end of the PW" 

This is necessary to uniquely identify the PW when using FEC 128.









 
6)      Are there=
 any provisions for when an access network might segment with part of the a=
ccess network still having connectivity to one PE while the remainder of th=
e network has connectivity to the other PE?  I realize that how this c=
ondition is recognized may be out of the scope of this document, but how th=
e PEs communicate this condition could potentially be included.<=
/pre>
 
  



this would have to be handled by the access network
protocol. It is out of scope of ICCP.



Thanks.

Luca









Thanks for your attention.
 
Cheers,
Olen
 
 
 
=
 
 
 
<=
pre> 
  
 





 
____________________________________=
___________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/pwe3
  



 
--_000_6738A78F51650A4FAEDCF6844B26C214135C68FE78USEXCHANGEcor_-- From yljiang@huawei.com Fri Jul 31 02:15:31 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29993A68B4 for ; Fri, 31 Jul 2009 02:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.547 X-Spam-Level: * X-Spam-Status: No, score=1.547 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dON3OMpSdoR5 for ; Fri, 31 Jul 2009 02:15:25 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 035CE3A6805 for ; Fri, 31 Jul 2009 02:15:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN00B7831FLZ@szxga02-in.huawei.com> for pwe3@ietf.org; Fri, 31 Jul 2009 17:15:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNN009ZB31F7V@szxga02-in.huawei.com> for pwe3@ietf.org; Fri, 31 Jul 2009 17:15:15 +0800 (CST) Received: from j59929 ([10.70.40.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNN00JQJ31F6I@szxml04-in.huawei.com> for pwe3@ietf.org; Fri, 31 Jul 2009 17:15:15 +0800 (CST) Date: Fri, 31 Jul 2009 17:15:15 +0800 From: Jiang Yuan-long To: Luca Martini Message-id: <001b01ca11bf$6a6e7510$3428460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_MMPPLRh23yZFk0OqPLkTeA)" X-Priority: 3 X-MSMail-priority: Normal References: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> <4A69AFBA.2050205@cisco.com> Cc: pwe3@ietf.org Subject: [PWE3] Comments on draft "Segmented Pseudowire" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 09:15:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MMPPLRh23yZFk0OqPLkTeA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Luca, I have some comments on your draft-ietf-pwe3-segmented-pw-12. Technical comments: 1. In Sec 7.4.1, the description of the 5th sub-TLV is not only "The FEC of last PW segment traversed", but also "The Attachment Identifier of the last PW segment traversed" in the same section. IMO, neither is the exact description. As defined in RFC 4447, FEC element 129 consists of , and AI consists of , so the first is closer to the actual format in this ID. But FEC element 129 also includes a sub-TLV header which is removed here, therefore I think a more accurate description is needed. How about "The neat content of the FEC of last PW segment traversed" or something new? BTW, this description should also align with the sub-TLV type 5 in Sec 13.5 (in the next to the last line): " 0x05 variable AI of last PW segment traversed" 2. Also in Sec 7.4.1, the last sub-TLV is very confusing: " - L2 PW address of PW Switching Point (recommended format). This sub-TLV type contains a L2 PW address of PW Switching Point in the format described in [RFC5003]. This includes the AII type field , and length, as well as the L2 PW address." >From the above paragraph, it seems that 'L2 PW address' is defined in RFC 5003, but in fact there is no such a definition. And the actual components of L2 PW address is also misleading. I think a more clear definition is needed, how about the following: " - L2 PW address of PW Switching Point (recommended format). This sub-TLV type contains a L2 PW address of PW Switching Point, which includes a Global ID field and a Prefix field as described in the AII type 2 construct defined in [RFC5003]." 3. In Sec 13.5, in the last line, a sub-TLV type 6 is defined: 0x06 10 L2 PW address of PW Switching Point But the length should be 8 rather than 10, as both Global ID and Prefix are 4 octets fields. This mismatch may root in the original ID of RFC 5003, which defined Global ID as 6 octets in length, but changes it to 4 in the final RFC. BTW, the same problem also exists in draft-ietf-pwe3-dynamic-ms-pw-09. Some editoral comments: In Sec 7.4, s/the the/to the/ In Sec 8.1, in the 4th line, "VC Label" should be replaced with "PW label". In Sec 9.3, in the first sentence, s/interface parameter field/Interface Parameter sub-TLV field/ s/sub-TLV interface parameter/Interface Parameters sub-TLV/ In Sec 9.4.2, in the first line, s/form/from/ More than one occurence of "no packets MUST be sent..." found in this ID, maybe it would be better to say "packets MUST NOT be sent..." In Sec 10.1, s/an an/an/ s/MH-PW/MS-PW/ s/more then/more than/ In Sec 13.1, s/ne/new/ In Sec 13.2, inserts 'uses' behind "This document" In Sec 14 and 15, there are some minor copy & paste errors: - The title of [RFC4447] should be "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", rather than "Transport of Layer 2 Frames Over MPLS". The latter is the title of a historic RFC (RFC 4906). - The title of [RFC3438] should be "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update" - Both [RFC3985] and [RFC4379] appear twice in the list of References. Please delete one copy for each. I find the following nomenclatures are used for the same TLV across this ID: "Switching Point PE TLV,Switching Point TLV,S-PE TLV, PW sw TLV, PW Switching Point TLV, Pseudowire Switching TLV" If we could simplify them to two (one full name and another abbreviation), it would be a little easier for us to read this document ^&^ Best Regards Yuanlong Jiang --Boundary_(ID_MMPPLRh23yZFk0OqPLkTeA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Luca,
 
I have some comments on your draft-ietf-pwe3-segmented-pw-12.
 
Technical comments:
1. In Sec 7.4.1, the description of the 5th sub-TLV is not only "The
FEC of last PW segment traversed", but also "The Attachment
Identifier of the last PW segment traversed" in the same section.
IMO, neither is the exact description.
As defined in RFC 4447, FEC element 129 consists of <AGI,
SAII, TAII>, and AI consists of <AGI, AII>, so the first is closer
to the actual format in this ID. But FEC element 129 also includes
a sub-TLV header which is removed here, therefore I think a more
accurate description is needed. How about "The neat content of the
FEC of last PW segment traversed" or something new?
BTW, this description should also align with the sub-TLV type 5
in Sec 13.5 (in the next to the last line):
"   0x05  variable AI of last PW segment traversed"
 
2. Also in Sec 7.4.1, the last sub-TLV is very confusing:
"    - L2 PW address of PW Switching Point (recommended format).
 
   This sub-TLV type contains a L2 PW address of PW Switching Point in
   the format described in [RFC5003]. This includes the AII type field ,
   and length, as well as the L2 PW address."
From the above paragraph, it seems that 'L2 PW address' is defined in
RFC 5003, but in fact there is no such a definition. And the actual
components of L2 PW address is also misleading.
I think a more clear definition is needed, how about the following:
"    - L2 PW address of PW Switching Point (recommended format).
 
       This sub-TLV type contains a L2 PW address of PW Switching Point,
       which includes a Global ID field and a Prefix field as described
       in the AII type 2 construct defined in [RFC5003]."
 
3. In Sec 13.5, in the last line, a sub-TLV type 6 is defined:
   0x06     10    L2 PW address of PW Switching Point 
But the length should be 8 rather than 10, as both Global ID and Prefix
are 4 octets fields. This mismatch may root in the original ID of RFC 5003,
which defined Global ID as 6 octets in length, but changes it to 4 in the
final RFC.
BTW, the same problem also exists in draft-ietf-pwe3-dynamic-ms-pw-09.
 
Some editoral comments:   
In Sec 7.4,  s/the the/to the/
In Sec 8.1, in the 4th line, "VC Label" should be replaced with "PW label".
 
In Sec 9.3, in the first sentence,
  s/interface parameter field/Interface Parameter sub-TLV field/
  s/sub-TLV interface parameter/Interface Parameters sub-TLV/
 
In Sec 9.4.2, in the first line, s/form/from/
 
More than one occurence of "no packets MUST be sent..." found in this ID,
maybe it would be better to say "packets MUST NOT be sent..."
 
In Sec 10.1,
  s/an an/an/
  s/MH-PW/MS-PW/ 
  s/more then/more than/

In Sec 13.1, s/ne/new/
In Sec 13.2, inserts 'uses' behind "This document"
 
In Sec 14 and 15, there are some minor copy & paste errors:
- The title of [RFC4447] should be "Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP)", rather than "Transport of
Layer 2 Frames Over MPLS". The latter is the title of a historic RFC
(RFC 4906).
 
- The title of [RFC3438] should be "Layer Two Tunneling Protocol (L2TP)
 Internet Assigned Numbers Authority (IANA) Considerations Update"
 
- Both [RFC3985] and [RFC4379] appear twice in the list of References.
Please delete one copy for each.
 
I find the following nomenclatures are used for the same TLV across this ID:
"Switching Point PE TLV，Switching Point TLV，S-PE TLV，
PW sw TLV, PW Switching Point TLV, Pseudowire Switching TLV"
If we could simplify them to two (one full name and another abbreviation),
it would be a little easier for us to read this document ^&^
 

Best Regards
 
Yuanlong Jiang
--Boundary_(ID_MMPPLRh23yZFk0OqPLkTeA)-- From lmartini@cisco.com Fri Jul 31 03:16:28 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C340528C0FF for ; Fri, 31 Jul 2009 03:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv55h0FsfJ8f for ; Fri, 31 Jul 2009 03:16:27 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 7E47A28C1FE for ; Fri, 31 Jul 2009 03:16:27 -0700 (PDT) Received: from rasputin.monoski.com (m4c5336d0.tmodns.net [208.54.83.76]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n6VAG0RF008884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 04:16:03 -0600 (MDT) Message-ID: <4A72C3E6.8090002@cisco.com> Date: Fri, 31 Jul 2009 04:13:58 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: Jiang Yuan-long References: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> <4A69AFBA.2050205@cisco.com> <001b01ca11bf$6a6e7510$3428460a@china.huawei.com> In-Reply-To: <001b01ca11bf$6a6e7510$3428460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 67.41.208.110 Cc: pwe3@ietf.org Subject: Re: [PWE3] Comments on draft "Segmented Pseudowire" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 10:16:28 -0000 Jiang, Unfortunately this document is past WG Last Call, so I cannot edit it now. However Once the IETF LC is issued I will be able to correct the document. I will respond in detail then. Thanks. Luca Jiang Yuan-long wrote: > Hi Luca, > > I have some comments on your draft-ietf-pwe3-segmented-pw-12. > > Technical comments: > 1. In Sec 7.4.1, the description of the 5th sub-TLV is not only "The > FEC of last PW segment traversed", but also "The Attachment > Identifier of the last PW segment traversed" in the same section. > IMO, neither is the exact description. > As defined in RFC 4447, FEC element 129 consists of SAII, TAII>, and AI consists of , so the first is closer > to the actual format in this ID. But FEC element 129 also includes > a sub-TLV header which is removed here, therefore I think a more > accurate description is needed. How about "The neat content of the > FEC of last PW segment traversed" or something new? > BTW, this description should also align with the sub-TLV type 5 > in Sec 13.5 (in the next to the last line): > " 0x05 variable AI of last PW segment traversed" > > 2. Also in Sec 7.4.1, the last sub-TLV is very confusing: > " - L2 PW address of PW Switching Point (recommended format). > > This sub-TLV type contains a L2 PW address of PW Switching Point in > the format described in [RFC5003]. This includes the AII type field , > and length, as well as the L2 PW address." > From the above paragraph, it seems that 'L2 PW address' is defined in > RFC 5003, but in fact there is no such a definition. And the actual > components of L2 PW address is also misleading. > I think a more clear definition is needed, how about the following: > " - L2 PW address of PW Switching Point (recommended format). > > This sub-TLV type contains a L2 PW address of PW Switching Point, > which includes a Global ID field and a Prefix field as described > in the AII type 2 construct defined in [RFC5003]." > > 3. In Sec 13.5, in the last line, a sub-TLV type 6 is defined: > 0x06 10 L2 PW address of PW Switching Point > But the length should be 8 rather than 10, as both Global ID and Prefix > are 4 octets fields. This mismatch may root in the original ID of RFC 5003, > which defined Global ID as 6 octets in length, but changes it to 4 in the > final RFC. > BTW, the same problem also exists in draft-ietf-pwe3-dynamic-ms-pw-09. > > Some editoral comments: > In Sec 7.4, s/the the/to the/ > In Sec 8.1, in the 4th line, "VC Label" should be replaced with "PW label". > > In Sec 9.3, in the first sentence, > s/interface parameter field/Interface Parameter sub-TLV field/ > s/sub-TLV interface parameter/Interface Parameters sub-TLV/ > > In Sec 9.4.2, in the first line, s/form/from/ > > More than one occurence of "no packets MUST be sent..." found in this ID, > maybe it would be better to say "packets MUST NOT be sent..." > > In Sec 10.1, > s/an an/an/ > s/MH-PW/MS-PW/ > s/more then/more than/ > > In Sec 13.1, s/ne/new/ > In Sec 13.2, inserts 'uses' behind "This document" > > In Sec 14 and 15, there are some minor copy & paste errors: > - The title of [RFC4447] should be "Pseudowire Setup and Maintenance > Using the Label Distribution Protocol (LDP)", rather than "Transport of > Layer 2 Frames Over MPLS". The latter is the title of a historic RFC > (RFC 4906). > > - The title of [RFC3438] should be "Layer Two Tunneling Protocol (L2TP) > Internet Assigned Numbers Authority (IANA) Considerations Update" > > - Both [RFC3985] and [RFC4379] appear twice in the list of References. > Please delete one copy for each. > > I find the following nomenclatures are used for the same TLV across this ID: > "Switching Point PE TLV,Switching Point TLV,S-PE TLV, > PW sw TLV, PW Switching Point TLV, Pseudowire Switching TLV" > If we could simplify them to two (one full name and another abbreviation), > it would be a little easier for us to read this document ^&^ > > > Best Regards > > Yuanlong Jiang > > From yljiang@huawei.com Fri Jul 31 19:03:09 2009 Return-Path: X-Original-To: pwe3@core3.amsl.com Delivered-To: pwe3@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542C73A6872 for ; Fri, 31 Jul 2009 19:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[AWL=1.773, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq0lWaHMklgd for ; Fri, 31 Jul 2009 19:03:08 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2EFDF3A67B7 for ; Fri, 31 Jul 2009 19:03:08 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNO00K6GDP8LK@szxga03-in.huawei.com> for pwe3@ietf.org; Sat, 01 Aug 2009 10:03:09 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNO005IDDP809@szxga03-in.huawei.com> for pwe3@ietf.org; Sat, 01 Aug 2009 10:03:08 +0800 (CST) Received: from j59929 ([10.70.40.52]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNO002KXDP85C@szxml06-in.huawei.com> for pwe3@ietf.org; Sat, 01 Aug 2009 10:03:08 +0800 (CST) Date: Sat, 01 Aug 2009 10:03:08 +0800 From: Jiang Yuan-long To: Luca Martini Message-id: <001501ca124c$37349d90$3428460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <6738A78F51650A4FAEDCF6844B26C21413554176FF@USEXCHANGE.corp.extremenetworks.com> <4A69AFBA.2050205@cisco.com> <001b01ca11bf$6a6e7510$3428460a@china.huawei.com> <4A72C3E6.8090002@cisco.com> Cc: pwe3@ietf.org Subject: Re: [PWE3] Comments on draft "Segmented Pseudowire" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 02:03:09 -0000 Luca, Sorry that I was not aware that this draft had past WG Last Call. But I do appriciate if you can consider these comments in the next revision. Best Regards Yuanlong Jiang ----- Original Message ----- From: "Luca Martini" To: "Jiang Yuan-long" Cc: Sent: Friday, July 31, 2009 6:13 PM Subject: Re: Comments on draft "Segmented Pseudowire" > Jiang, > > Unfortunately this document is past WG Last Call, so I cannot edit it now. > However Once the IETF LC is issued I will be able to correct the document. > I will respond in detail then. > > Thanks. > Luca > > > > Jiang Yuan-long wrote: >> Hi Luca, >> >> I have some comments on your draft-ietf-pwe3-segmented-pw-12. >> >> Technical comments: >> 1. In Sec 7.4.1, the description of the 5th sub-TLV is not only "The >> FEC of last PW segment traversed", but also "The Attachment >> Identifier of the last PW segment traversed" in the same section. >> IMO, neither is the exact description. >> As defined in RFC 4447, FEC element 129 consists of > SAII, TAII>, and AI consists of , so the first is closer >> to the actual format in this ID. But FEC element 129 also includes >> a sub-TLV header which is removed here, therefore I think a more >> accurate description is needed. How about "The neat content of the >> FEC of last PW segment traversed" or something new? >> BTW, this description should also align with the sub-TLV type 5 >> in Sec 13.5 (in the next to the last line): >> " 0x05 variable AI of last PW segment traversed" >> >> 2. Also in Sec 7.4.1, the last sub-TLV is very confusing: >> " - L2 PW address of PW Switching Point (recommended format). >> >> This sub-TLV type contains a L2 PW address of PW Switching Point in >> the format described in [RFC5003]. This includes the AII type field , >> and length, as well as the L2 PW address." >> From the above paragraph, it seems that 'L2 PW address' is defined in >> RFC 5003, but in fact there is no such a definition. And the actual >> components of L2 PW address is also misleading. >> I think a more clear definition is needed, how about the following: >> " - L2 PW address of PW Switching Point (recommended format). >> >> This sub-TLV type contains a L2 PW address of PW Switching Point, >> which includes a Global ID field and a Prefix field as described >> in the AII type 2 construct defined in [RFC5003]." >> >> 3. In Sec 13.5, in the last line, a sub-TLV type 6 is defined: >> 0x06 10 L2 PW address of PW Switching Point >> But the length should be 8 rather than 10, as both Global ID and Prefix >> are 4 octets fields. This mismatch may root in the original ID of RFC >> 5003, >> which defined Global ID as 6 octets in length, but changes it to 4 in the >> final RFC. >> BTW, the same problem also exists in draft-ietf-pwe3-dynamic-ms-pw-09. >> >> Some editoral comments: >> In Sec 7.4, s/the the/to the/ >> In Sec 8.1, in the 4th line, "VC Label" should be replaced with "PW >> label". >> >> In Sec 9.3, in the first sentence, >> s/interface parameter field/Interface Parameter sub-TLV field/ >> s/sub-TLV interface parameter/Interface Parameters sub-TLV/ >> >> In Sec 9.4.2, in the first line, s/form/from/ >> >> More than one occurence of "no packets MUST be sent..." found in this ID, >> maybe it would be better to say "packets MUST NOT be sent..." >> >> In Sec 10.1, >> s/an an/an/ >> s/MH-PW/MS-PW/ >> s/more then/more than/ >> >> In Sec 13.1, s/ne/new/ >> In Sec 13.2, inserts 'uses' behind "This document" >> >> In Sec 14 and 15, there are some minor copy & paste errors: >> - The title of [RFC4447] should be "Pseudowire Setup and Maintenance >> Using the Label Distribution Protocol (LDP)", rather than "Transport of >> Layer 2 Frames Over MPLS". The latter is the title of a historic RFC >> (RFC 4906). >> >> - The title of [RFC3438] should be "Layer Two Tunneling Protocol (L2TP) >> Internet Assigned Numbers Authority (IANA) Considerations Update" >> >> - Both [RFC3985] and [RFC4379] appear twice in the list of References. >> Please delete one copy for each. >> >> I find the following nomenclatures are used for the same TLV across this >> ID: >> "Switching Point PE TLV,Switching Point TLV,S-PE TLV, >> PW sw TLV, PW Switching Point TLV, Pseudowire Switching TLV" >> If we could simplify them to two (one full name and another >> abbreviation), >> it would be a little easier for us to read this document ^&^ >> >> >> Best Regards >> >> Yuanlong Jiang >> >> >