From yaakov_s@rad.com Thu Sep 1 07:36:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C157E21F9B51; Thu, 1 Sep 2011 07:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebZLF2osrkPr; Thu, 1 Sep 2011 07:36:56 -0700 (PDT) Received: from antivir1.rad.co.il (mx1-q.rad.co.il [80.74.100.136]) by ietfa.amsl.com (Postfix) with ESMTP id 9374821F9B50; Thu, 1 Sep 2011 07:36:52 -0700 (PDT) Received: from exrad5.ad.rad.co.il ([192.114.24.28]) by antivir1.rad.co.il with ESMTP; 01 Sep 2011 17:37:55 +0300 Received: from EXUS4-DRP.ad.rad.co.il (192.114.24.119) by EXRAD5.ad.rad.co.il (192.114.24.28) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Sep 2011 17:37:55 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by exus4-drp.ad.rad.co.il ([fe80::5d6f:c2cb:2468:ee2%14]) with mapi id 14.01.0323.003; Thu, 1 Sep 2011 17:37:54 +0300 From: Yaakov Stein To: "stbryant@cisco.com" , Luca Martini , IETF Discussion Thread-Topic: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AQHMZw5mavvEVGB+20OZmzYhp4SdFJU4malQ Date: Thu, 1 Sep 2011 14:37:54 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.ad.rad.co.il> References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com> In-Reply-To: <4E5CD1DF.90702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC903FABF6AEXRAD5adradcoil_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , pwe3 , "iesg@ietf.org" , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 14:36:57 -0000 --_000_07F7D7DED63154409F13298786A2ADC903FABF6AEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart Was this email meant to address my email to the IETF discussion list (from = Tues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not be= ing at BoS; but it does not rule out that possibility either. However, you did not address my other final comment that a PW that starts i= n an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? (My email also identified a wording issue and what I consider to be a compl= etely inaccurate explanation of what the draft is trying to accomplish.) Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Ste= wart Bryant Sent: Tuesday, August 30, 2011 15:05 To: Luca Martini; IETF Discussion Cc: ietf@ietf.org; Vladimir Kleiner; mpls@ietf.org; Idan Kaspit; Mishael We= xler; pwe3; iesg@ietf.org; Oren Gal; John Shirron; pwe3-chairs@tools.ietf.o= rg; Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 =3D=3D=3D=3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. =3D=3D=3D=3D=3D should be replaced by =3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. =3D=3D=3D=3D=3D=3D - Stewart --_000_07F7D7DED63154409F13298786A2ADC903FABF6AEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart

 

Was this email meant to address my email to the IETF discuss= ion list (from Tues 16 Aug)

or just the discussion on MPLS and PWE lists ?

 

It does to SOME extent, as it leaves open the possibility of= the GAL not being at BoS;

but it does not rule out that possibility either.=

 

However, you did not address my other final comment that a P= W that starts in an MPLS-TP domain,

can easily leak into a non-TP domain.

What does one do then ?

 

(My email also identified a wording issue and what I conside= r to be a completely inaccurate

explanation of what the draft is trying to accomplish.)=

 

Y(J)S

 

 

 

From: pwe3-bounces@i= etf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, August 30, 2011 15:05
To: Luca Martini; IETF Discussion
Cc: ietf@ietf.org; Vladimir Kleiner; mpls@ietf.org; Idan Kaspit; Mis= hael Wexler; pwe3; iesg@ietf.org; Oren Gal; John Shirron; pwe3-chairs@tools= .ietf.org; Rotem Cohen
Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3= -gal-in-pw

 


Reviewing this discussion there are three components.

1) The update of RFC5586 to allow PW to use the GAL.
2) The PW OAM application that is to use the GAL.
3) The label stack structure when  teh GAL is used with a PW

This draft is only concerned with point 1 above. Points
2 and 3 need to be resolved in any PWE3 draft that describes
the use of the GAL.

To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01

=3D=3D=3D=3D=3D=3D=3D=3D
 -  Section 4.2. (GAL Applicability and Usa=
ge) in [RFC5586], the
      original text:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatena=
ted Segments of LSPs, and with Sections, and
          MUST NOT be use=
d with PWs. It MUST always be at the bottom of
          the label stack=
 (i.e., S bit set to 1). However, in other MPLS
          environments, t=
his document places no restrictions on where
          the GAL may app=
ear within the label stack or its use with PWs.
 
      is replaced by:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatena=
ted Segments of LSPs, and with Sections, and
          MAY be used wit=
h PWs. It MUST always be at the bottom of the
          label stack (i.=
e., S bit set to 1). However, in other MPLS
          environments, t=
his document places no restrictions on where
          the GAL may app=
ear within the label stack.

=3D=3D=3D=3D=3D

should be replaced by

=3D=3D=3D=3D=3D

 -  Section 4.2. (GAL Applicability and Usa=
ge) in [RFC5586], the
      original text:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatena=
ted Segments of LSPs, and with Sections, and
          MUST NOT be use=
d with PWs. It MUST always be at the bottom of
          the label stack=
 (i.e., S bit set to 1). However, in other MPLS
          environments, t=
his document places no restrictions on where
          the GAL may app=
ear within the label stack or its use with PWs.
 
      is replaced by:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatena=
ted Segments of LSPs, and with Sections, and
          MAY be used wit=
h PWs. The presence of a GAL indicates that
          an ACH immediat=
ely follows the MPLS label stack. 

=3D=3D=3D=3D=3D=3D

- Stewart

--_000_07F7D7DED63154409F13298786A2ADC903FABF6AEXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Thu Sep 1 09:06:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71FE21F992A for ; Thu, 1 Sep 2011 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ka8yCiPmow5 for ; Thu, 1 Sep 2011 09:06:09 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 9080B21F9934 for ; Thu, 1 Sep 2011 09:06:08 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1314893259!16694533!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 17938 invoked from network); 1 Sep 2011 16:07:40 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-10.tower-182.messagelabs.com with SMTP; 1 Sep 2011 16:07:40 -0000 X-AuditID: 93eaf2e7-b7b3dae00000209e-25-4e5fadc1afa1 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 07.82.08350.1CDAF5E4; Thu, 1 Sep 2011 19:07:29 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 1 Sep 2011 19:07:38 +0300 From: Alexander Vainshtein To: Yaakov Stein Date: Thu, 1 Sep 2011 19:07:39 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AQHMZw5mavvEVGB+20OZmzYhp4SdFJU4malQgAAXtkM= Message-ID: References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com>, <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.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_A3C5DF08D38B6049839A6F553B331C760111EF7BD46CILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTb2wMaRj3zszuTldHplvVV9PEGOUDtrrcuXG6jQ8VK3LVlkYioqa7b3eH 3dnJzGisP7mVCNEISpvrNSin1T9a1UbEB4laLhzheviwqmii9G7b0DhCVVszHaqJmE+/9/n9 eZ538rwkbqu3pJCCqCJZ5P2s2Uocjb1+Y7/aXJiTcePtYq7yYxnOvWitJrjermEL11nbYOL2 Nd8huIOvLxDc3efHADdQ+t60jHSVD7WaXDU1g5jrSHOx6839/825xPowyORFMajyKmI8SHE7 2VxZKOHdIZYRPE7WwTKSn3ejABJVJ8tLEhI9bJaV+ebL1GSCyCDRHfQIotfJrlyz2s5xPy6x O9isObMci5Za1/oEhUH2AC/4mQBSFN6LGK2y6QLuu9lxHpMG94Bt/bdrQRg8kkpBHAnpH+Dw w3LCwNNgx5MWcymwkjb6CoDP3p/FjEMFgOHeOouuMtNO2Hb2sVnHU+lZsH//iEkX4XQpBns7 DuE6QdBp8F77P5iOE+lcGHvyijAMeTA6NPjZ/DO8MXBqrE5p9cjwn4TRrYOAL5seAZ2Io1fB Iw8ujmGgzffuVtNYKE4nw86easyYm4Y1l//GDZwE/3umT6Trk2DXvhZg6IPwQFsLZjRLgH/9 3vP5ztPh1foocRhMq5oQWzXBUjXBYtTTYbSi3GzgefDMqT7cwHZYORIhJtZPAksjSBL8kloU 8GY40pFbUJEfpbuDgTZgrFnvJfChOi0CaBKw8VR0w8Ycm4kvUUKBCJhOYmwSVdZQmGObUhT0 hHy84iuUt/qREgGQxNmp1PxKjaM8fGg7koNfqOXa7y/DUya7g9pCi2rhooyM7x/YZOq5u/8X G+3VtnMLQhKSv+SkkiQLqa4mrUWCjLxoW7HgV7/SGBmnjxGvjdGpayhF4gOK4DX4W2BmSjLV rxO0Tvi2iuNe/YH9Ojo6GgPJ2qUTDXu89vzG3TEtGNOCR+aNBWsvZ5xKCYPUxh7//oWZlyxx 5NMXQ909R88Rw3xMTqt/u7P4p7rj2Wvy5pzJkU+71PTIpJI9+bsWZA4y2bNp687u1RdnPLwS rri+bvfJzS8vz1yemnhPrglZ/hiIFu0omLKXzk7beOLfLJ95WcFxQEg3896t8Dy29Dna+7j2 lvyG7muB32ox31qWUHy8Yy4uK/wn4NsutjsEAAA= Cc: "mpls@ietf.org" , IETF Discussion , "pwe3-chairs@tools.ietf.org" , pwe3 , "iesg@ietf.org" , "stbryant@cisco.com" Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 16:06:10 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46CILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draf= t (for MS-PW) - please see my email (to several lists) that explains that in= some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.= html. Regards, Sasha ________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Yaakov Stei= n [yaakov_s@rad.com] Sent: Thursday, September 01, 2011 5:37 PM To: stbryant@cisco.com; Luca Martini; IETF Discussion Cc: mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Stewart Was this email meant to address my email to the IETF discussion list (from T= ues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not bei= ng at BoS; but it does not rule out that possibility either. However, you did not address my other final comment that a PW that starts in= an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? (My email also identified a wording issue and what I consider to be a comple= tely inaccurate explanation of what the draft is trying to accomplish.) Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stew= art Bryant Sent: Tuesday, August 30, 2011 15:05 To: Luca Martini; IETF Discussion Cc: ietf@ietf.org; Vladimir Kleiner; mpls@ietf.org; Idan Kaspit; Mishael Wex= ler; pwe3; iesg@ietf.org; Oren Gal; John Shirron; pwe3-chairs@tools.ietf.org= ; Rotem Cohen Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 =3D=3D=3D=3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. =3D=3D=3D=3D=3D should be replaced by =3D=3D=3D=3D=3D - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. =3D=3D=3D=3D=3D=3D - Stewart This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46CILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point th= at I've raised in my IETF LC comment on the draft (for MS-PW) - please see m= y email (to several lists) that explains that in some detail, at = http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.<= /div>
 
Regards,
     Sas= ha
 
 
 
From: mpls-bounces= @ietf.org [mpls-bounces@ietf.org] On Behalf Of Yaakov Stein [yaakov_s@rad.co= m]
Sent: Thursday, September 01, 2011 5:37 PM
To: stbryant@cisco.com; Luca Martini; IETF Discussion
Cc: mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf.org Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-= gal-in-pw

Stewart

 

Was this email meant to address my email to= the IETF discussion list (from Tues 16 Aug)

or just the discussion on MPLS and PWE lists= ?

 

It does to SOME extent, as it leaves open th= e possibility of the GAL not being at BoS;

but it does not rule out that possibility ei= ther.

 

However, you did not address my other final= comment that a PW that starts in an MPLS-TP domain,

can easily leak into a non-TP domain.=

What does one do then ?

 

(My email also identified a wording issue an= d what I consider to be a completely inaccurate

explanation of what the draft is trying to a= ccomplish.)

 

Y(J)S

 

 

 

From: pwe3-bounce= s@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Tuesday, August 30, 2011 15:05
To: Luca Martini; IETF Discussion
Cc: ietf@ietf.org; Vladimir Kleiner; mpls@ietf.org; Idan Kaspit; Mish= ael Wexler; pwe3; iesg@ietf.org; Oren Gal; John Shirron; pwe3-chairs@tools.i= etf.org; Rotem Cohen
Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-= gal-in-pw

 


Reviewing this discussion there are three components.

1) The update of RFC5586 to allow PW to use the GAL.
2) The PW OAM application that is to use the GAL.
3) The label stack structure when  teh GAL is used with a PW

This draft is only concerned with point 1 above. Points
2 and 3 need to be resolved in any PWE3 draft that describes
the use of the GAL.

To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01

=3D=3D=3D=3D=3D=3D=3D=3D
 -  Section 4.2. (GAL Appli=
cability and Usage) in [RFC5586], the
      original text:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenat=
ed Segments of LSPs, and with Sections, and
          MUST NOT be used=
 with PWs. It MUST always be at the bottom of
          the label stack=
 (i.e., S bit set to 1). However, in other MPLS
          environments, th=
is document places no restrictions on where
          the GAL may appe=
ar within the label stack or its use with PWs.
 
      is replaced by:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenat=
ed Segments of LSPs, and with Sections, and
          MAY be used with=
 PWs. It MUST always be at the bottom of the
          label stack (i.e=
., S bit set to 1). However, in other MPLS
          environments, th=
is document places no restrictions on where
          the GAL may appe=
ar within the label stack.

=3D=3D=3D=3D=3D

should be replaced by

=3D=3D=3D=3D=3D

 -  Section 4.2. (GAL Appli=
cability and Usage) in [RFC5586], the
      original text:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenat=
ed Segments of LSPs, and with Sections, and
          MUST NOT be used=
 with PWs. It MUST always be at the bottom of
          the label stack=
 (i.e., S bit set to 1). However, in other MPLS
          environments, th=
is document places no restrictions on where
          the GAL may appe=
ar within the label stack or its use with PWs.
 
      is replaced by:
 
          In MPLS-TP, the=
 GAL MUST be used with packets on a G-ACh on
          LSPs, Concatenat=
ed Segments of LSPs, and with Sections, and
          MAY be used with=
 PWs. The presence of a GAL indicates that
          an ACH immediate=
ly follows the MPLS label stack. 

=3D=3D=3D=3D=3D=3D

- Stewart

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46CILPTMAIL02e_-- From gregimirsky@gmail.com Thu Sep 1 09:30:21 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F305C21F9822; Thu, 1 Sep 2011 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWbIIaXdAysh; Thu, 1 Sep 2011 09:30:20 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94FDA21F985E; Thu, 1 Sep 2011 09:30:19 -0700 (PDT) Received: by vws12 with SMTP id 12so1935637vws.31 for ; Thu, 01 Sep 2011 09:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KVbb3Lki+LOE+FKTglHPWOg8maMju090AWA/19t+IZU=; b=etI6UFdyrLFWVrsyG0lOPgBZFa+lCuk14g6dUg6C6nAhVmnGokx7kHLIAR8C2m2JQZ HtL8KZ72U/XVRADQjjjYK46n+cHewLaL8Qfb8Nht8w+3uiqrezo10rhmuo3JmX9TaJN3 UHajvxALWl1N0VW58Ow0oW7Ic0wv+G431/KCI= MIME-Version: 1.0 Received: by 10.52.93.48 with SMTP id cr16mr28429vdb.312.1314894712606; Thu, 01 Sep 2011 09:31:52 -0700 (PDT) Received: by 10.52.163.133 with HTTP; Thu, 1 Sep 2011 09:31:52 -0700 (PDT) In-Reply-To: References: <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com> <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.ad.rad.co.il> Date: Thu, 1 Sep 2011 09:31:52 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , IETF Discussion , pwe3 , "iesg@ietf.org" , "stbryant@cisco.com" , "pwe3-chairs@tools.ietf.org" Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 16:30:21 -0000 Dear Yaakov and Sasha, I share your concern in regard to MPLS-TP-ness of MS-PW construct. It was in my background thinking when I was querying Sasha and I think that the "chimera" is quite proper characterization for MS-PW in MPLS-TP. Regards, Greg On Thu, Sep 1, 2011 at 9:07 AM, Alexander Vainshtein wrote: > Yaakov, > You've written > > PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain > > This is exactly the point that I've raised in my IETF LC comment on the > draft (for MS-PW) - please see my email (to several lists) that explains > that in some detail, at > http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. > > Regards, > =A0=A0=A0=A0 Sasha > > > > ________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Yaakov > Stein [yaakov_s@rad.com] > Sent: Thursday, September 01, 2011 5:37 PM > To: stbryant@cisco.com; Luca Martini; IETF Discussion > Cc: mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf.org > Subject: Re: [mpls] [PWE3] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > > Stewart > > > > Was this email meant to address my email to the IETF discussion list (fro= m > Tues 16 Aug) > > or just the discussion on MPLS and PWE lists ? > > > > It does to SOME extent, as it leaves open the possibility of the GAL not > being at BoS; > > but it does not rule out that possibility either. > > > > However, you did not address my other final comment that a PW that starts= in > an MPLS-TP domain, > > can easily leak into a non-TP domain. > > What does one do then ? > > > > (My email also identified a wording issue and what I consider to be a > completely inaccurate > > explanation of what the draft is trying to accomplish.) > > > > Y(J)S > > > > > > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Tuesday, August 30, 2011 15:05 > To: Luca Martini; IETF Discussion > Cc: ietf@ietf.org; Vladimir Kleiner; mpls@ietf.org; Idan Kaspit; Mishael > Wexler; pwe3; iesg@ietf.org; Oren Gal; John Shirron; > pwe3-chairs@tools.ietf.org; Rotem Cohen > Subject: Re: [PWE3] [mpls] IETF Last Call comment on > draft-ietf-pwe3-gal-in-pw > > > > Reviewing this discussion there are three components. > > 1) The update of RFC5586 to allow PW to use the GAL. > 2) The PW OAM application that is to use the GAL. > 3) The label stack structure when=A0 teh GAL is used with a PW > > This draft is only concerned with point 1 above. Points > 2 and 3 need to be resolved in any PWE3 draft that describes > the use of the GAL. > > To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 > > =3D=3D=3D=3D=3D=3D=3D=3D > > =A0-=A0 Section 4.2. (GAL Applicability and Usage) in [RFC5586], the > > =A0=A0=A0=A0=A0 original text: > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT be used with PWs. It MUST always be = at the bottom of > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the label stack (i.e., S bit set to 1). Howev= er, in other MPLS > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 environments, this document places no restric= tions on where > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the GAL may appear within the label stack or = its use with PWs. > > > > =A0=A0=A0=A0=A0 is replaced by: > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on > > =A0=A0=A0=A0=A0=A0=A0 =A0=A0LSPs, Concatenated Segments of LSPs, and with= Sections, and > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 MAY be used with PWs. It MUST always be at th= e bottom of the > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 label stack (i.e., S bit set to 1). However, = in other MPLS > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 environments, this document places no restric= tions on where > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the GAL may appear within the label stack. > > =3D=3D=3D=3D=3D > > should be replaced by > > =3D=3D=3D=3D=3D > > =A0-=A0 Section 4.2. (GAL Applicability and Usage) in [RFC5586], the > > =A0=A0=A0=A0=A0 original text: > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 MUST NOT be used with PWs. It MUST always be = at the bottom of > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the label stack (i.e., S bit set to 1). Howev= er, in other MPLS > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 environments, this document places no restric= tions on where > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the GAL may appear within the label stack or = its use with PWs. > > > > =A0=A0=A0=A0=A0 is replaced by: > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 In MPLS-TP, the GAL MUST be used with packets= on a G-ACh on > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 LSPs, Concatenated Segments of LSPs, and with= Sections, and > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0MAY be used with PWs. The presence of a GAL i= ndicates that > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 an ACH immediately follows the MPLS label sta= ck. > > =3D=3D=3D=3D=3D=3D > > - Stewart > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From stbryant@cisco.com Thu Sep 1 10:31:52 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0521F9629; Thu, 1 Sep 2011 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw2xuc4XYRq6; Thu, 1 Sep 2011 10:31:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5F72521F9618; Thu, 1 Sep 2011 10:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4860; q=dns/txt; s=iport; t=1314898405; x=1316108005; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=GQDOkY4pw1+DL63sj5an9xsMn0ZRukZyf2cQSx4DcQk=; b=fTYsU8TZxAyXXvxVl7vcig/3ysIETQ3jIDdJVQMGTM5Ha+mDI34QogQ1 aAWj0EsymJKYBB2qAkaVVPHDxbBFjogcRSg/YGON2rN60eSyCFmQB39zG MhfI3Ri8hb7sS6Dkllqsnl122SRSskEA82lE4cMkSmvpnqcG4U8JnkdHR s=; X-IronPort-AV: E=Sophos;i="4.68,314,1312156800"; d="scan'208,217";a="52879768" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 Sep 2011 17:33:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p81HXO3x001592; Thu, 1 Sep 2011 17:33:24 GMT Received: from dhcp-gpk02-vlan300-64-103-65-27.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p81HXKMR006522; Thu, 1 Sep 2011 18:33:23 +0100 (BST) Message-ID: <4E5FC1E0.4050802@cisco.com> Date: Thu, 01 Sep 2011 18:33:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Alexander Vainshtein References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com>, <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.ad.rad.co.il> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030300060505050902040707" Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 , "iesg@ietf.org" , IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 17:31:53 -0000 This is a multi-part message in MIME format. --------------030300060505050902040707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/09/2011 17:07, Alexander Vainshtein wrote: > Yaakov, > You've written > > PW that starts in an MPLS-TP domain, can easily leak into a non-TP > domain > > This is exactly the point that I've raised in my IETF LC comment on > the draft (for MS-PW) - please see my email (to several lists) that > explains that in some detail, at > http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. > Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertionand discard of "flow labels" at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart --------------030300060505050902040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 01/09/2011 17:07, Alexander Vainshtein wrote:
Sasha

The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs.

Stewart


--------------030300060505050902040707-- From Alexander.Vainshtein@ecitele.com Thu Sep 1 22:04:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FFC21F94A4 for ; Thu, 1 Sep 2011 22:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KhrLpZfDvm3 for ; Thu, 1 Sep 2011 22:04:16 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 15D9C21F9422 for ; Thu, 1 Sep 2011 22:04:14 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-174.messagelabs.com!1314939937!29964760!4 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 1856 invoked from network); 2 Sep 2011 05:05:48 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-174.messagelabs.com with SMTP; 2 Sep 2011 05:05:48 -0000 X-AuditID: 93eaf2e7-b7c4dae0000018d7-34-4e60642187d2 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 2F.82.06359.124606E4; Fri, 2 Sep 2011 08:05:38 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 2 Sep 2011 08:05:47 +0300 From: Alexander Vainshtein To: "stbryant@cisco.com" Date: Fri, 2 Sep 2011 08:05:47 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxozUQ02r1up0JKR8GfF1MoWEKo7gAXg5t5 Message-ID: References: , , <4E4C0F3F.8010700@cisco.com> <5E893DB832F57341992548CDBB333163A0ACD4831F@EMBX01-HQ.jnpr.net> <4E4EC4D2.3070603@cisco.com> <4E5CD1DF.90702@cisco.com>, <07F7D7DED63154409F13298786A2ADC903FABF6A@EXRAD5.ad.rad.co.il> , <4E5FC1E0.4050802@cisco.com> In-Reply-To: <4E5FC1E0.4050802@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_A3C5DF08D38B6049839A6F553B331C760111EF7BD46DILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLsWRmVeSWpSXmKPExsUy+dWnL7pKKQl+Bp+nc1jM+DOR2eLZxvks Fs/v/GW3uLV0JatF+9qzLBZ9n7awWJx7OofR4kPXD1YHDo8pvzeyeixZ8pPJY9LaNI8vlz+z BbBENTDaJObl5ZcklqQqpKQWJ9sqBRRlliUmVyopZKbYKhkqKRTkJCan5qbmldgqJRYUpOal KNlxKWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlOzVlQ2NrrpCMzGKFVN3cxMwchdzU 4uLE9FQFoEjCFuaMaa0vmAr+eFR8XNXM1sB4366LkZNDQsBEYuKeWywQtpjEhXvr2UBsIYG9 jBIzF+t3MXIB2ZMZJfZ2nWIGSbAJ2EpsWn0XrEhEQFdi9oYbjCBFzAINTBLfb3aydzFycLAI qEic+poDUiMsECBxYP0yFoj6QIn1d3+wQthGEhumgpRzcvACxR9f3MgKsXgrq8Tem2C7OAU0 JX4c6WUCsRmBjvt+ag2YzSwgLnHryXwmiKMFJJbsOc8MYYtKvHz8jxWiXlTiTvt6Roj6fImm T0tYIXYJSpyc+QTqYUmJgytusExgFJuFZOwsJC2zkLRAxPUkbkydwgZha0ssW/iaGcLWlZjx 7xALsvgCRvZVjKKZOQUlSbnpBoZ6qcmZJak5qXrJ+bmbGCFJ7PkOxl/zVQ4xCnAwKvHwRqyL 9xNiTSwrrsw9xCjJwaQkyiudkOAnxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3IgtQjjclsbIq tSgfJuUKDPyJzFLcyfnAxJxXEm9sYICboyTO+zT5ja+QQDowZWanphakFsHMkeHgUJLgNUkG WiFYlJqeWpGWmVOCkGbi4AQ5gwfojPMgNbzFBYm5xZnpEPlTjIpS4rybQBICIImM0jy4XlDm qv////8rRnGgp4V5L4BU8QCzHlz3K6DBTECD/2nHgwwG5hq4lFQDo9qniq1r1ueJyR1iP/rf Urfr/JWguCde6s8MFnisKmo69SlO+NNuw409n80nHxXQUrn2OTEwJ7b7fZNmwMejDy6GvbBw mqOv2SO413dWxE33y5NVV9ZKfJFN5vnUrfH/zcHTImq6B3YFRO6/sH31DLH3b2ZwB+4NCp9r f+Lmy1U7PUOuCOnstVJiKc5INNRiLipOBADbF8WRNwQAAA== Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 , "iesg@ietf.org" , IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 05:04:16 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46DILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting= ) which I've acknowledged and corrected in this thread (please see http://w= ww.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that orig= inates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP= /MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes t= o improve traffic distribution in the IP/MPLS domain which employs ECMP, flo= w labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed= in http://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves= the original issue I've raised of both GAL and flow label "competing" for t= he BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on P= Ws?- remains open as noted in Greg's comment (please see http://www.ietf.org= /mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should ackno= wledge the fact (implicitly recognized already in RFC 5920) that there is s= imply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha ________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf= .org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draf= t (for MS-PW) - please see my email (to several lists) that explains that in= some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.= html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain,= hence he enables insertion and discard of "flow labels" at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that prop= oses that S-PEs insert FLs in the stack, and it never occurred to me that an= yone anyone would try, since would require a change to the design of the S-P= Es. Stewart This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46DILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Stewart,
Lots of thanks for a prompt response.
 
My original email contained a typo (S-PE= instead of T-PE  named as inserting ) which I've acknowledged and corr= ected in this thread (please see = http://www.ietf.org/mail-archive/web/pwe3/current/ms= g12586.html).
 
With this correction in mind, the exampl= e I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domai= n and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov= 's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, f= low labels would be inserted by T-PE.
 
I believe that the change in draft-ietf-= pwe3-gal-in-pw that you've proposed in = http://www.ietf.org/mail-archive/web/pwe3/current/ms= g12613.html resolves the original issue I've raised of both= GAL and flow label "competing" for the BoS position. 
 
However, a conceptual question - can= any MPLS-TP restrictions be placed on PWs?- remains open as noted in G= reg's comment (please see = http://www.ietf.org/mail-archive/web/pwe3/current/ms= g12620.html). IMHO and FWIW we should acknowledge the fact (impli= citly recognized  already in RFC 5920) that there is simply no such thing as a MPLS-TP PW.
 
Hopefully this note clarifies my positio= n on the subject.
 
Regards, and apologies for the original= typo,
     Sasha
 
From: Stewart Brya= nt [stbryant@cisco.com]
Sent: Thursday, September 01, 2011 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@too= ls.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-= gal-in-pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point th= at I've raised in my IETF LC comment on the draft (for MS-PW) - please see m= y email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.<= /div>
 
Regards,
Sasha

The operator intends to improve traffic distr= ibution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that prop= oses that S-PEs insert FLs in the stack, and it never occurred to me that an= yone anyone would try, since would require a change to the design of the S-P= Es.

Stewart


This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46DILPTMAIL02e_-- From matthew.bocci@alcatel-lucent.com Fri Sep 2 03:05:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBDA21F8FFA; Fri, 2 Sep 2011 03:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.806 X-Spam-Level: X-Spam-Status: No, score=-105.806 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CipKCjXaNHFu; Fri, 2 Sep 2011 03:05:45 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97B21F8FF9; Fri, 2 Sep 2011 03:05:45 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p82A6bfV015129 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Sep 2011 12:07:14 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 2 Sep 2011 12:06:43 +0200 From: "Bocci, Matthew (Matthew)" To: Alexander Vainshtein , Stewart Bryant Date: Fri, 2 Sep 2011 12:06:40 +0200 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxpWAPrGACkObeVThu0S15T5SOcEw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA8662F517069matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 , "iesg@ietf.org" , IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 10:05:46 -0000 --_000_CA8662F517069matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, On your final comment on the concept of an MPLS-TP PW, RFC5586 has already = made the distinction between the use of the GAL on PWs in MPLS-TP and in ot= her MPLS environments. This draft aligns the two cases in terms of the appl= icability of the GAL, by updating RFC5586 to remove the restriction on its = use and position in an MPLS-TP environment. The case of interconnecting PW segments on MPLS-TP to PW segments on genera= l MPLS networks should be discussed elsewhere, IMHO, as the interaction bet= ween the GAL and hashing on some PW segments is most likely not the only is= sue. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would no= t expect an MPLS-TP PSN to hash the flow label today. If that is going to c= hange or if there are other flow label applications in MPLS-TP, then IMHO d= rafts detailing those applications should discuss the interaction with the = GAL. Regards, Matthew On 02/09/2011 06:05, "Alexander Vainshtein" > wrote: Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as insertin= g ) which I've acknowledged and corrected in this thread (please see http:/= /www.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that ori= ginates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an = IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishe= s to improve traffic distribution in the IP/MPLS domain which employs ECMP,= flow labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed= inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves= the original issue I've raised of both GAL and flow label "competing" for = the BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on = PWs?- remains open as noted in Greg's comment (please see http://www.ietf.o= rg/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should ac= knowledge the fact (implicitly recognized already in RFC 5920) that there = is simply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha ________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org<= mailto:iesg@ietf.org>; pwe3-chairs@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the dra= ft (for MS-PW) - please see my email (to several lists) that explains that = in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg125= 81.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain,= hence he enables insertion and discard of "flow labels" at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that pro= poses that S-PEs insert FLs in the stack, and it never occurred to me that = anyone anyone would try, since would require a change to the design of the = S-PEs. Stewart This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_CA8662F517069matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sasha,

On your final comment on the concept of an MPLS-TP PW, RFC5586 has = already made the distinction between the use of the GAL on PWs in MPLS-TP a= nd in other MPLS environments. This draft aligns the two cases in terms of = the applicability of the GAL, by updating RFC5586 to remove the restriction= on its use and position in an MPLS-TP environment. 

The case of interconnecting PW segments on MPLS-TP to PW segments o= n general MPLS networks should be discussed elsewhere, IMHO, as the interac= tion between the GAL and hashing on some PW segments is most likely not the= only issue. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one = would not expect an MPLS-TP PSN to hash the flow label today. If that is go= ing to change or if there are other flow label applications in MPLS-TP, the= n IMHO drafts detailing those applications should discuss the interaction w= ith the GAL. 

Regards,

Matthew

= On 02/09/2011 06:05, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com> wrote:

Stewart,
Lots of thanks for a prompt respons= e.
 
= My original email contained a typo (S-PE ins= tead of T-PE  named as inserting ) which I've acknowledged and correct= ed in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/= msg12586.html).
=  
With this correction= in mind, the example I've presented (an MS-PW that originates in a T-= PE in a MPLS-TP domain and them crosses - at S-PE - into an IP/MPLS domain)= matches, IMHO, Yaakov's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, = flow labels would be inserted by T-PE.
 
I believe that the change in draft-ietf-pwe3-gal-in-pw that you've prop= osed inhttp://www.ietf.org/mail-archive/web/pwe3/c= urrent/msg12613.html resolves the original issue I've raise= d of both GAL and flow label "competing" for the BoS position. 
&nb= sp;
However, a conceptual question= - can any MPLS-TP restrictions be placed on PWs?- remains open as= noted in Greg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/= msg12620.html). IMHO and FWIW we should acknowledge the fact (im= plicitly recognized  already in RFC 5920) that there is simply no such thing as a MPLS-TP PW.
 
Hopefully this note clarifies my position on the = subject.
 
Regards, and apologies for the origina= l typo,
   &= nbsp; Sasha
 
From: Stewart Bryant [stbryant@cisco.com]
Sent: Thursday, September 01, 2011= 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf.org; Luca Martini; IETF Discussion
Subj= ect: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in= -pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain=
This is = exactly the point that I've raised in my IETF LC comment on the draft (for = MS-PW) - please see my email (to several lists) that explains that in some = detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.=
 
Regards,
Sasha

The operator intends to improve= traffic distribution in the IP/MPLS domain, hence he enables insertio= n and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that pro= poses that S-PEs insert FLs in the stack, and it never occurred to me that = anyone anyone would try, since would require a change to the design of the = S-PEs.

Stewart


This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_CA8662F517069matthewboccialcatellucentcom_-- From internet-drafts@ietf.org Fri Sep 2 05:53:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7321F8FC9; Fri, 2 Sep 2011 05:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CA8RpX4iUoy; Fri, 2 Sep 2011 05:53:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F95121F8FC3; Fri, 2 Sep 2011 05:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902125334.22652.83723.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 05:53:34 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-fault-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 12:53:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Fault Management OAM Author(s) : George Swallow Annamaria Fulignoli Martin Vigoureux Sami Boutros David Ward Filename : draft-ietf-mpls-tp-fault-07.txt Pages : 17 Date : 2011-09-02 This document specifies Operations, Administration, and Maintenance messages to indicate service disruptive conditions for MPLS based Transport Network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-07.txt From Alexander.Vainshtein@ecitele.com Fri Sep 2 08:00:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7321F8B49 for ; Fri, 2 Sep 2011 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[AWL=0.972, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDUUg-TNB8XI for ; Fri, 2 Sep 2011 08:00:40 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id EC4CE21F8B45 for ; Fri, 2 Sep 2011 08:00:39 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1314975719!57518320!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.3.6; banners=-,-,- Received: (qmail 21590 invoked from network); 2 Sep 2011 15:02:00 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-21.messagelabs.com with SMTP; 2 Sep 2011 15:02:00 -0000 X-AuditID: 93eaf2e7-b7c4dae0000018d7-bf-4e60efeb822e Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 30.DF.06359.BEFE06E4; Fri, 2 Sep 2011 18:02:03 +0300 (IDT) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 2 Sep 2011 18:02:13 +0300 From: Alexander Vainshtein To: "Bocci, Matthew (Matthew)" , Stewart Bryant Date: Fri, 2 Sep 2011 18:02:12 +0300 Thread-Topic: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw Thread-Index: AcxpWAPrGACkObeVThu0S15T5SOcEwAKFKr9 Message-ID: References: , 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_A3C5DF08D38B6049839A6F553B331C760111EF7BD46FILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLsWRmVeSWpSXmKPExsUy+dWnL7qv3yf4GSzbYGox489EZotnG+ez WDy/85fd4nDXXUaLW0tXslq0rz3LYtH3aQuLxbmncxgtPnT9YHXg9Gh9tpfVY8rvjaweS5b8 ZPKYtDbN48vlz2wBrFENjDaJeXn5JYklqQopqcXJtkoBRZllicmVSgqZKbZKhkoKBTmJyam5 qXkltkqJBQWpeSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMlOTdnQ2JorJCOz WCFVNzcxM0chN7W4ODE9VQEokrCFOaPt2nOWgu2NjBWLz3s2MC7N62Lk5JAQMJG4ce4dE4Qt JnHh3nq2LkYuDiGBvYwST7rPQjmTGSW+tf9iBaliE7CV2LT6LhuILSKQIdHcMpkFpIhZoIFJ 4vvNTvYuRg4OFgEViVm98iA1wgIBEheWNbNC1AdKtJ5+xAhSIiJgJPF8VwxImBco/GMNSBhk VzOjROv2F+wgCU4BO4nnFyeD7WIEuu77qTVglzILiEvcejIf6moBiSV7zjND2KISLx//Y4Wo F5W4076eEaI+X+L10S4miGWCEidnPmGBqJeUOLjiBssERrFZSMbOQtIyC0kLRFxP4sbUKWwQ trbEsoWvmSFsXYkZ/w6xIIsvYGRfxSiamVNQkpSbbmCol5qcWZKak6qXnJ+7iRGS2p7vYPw1 X+UQowAHoxIPb8S6eD8h1sSy4srcQ4ySHExKorzf3iX4CfEl5adUZiQWZ8QXleakFh9ilOBg VhLh/TURKMebklhZlVqUD5NyBQb+RGYp7uR8YLrOK4k3NjDAzVES532a/MZXSCAdmDSzU1ML Uotg5shwcChJ8JoA84KQYFFqempFWmZOCUKaiYMT5AweoDOiQGp4iwsSc4sz0yHypxh1Odad XnKcUYglLz8vVUqcNwikSACkKKM0D24OKM/V/////xWjODAAhCFG8QBzJNykV0BLmICW/NOO B1kCzEJwKakGxtyG3sOT9Vq0U+0iz2d9kf5kvrvKeeaa21v9/GqyZQ0COJcz+UhwnTvSdtdt 40mjSRLuCiczTk/LfhVo7Gt/0H96ZobuvXULnaMv2j02OLWgiVEhWrln3rRjPwyamXfeOz/h RuZFFZZIw82sDjxTjiuZ3aqYsPjrwakhoVOmqVX7pNY3Prg3TYmlOCPRUIu5qDgRAG9MKp5O BAAA Cc: "mpls@ietf.org" , "pwe3-chairs@tools.ietf.org" , pwe3 , "iesg@ietf.org" , IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 15:00:42 -0000 --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46FILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Matthew, Lots of thanks for a prompt response. Please see a couple of comments inline below. Regards, Sasha ________________________________ From: Bocci, Matthew (Matthew) [matthew.bocci@alcatel-lucent.com] Sent: Friday, September 02, 2011 1:06 PM To: Alexander Vainshtein; Stewart Bryant Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf= .org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw Sasha, On your final comment on the concept of an MPLS-TP PW, RFC5586 has already m= ade the distinction between the use of the GAL on PWs in MPLS-TP and in othe= r MPLS environments. This draft aligns the two cases in terms of the applica= bility of the GAL, by updating RFC5586 to remove the restriction on its use= and position in an MPLS-TP environment. [[Sasha]] IMHO and FWIW this is one more indication that there is no such th= ing as an MPLS-TP PW as different from an MPLS TP. Did I miss something impo= rtant? The case of interconnecting PW segments on MPLS-TP to PW segments on general= MPLS networks should be discussed elsewhere, IMHO, as the interaction betwe= en the GAL and hashing on some PW segments is most likely not the only issue= . [[Sasha]] Sounds OK with me. RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expe= ct an MPLS-TP PSN to hash the flow label today. [[Sasha]] I make a distinction between inserting a flow label at T-PE and ha= shing on the label stack (or lack thereof) in some of the network domains th= at are crossed by the MS-PW packet. The hashing is done (or not done) by P r= outers that do not specifically care about PWs. If that is going to change or if there are other flow label applications in= MPLS-TP, then IMHO drafts detailing those applications should discuss the i= nteraction with the GAL. [[Sasha]] Please see above. IMHO there is no need for a new application to s= tudy the interaction. Regards, Matthew On 02/09/2011 06:05, "Alexander Vainshtein" > wrote: Stewart, Lots of thanks for a prompt response. My original email contained a typo (S-PE instead of T-PE named as inserting= ) which I've acknowledged and corrected in this thread (please see http://w= ww.ietf.org/mail-archive/web/pwe3/current/msg12586.html). With this correction in mind, the example I've presented (an MS-PW that orig= inates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an IP= /MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes t= o improve traffic distribution in the IP/MPLS domain which employs ECMP, flo= w labels would be inserted by T-PE. I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed= inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves= the original issue I've raised of both GAL and flow label "competing" for t= he BoS position. However, a conceptual question - can any MPLS-TP restrictions be placed on P= Ws?- remains open as noted in Greg's comment (please see http://www.ietf.org= /mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW we should ackno= wledge the fact (implicitly recognized already in RFC 5920) that there is s= imply no such thing as a MPLS-TP PW. Hopefully this note clarifies my position on the subject. Regards, and apologies for the original typo, Sasha ________________________________ From: Stewart Bryant [stbryant@cisco.com] Sent: Thursday, September 01, 2011 8:33 PM To: Alexander Vainshtein Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@tools.ietf.org; Luca Martini; IETF Discussion Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-= pw On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draf= t (for MS-PW) - please see my email (to several lists) that explains that in= some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.= html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain,= hence he enables insertion and discard of "flow labels" at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that prop= oses that S-PEs insert FLs in the stack, and it never occurred to me that an= yone anyone would try, since would require a change to the design of the S-P= Es. Stewart This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46FILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Matthew,
Lots of thanks for a prompt response.
 
Please see a couple of comments inline b= elow.
 
Regards,
     Sasha
 
From: Bocci, Matth= ew (Matthew) [matthew.bocci@alcatel-lucent.com]
Sent: Friday, September 02, 2011 1:06 PM
To: Alexander Vainshtein; Stewart Bryant
Cc: Yaakov Stein; mpls@ietf.org; pwe3; iesg@ietf.org; pwe3-chairs@too= ls.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-= gal-in-pw

Sasha,

On your final comment on the concept of an MPLS-TP PW, RFC5586 has alre= ady made the distinction between the use of the GAL on PWs in MPLS-TP and in= other MPLS environments. This draft aligns the two cases in terms of the ap= plicability of the GAL, by updating RFC5586 to remove the restriction on its use and position in an MPLS-TP env= ironment. 
 
[[Sasha]] IMHO and= FWIW this is one more indication that there is no such thing as an MPLS-TP= PW as different from an MPLS TP. Did I miss something important?

 
The case of interconnecting PW segments on MPLS-TP to PW segments on ge= neral MPLS networks should be discussed elsewhere, IMHO, as the interaction= between the GAL and hashing on some PW segments is most likely not the only= issue.
 
[[Sasha]] Sounds OK with me.
 
RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not= expect an MPLS-TP PSN to hash the flow label today.
 
[[Sasha]] I make a= distinction between inserting a flow label at T-PE and hashing on the label= stack (or lack thereof) in some of the network domains that are crossed by= the MS-PW packet. The hashing is done (or not done) by P routers that do not specifically care about PWs.
 
If that is going to change or if there are other flow label application= s in MPLS-TP, then IMHO drafts detailing those applications should discuss t= he interaction with the GAL. 
 
[[Sasha]] Please s= ee above. IMHO there is no need for a new application to study the interacti= on.

Regards,

Matthew

On 02/09/2011 06:05, "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com&= gt; wrote:

Stewart,
Lots of thanks for a prompt response.
 
My original email contained a typo (S-PE= instead of T-PE  named as inserting ) which I've acknowledged and corr= ected in this thread (please see http://www.ietf.org/mail-archive/web/pwe3/current/ms= g12586.html).
 
With this correction in mind, the exampl= e I've presented (an MS-PW that originates in a T-PE in a MPLS-TP domai= n and them crosses - at S-PE - into an IP/MPLS domain) matches, IMHO, Yaakov= 's question. And if the operator wishes to improve traffic distribution in the IP/MPLS domain which employs ECMP, f= low labels would be inserted by T-PE.
 
 
However, a conceptual question - can= any MPLS-TP restrictions be placed on PWs?- remains open as noted in G= reg's comment (please see http://www.ietf.org/mail-archive/web/pwe3/current/ms= g12620.html). IMHO and FWIW we should acknowledge the fact (impli= citly recognized  already in RFC 5920) that there is simply no such thing as a MPLS-TP PW.
 
Hopefully this note clarifies my positio= n on the subject.
 
Regards, and apologies for the original= typo,
     Sasha
 
From: Stewart Brya= nt [stbryant@cisco.com]
Sent: Thursday, September 01, 2011 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; mpls@ietf.org;= pwe3; iesg@ietf.org; pwe3-chairs= @tools.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-= gal-in-pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point th= at I've raised in my IETF LC comment on the draft (for MS-PW) - please see m= y email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.=
 
Regards,
Sasha

The operator intends to improve traffic distr= ibution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that prop= oses that S-PEs insert FLs in the stack, and it never occurred to me that an= yone anyone would try, since would require a change to the design of the S-P= Es.

Stewart


This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD46FILPTMAIL02e_-- From iesg-secretary@ietf.org Fri Sep 2 09:13:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169D621F8B70; Fri, 2 Sep 2011 09:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5brD5l-HSlT; Fri, 2 Sep 2011 09:13:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5207921F8B51; Fri, 2 Sep 2011 09:13:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902161317.17696.19966.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 09:13:17 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS Fault Management OAM) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 16:13:18 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS Fault Management OAM' as a Proposed Standard 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 2011-09-16. 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. Abstract This document specifies Operations, Administration, and Maintenance messages to indicate service disruptive conditions for MPLS based Transport Network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-fault/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-fault/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1460/ From Manuel.Paul@telekom.de Fri Sep 2 10:00:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783B521F8C3A for ; Fri, 2 Sep 2011 10:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjs1lwdHqHOC for ; Fri, 2 Sep 2011 10:00:07 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E800421F8C37 for ; Fri, 2 Sep 2011 10:00:06 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 02 Sep 2011 19:01:40 +0200 Received: from HE101452.emea1.cds.t-internal.com ([169.254.2.253]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Fri, 2 Sep 2011 19:01:39 +0200 From: To: , Date: Fri, 2 Sep 2011 19:01:38 +0200 Thread-Topic: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt Thread-Index: AcxmprVPCkvtYyGgRVyBvr/Ks7SrjwC6fl9Q Message-ID: <9435EDACD941174099E143BCA2BCD615F7AD796112@HE101452.emea1.cds.t-internal.com> References: <4E497423.8030001@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD6A9329A7C0A@SJEXCHCCR02.corp.ad.broadcom.com> <4E56B475.408@lab.ntt.co.jp> <4E5BF1C0.3010300@lab.ntt.co.jp> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: tsg15q10@lists.itu.int, mpls@ietf.org, ahmpls-tp@lists.itu.int, huubatwork@gmail.com Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-tp-li-lb-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 17:00:08 -0000 SGkgWW9zaGlub3JpIGFuZCBTYW1pLA0KDQpQbGVhc2UgYWxsb3cgbWUgdG8ganVtcCBpbiwgYWRk aW5nIDIgY2VudHMgaW5saW5lIGJlbG93IG1hcmtlZCB3aXRoIFtNUF0uDQoNClRoYW5rcywNCk1h bnVlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ IFNhbWkgQm91dHJvcw0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTEgMTo1MiBBTQ0K PiBUbzogWW9zaGlub3JpIEtvaWtlDQo+IENjOiB0c2cxNXExMEBsaXN0cy5pdHUuaW50OyBtcGxz QGlldGYub3JnOyBNUExTLVRQIGFkIGhvYyB0ZWFtOw0KPiBodXViYXR3b3JrQGdtYWlsLmNvbQ0K PiBTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gZHJh ZnQtaWV0Zi1tcGxzLXRwLWxpLQ0KPiBsYi0wMy50eHQNCj4NCj4gSGkgWW9zaGlub3JpLA0KPg0K PiBQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCj4NCj4gQXQgMDE6MDggUE0gOC8yOS8y MDExLCBZb3NoaW5vcmkgS29pa2Ugd3JvdGU6DQo+ID5EZWFyIFNhbWksDQo+ID4NCj4gPlRoYW5r IHlvdSBmb3IgdGhlIHJlcGx5IGFuZCBjbGFyaWZpY2F0aW9uLiBTZWUgaW5saW5lIG1hcmtlZCB3 aXRoDQo+ID5bWUtdLCBwbGVhc2UuDQo+ID4NCj4gPigyMDExLzA4LzI5IDA6NDgpLCBTYW1pIEJv dXRyb3Mgd3JvdGU6DQo+ID4+WW9zaGlub3JpLA0KPiA+Pg0KPiA+PklzIHRoaXMgdGhlIHByb3Bv c2VkIHRleHQgeW91IGFyZSByZWZlcnJpbmcgdG9vPyBJZiBzbyB3ZSBjYW4gYWRkIHNvbWUNCj4g Pj5vZiB0aGlzIHRleHQgLi4NCj4gPj4NCj4gPj5TdGFydCBvZiB0ZXh0Li4uDQo+ID4+RGF0YSBw bGFuZSBsb29wYmFjayBpcyBhbiBvdXQtb2Ytc2VydmljZSBmdW5jdGlvbiwgYXMgcmVxdWlyZWQN Cj4gPj5pbiBzZWN0aW9uIDIuMi41IG9mIFJGQyA1ODYwIFsxMV0uIFRoaXMgZnVuY3Rpb24gcGVy bWl0cyBhbGwNCj4gPj50cmFmZmljKGluY2x1ZGluZyB1c2VyIGRhdGEgYW5kIE9BTSwgd2l0aCB0 aGUgZXhjZXB0aW9uIG9mIHRoZQ0KPiA+PmRpc2FibGUgbG9vcGJhY2sgY29tbWFuZCkuIFRoZSB0 cmFmZmljIGlzIG9yaWdpbmF0ZWQgZnJvbQ0KPiA+Pm9uZSBpbnRlcm5hbCBwb2ludCBhdCB0aGUg aW5ncmVzcyBvZiBhIHRyYW5zcG9ydCBwYXRoIHdpdGhpbiBhDQo+ID4+aW50ZXJmYWNlIG9yIGlu c2VydGVkIGZyb20gaW5wdXQgcG9ydCBvZiBhbiBpbnRlcmZhY2UgYnkgdGhlDQo+ID4+ZXh0ZXJu YWwgdGVzdCBlcXVpcG1lbnQgdG8gYmUgbG9vcGVkIGJhY2sgdW5tb2RpZmllZCAob3RoZXIgdGhh bg0KPiA+Pm5vcm1hbCBwZXIgaG9wIHByb2Nlc3Npbmcgc3VjaCBhcyBUVEwgZGVjcmVtZW50KS4g QWxsIHRoZSB0cmFmZmljDQo+ID4+YXJlIGxvb3AgYmFja2VkIGluIHRoZSBkaXJlY3Rpb24gb2Yg dGhlIHBvaW50IG9mIG9yaWdpbiBieSBhbg0KPiA+PmludGVyZmFjZSBhdCBlaXRoZXIgYW4gaW50 ZXJtZWRpYXRlIG5vZGUgb3IgYSB0ZXJtaW5hdGluZyBub2RlLg0KPiA+Pg0KPiA+Pkl0IHNob3Vs ZCBiZSBub3RlZCB0aGF0IGRhdGEgcGxhbmUgbG9vcGJhY2sgZnVuY3Rpb24gaXRzZWxmIGlzDQo+ ID4+YXBwbGllZCBiZXR3ZWVuIGRhdGEtcGxhbmUgbG9vcGJhY2sgcG9pbnRzIHdpdGhpbiBpbnRl cmZhY2VzDQo+ID4+d2hpY2ggaXMgZGlmZmVyZW50IGZyb20gTUlQL01FUC4NCj4gPj5FbmQgb2Yg dGV4dC4uLg0KPiA+DQo+ID5bWUtdDQo+ID5Db3JyZWN0LiBIb3dldmVyLCBpdCB3aWxsIGJlIGJl dHRlciB0byBhbGlnbiB3aXRoIHRoZSB0ZXh0IGluDQo+ID5zZWN0aW9uIDYuMyBvZiBvYW0tZnJh bWV3b3JrLWRyYWZ0LiBNeSBzdWdnZXN0aW9uIGlzIHRvIG1lcmdlIHRoZQ0KPiA+Zm9sbG93aW5n IHR3byBwYXJ0cy4NCj4gPg0KPiA+Ikl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGRhdGEgcGxhbmUg bG9vcGJhY2sgZnVuY3Rpb24gaXRzZWxmIGlzDQo+ID5hcHBsaWVkIHRvIGRhdGEgcGxhbmUgbG9v cGJhY2sgcG9pbnRzIHRoYXQgY2FuIHJlc2lkZXMgb24gZGlmZmVyZW50DQo+ID5pbnRlcmZhY2Vz IGZyb20gTUlQcy9NRVBzLiINCj4gPg0KPiA+ImFsbCB0cmFmZmljIChpbmNsdWRpbmcgYm90aCBw YXlsb2FkIGFuZCBPQU0pIHJlY2VpdmVkIG9uIHRoZSBsb29wZWQNCj4gPmJhY2sgaW50ZXJmYWNl IGlzIHNlbnQgb24gdGhlIHJldmVyc2UgZGlyZWN0aW9uIG9mIHRoZSB0cmFuc3BvcnQNCj4gPnBh dGguIFRoZSB0cmFmZmljIGlzIGxvb3BlZCBiYWNrIHVubW9kaWZpZWQgb3RoZXIgdGhhbiBub3Jt YWwgcGVyDQo+ID5ob3AgcHJvY2Vzc2luZyBzdWNoIGFzIFRUTCBkZWNyZW1lbnQuIg0KPg0KPiBT YW1pOiBTdXJlIHdpbGwgYWRkIHRoaXMgdG9vLg0KPg0KPiA+SW4gYWRkaXRpb24gdG8gYWRkaW5n IHRoZSB0ZXh0LCBJIHRoaW5rIHRoZSBmb2xsb3dpbmcgc2VudGVuY2VzIG5lZWQNCj4gPnRvIGJl IG1vZGlmaWVkIHRvIGF2b2lkIGEgbWlzdW5kZXJzdGFuZGluZyBvciBhIGNvbnRyYWRpY3Rpb24u ICgiVGhlDQo+ID5sb29wYmFjayBmdW5jdGlvbiBpcyBvcGVyYXRlZCBieSBOTVMiIHdvdWxkIGJl IGEgY29ycmVjdCBzZW50ZW5jZS4pDQo+ID5JcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+ DQo+IFNhbWk6IENvcnJlY3QuDQo+DQo+ID4iVGhlIExvb3BiYWNrIGZ1bmN0aW9uIGlzIG9wZXJh dGVkIGZyb20gTUVQIHRvIE1FUCBvbiBiaWRpcmVjdGlvbmFsDQo+ID4oYXNzb2NpYXRlZCBhbmQg Y28tcm91dGVkKSBMYWJlbCBTd2l0Y2hlZCBQYXRocyAoTFNQcyksIFBzZXVkb3dpcmVzDQo+ID4o aW5jbHVkaW5nIG11bHRpLXNlZ21lbnQgUHNldWRvd2lyZXMpLiBUaGUgTG9vcGJhY2sgZnVuY3Rp b24gaXMNCj4gPmFkZGl0aW9uYWxseSBvcGVyYXRlZCBmcm9tIE1FUCB0byBNSVAgb24gY28tcm91 dGVkIGJpZGlyZWN0aW9uYWwNCj4gPkxTUHMsIGFuZCBvbiBtdWx0aS1zZWdtZW50IFBzZXVkb3dp cmVzLiINCj4gPg0KPiA+PlBsZWFzZSBzZWUgQ29tbWVudHMgaW5saW5lLi4NCj4gPj5BdCAwMTo0 NSBQTSA4LzI1LzIwMTEsIFlvc2hpbm9yaSBLb2lrZSB3cm90ZToNCj4gPj4+RGVhciBhdXRob3Jz LA0KPiA+Pj4NCj4gPj4+SSBhZGRlZCBJVFUtVCBtYWlsaW5nIGxpc3RzIHRvIGFzayB0byBwdXQg bXkgY29tbWVudHMgaW4gSVRVLVQgbGlhaXNvbg0KPiA+Pj50byBJRVRGIGluIG9yZGVyIHRvIGRy YXcgYXR0ZW50aW9uIGFsc28gaW4gSVRVLVQuDQo+ID4+Pg0KPiA+Pj5JIHRoaW5rIGl0J3MgdmFs aWQgYW5kIGluZGlzcGVuc2FibGUgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbnMgYW5kDQo+ID4+PmNv bW1lbnRzIGZyb20gTXIuIFNoYXJhbSBEYXZhcmkgYXR0YWNoZWQgYXQgdGhlIGJvdHRvbS4gSSB3 b3VsZCBsaWtlDQo+ID4+PnRvIG1ha2UgYWRkaXRpb25hbCBjb21tZW50cyByZWxhdGVkIHRvIHRo ZW0uDQo+ID4+Pg0KPiA+Pj4oMSkgVGhlIGZvbGxvd2luZyBzZW50ZW5jZXMgaW4gc2VjdGlvbiAx LkludHJvZHVjdGlvbiBzaG91bGQgYmUNCj4gPj4+bW9kaWZpZWQgYnkgYWRkaW5nIGNsZWFyIGRl ZmluaXRpb24gb2YgZGF0YS1wbGFuZSBsb29wYmFjayBwb2ludCB3aGljaA0KPiA+Pj5kb2Vzbid0 IGNvaW5jaWRlIHdpdGggTUlQIG9yIE1FUC4gSSB0aGluayB0aGUgZGVzY3JpcHRpb25zIG5lZWQg dG8gYmUNCj4gPj4+Y2FyZWZ1bGx5IGFsaWduZWQgd2l0aCB0aGUgb2FtLWZyYW1ld29yayBkcmFm dC4NCj4gPj4+DQo+ID4+PiJUaGUgTG9vcGJhY2sgZnVuY3Rpb24gaXMgb3BlcmF0ZWQgZnJvbSBN RVAgdG8gTUVQIG9uIGJpZGlyZWN0aW9uYWwNCj4gPj4+KGFzc29jaWF0ZWQgYW5kIGNvLXJvdXRl ZCkgTGFiZWwgU3dpdGNoZWQgUGF0aHMgKExTUHMpLCBQc2V1ZG93aXJlcw0KPiA+Pj4oaW5jbHVk aW5nIG11bHRpLXNlZ21lbnQgUHNldWRvd2lyZXMpLiBUaGUgTG9vcGJhY2sgZnVuY3Rpb24gaXMN Cj4gPj4+YWRkaXRpb25hbGx5IG9wZXJhdGVkIGZyb20gTUVQIHRvIE1JUCBvbiBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbA0KPiA+Pj5MU1BzLCBhbmQgb24gbXVsdGktc2VnbWVudCBQc2V1ZG93aXJl cy4gVGhlIExvb3BiYWNrIGlzIGEgZnVuY3Rpb24NCj4gPj4+dGhhdCBlbmFibGVzIGEgTUVQIHRv IHJlcXVlc3QgYSBNRVAgb3IgYSBNSVAgdG8gZW50ZXIgYSBsb29wYmFjaw0KPiA+Pj5zdGF0ZS4i DQo+ID4+Pg0KPiA+Pj5BcyBJIHByb3Bvc2VkIGluIHRoZSBmb2xsb3dpbmcgbGFzdCBjYWxsIGNv bW1lbnRzICMzIG9uIG9hbS1mcmFtZXdvcmsNCj4gPj4+ZHJhZnQsIGluIG15IHVuZGVyc3RhbmRp bmcsIE1JUCBvciBNRVAgaXMgZGlmZmVyZW50IGZyb20gZGF0YS1wbGFuZQ0KPiA+Pj5sb29wYmFj ayBwb2ludC4NCj4gPj4+DQo+ID4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9tcGxzLXRwL2N1cnJlbnQvbXNnMDQ4ODcuaHRtbA0KPiA+Pj4NCj4gPj4+TUlQJk1FUCBhcmUg cmVsYXRlZCBvbmx5IHRvIE9BTSBwYWNrZXRzLiBPbiB0aGUgb3RoZXIgaGFuZCwgZGF0YS1wbGFu DQo+ID4+Pmxvb3BiYWNrIHBvaW50cyBhcmUgcmVsYXRlZCB0byBib3RoIE9BTSBwYWNrZXRzIGFu ZCBkYXRhIHBhY2tldHMuDQo+ID4+PlRoZXJlZm9yZSwgSSB0aGluayB0aGF0IHRoZSB0d28gcG9p bnRzIGFyZSBjbGVhcmx5IGRpZmZlcmVudCBmcm9tIHRoZQ0KPiA+Pj5mdW5jdGlvbmFsIHBlcnNw ZWN0aXZlLiBUaGUgY3VycmVudCBkZWZpbml0aW9ucyBvZiBNSVAgYW5kIE1FUCBpbg0KPiA+Pj5s aS1sYiBkcmFmdCBnbyBiZXlvbmQgdGhlIG9yaWdpbmFsIGRlZmluaXRpb25zIG9mIE1JUCBhbmQg TUVQLg0KPiA+Pj4NCj4gPj4+KDIpIEFsbCB0aGUgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb25z IGZyb20gTXIuIFNoYXJhbSBEYXZhcmkgc2hvdWxkDQo+ID4+PmJlIGNsYXJpZmllZCBpbiB0aGUg Y29udGV4dCBvZiB0aGUgZGVmaW5pdGlvbiBvZiBkYXRhLXBsYW5lIExCIHBvaW50Lg0KPiA+DQo+ ID5bWUtdIEkgaG9wZSB0aGF0IHlvdXIgY2xhcmlmaWNhdGlvbiBpbiB0aGUgcmVwbHkgdG8gaGlt IHdpbGwgYmUNCj4gPmFwcHJvcHJpYXRlbHkgcmVmbGVjdGVkIGluIHRoZSBuZXh0IHZlcnNpb24g Y29uc2lkZXJpbmcgaGlzIGZlZWRiYWNrLg0KPg0KPiBTYW1pOiBJIHdpbGwgc2VlIHdoYXQgY2Fu IGFwcGx5LCBvbmUgdGhpbmcgd2UgZG9uJ3Qgd2FudCB0byBkbyBpcyB0bw0KPiBkZXNjcmliZSBo b3cgTVBMUyBmb3J3YXJkaW5nIHdvcmtzIGFuZCBob3cgdG8gaGFuZGxlIE1QTFMgRndkaW5nDQo+ IGV4Y2VwdGlvbiwgb3IgaG93IHRvIGFwcGx5IGEgcG9saWN5IG9uIGEgZ2l2ZW4gSFc/DQo+DQo+ ID4+PigzKSBNb3JlIGRldGFpbHMgYWJvdXQgdGhlIGNvbmZpZ3VyYXRpb24gb2YgZGF0YS1wbGFu ZSBsb29wYmFjaw0KPiA+Pj5wb2ludChzKSBzaG91bGQgYmUgY2xhcmlmaWVkLg0KPiA+Pg0KPiA+ PlNhbWk6IENhbiB5b3UgcGxlYXNlIGJlIG1vcmUgc3BlY2lmaWM/IGlzIHRoaXMgcGFydCBvZiB0 aGUgdGV4dCB5b3UNCj4gPj53YW50byBhZGQgYWJvdmU/DQo+ID4NCj4gPltZS10gVGhlIGZvbGxv d2luZyBzZW50ZW5jZSBpbiBvYW0tZnJhbWV3b3JrIGlzIG1vcmUgdXNlZnVsIHRoYW4gbXkNCj4g PnByb3Bvc2VkIHRleHQuIEkgd291bGQgbGlrZSB0byBzZWUgbW9yZSBkZXRhaWxlZCBleHBsYW5h dGlvbiBhYm91dA0KPiA+Y29uZmlndXJhdGlvbi4gSXQgc2VlbXMgdXNlZnVsIHRvIHNob3cgYW4g ZXhhbXBsZSBvZiBhIHNlcmllcyBvZg0KPiA+Y29uZmlndXJhdGlvbiB0byBhcHBseSBkYXRhLXBs YW4gbG9vcGJhY2sgZnVuY3Rpb24gaW5jbHVkaW5nIHRlc3QgdHJhZmZpYy4NCj4gPg0KPiA+Iklu c3RlYWQsIHRlc3QgdHJhZmZpYyBpcyBpbnNlcnRlZCBhdCB0aGUgaW5ncmVzcyBvZiB0aGUgTUVH LiBUaGlzDQo+ID50ZXN0IHRyYWZmaWMgY2FuIGJlIGdlbmVyYXRlZCBmcm9tIGFuIGludGVybmFs IHByb2Nlc3MgcmVzaWRpbmcNCj4gPndpdGhpbiB0aGUgaW5ncmVzcyBub2RlIG9yIGluamVjdGVk IGJ5IGV4dGVybmFsIHRlc3QgZXF1aXBtZW50DQo+ID5jb25uZWN0ZWQgdG8gdGhlIGluZ3Jlc3Mg bm9kZS4iDQo+DQo+IFNhbWk6IFdvdWxkbid0IHRoaXMgYmUgYW4gaW1wbGVtZW50YXRpb24gZGV0 YWlsPw0KDQpbTVA6XSBBcyBpdCB3YXMgYWxyZWFkeSBpbnRyb2R1Y2VkIGluIHRoZSBPQU0gRnJh bWV3b3JrLCBpdCB3b3VsZCBuZWVkIHRvIGJlIGV4cGFuZGVkIHNvbWV3aGVyZS4gVGhpcyBpcyB0 aGUgcmlnaHQgcGxhY2UgdG8gZG8gdGhhdCBJTUhPLg0KQW4gYXBwbGljYXRpb24gc2NlbmFyaW8g ZXhhbXBsZSB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgYW5kIGNhbiBiZSBwcm92aWRlZCB3aXRob3V0 IGFueSBub2RlIGludGVybmFscy4NCkkuRS4gaXQgd291bGQgYmUgc3VmZmljaWVudCB0byBhZGQg dHdvIGV4YW1wbGUgbmV0d29yayBzY2VuYXJpbyBkaWFncmFtcywgd2hlcmU6DQoxKSBhbiBhYnN0 cmFjdCB0ZXN0IHRyYWZmaWMgcHJvY2Vzc29yIHJlc2lkZXMgd2l0aGluIGFuIGluZ3Jlc3Mgbm9k ZQ0KMikgdGVzdCB0cmFmZmljIGlzIGdlbmVyYXRlZCBieSBhbiAiYWJzdHJhY3QiIGV4dGVybmFs IHRlc3QgZ2VuZXJhdG9yLCB0aGF0IGlzIGNvbm5lY3RlZCB0byB0aGUgaW5ncmVzcyBub2RlDQoN Cj4NCj4gPkFub3RoZXIgcGFydCBJIHdhbnRlZCB0byByZWZlciB0byBpcyB0aGUgZm9sbG93aW5n IHBhcnQuDQo+ID4NCj4gPiJJZiB0aGUgZGF0YSBwbGFuZSBsb29wYmFjayBwb2ludCBpcyBzZXQg c29tZXdoZXJlIGF0IGludGVybWVkaWF0ZQ0KPiA+cG9pbnQgaW4gYmlkaXJlY3Rpb25hbCB0cmFu c3BvcnQgcGF0aCwgdGhlIHNpZGUgb2YgbG9vcCBiYWNrDQo+ID5mdW5jdGlvbihvbmUgc2lkZSBv ciBib3RoIHNpZGUpIG5lZWRzIHRvIGJlIGNvbmZpZ3VyZWQuDQo+ID4oZW5kIG9mIHByb3Bvc2Vk IHRleHRzKSINCj4NCj4gU2FtaTogU3VyZSB3ZSBjYW4gYWRkIHRoaXMgdG8gZGVzY3JpYmUgbW9y ZSB0aGUgTG9vcGJhY2sgZnVuY3Rpb24uDQo+DQo+ID5SZWdhcmRpbmcgYW4gaW50ZXJtZWRpYXRl IGxvb3BiYWNrIHBvaW50LCB0aGVyZSBjb3VsZCBiZSB0d28gc2lkZXMNCj4gPndoaWNoIGNhbiBs b29wYmFjayB0aGUgdHJhZmZpYy4gUHJvYmFibHkgdGhlIHNpZGUgbmVlZHMgdG8gYmUNCj4gPmNv bmZpZ3VyZWQgZnJvbSBOTVMsIGJlY2F1c2UgZnJvbSBhbiBpbnRlcm1lZGlhdGUgcG9pbnQsIHRo ZXJlIGFyZQ0KPiA+dHdvIHBvc3NpYmxlIHBvaW50IGF0IHdoaWNoIHRlc3QgdHJhZmZpYyBpcyBp bnNlcnRlZCBpbiBhIHRyYW5zcG9ydA0KPiA+cGF0aC4gT3IgYm90aCBzaWRlcyBhcmUgYXV0b21h dGljYWxseSBzZXQgZm9yIGxvb3BiYWNrIG1vZGUuDQo+DQo+IFNhbWk6IEFuIE5NUyBjYW4gc2V0 IGJvdGggc2lkZXMgdG8gbG9vcGJhY2sgaWYgaXQgd2FudHMgdG9vLCBzbyB3aWxsDQo+IHVzZSB0 aGUgdGV4dCB5b3UgcHJvcG9zZSBhYm92ZS4NCj4NCj4gPj4+VGhpcyBpcyByZWxhdGVkIHRvIG15 IGNvbW1lbnQgIzQgYWxzbyBpbiB0aGUgYWJvdmUgbGFzdCBjYWxsIGNvbW1lbnRzDQo+ID4+PiM0 IG9uIG9hbS1mcmFtZXdvcmsgZHJhZnQuIEluIHBhcnRpY3VsYXIsIGl0IHNob3VsZCBiZSBjbGFy aWZpZWQgaG93DQo+ID4+PnRvIGRlc2lnbmF0ZSBvciBzcGVjaWZ5IGEgZGF0YS1wbGFuZSBsb29w YmFjayBwb2ludCwgaWYgdGhlcmUgYXJlIG1vcmUNCj4gPj4+dGhhbiBvbmUgZGF0YS1wbGFuZSBs b29wYmFjayBwb2ludHMgd2l0aGluIGEgbm9kZS4gSSB0aGluayB0aGF0IHRoaXMNCj4gPj4+aXMg YWxzbyByZWxhdGVkIHRvIG9uZSBvZiB0aGUgbGFzdCBjYWxsIGNvbW1lbnRzIGZyb20gQWxlc3Nh bmRyby4NCj4gPj4NCj4gPj5TYW1pOiBJIGFzc3VtZSB0aGlzIGlzIGNvdmVyZWQgaW4geW91ciB0 ZXh0IGFib3ZlLCBjb3JyZWN0Pw0KPiA+DQo+ID5bWUtdIEkgdW5kZXJzdG9vZCB0aGF0IGFueSBk YXRhLXBsYW5lIGxvb3BiYWNrIHBvaW50cyBpcw0KPiA+ZW5hYmxlZC9kaXNhYmxlZCBieSBOTVMu IElmIHNvLCB0aGUgaWRlbnRpZmllcnMgYXJlIG5ldmVyIGV4Y2hhbmdlZA0KPiA+dGhyb3VnaCB0 aGUgT0FNIHByb3RvY29sIGFuZCB0aGV5IGFyZSBvbmx5IHJlbGF0ZWQgdG8gbWFuYWdlbWVudA0K PiA+b2JqZWN0cy4gSXMgdGhhdCBjb3JyZWN0Pw0KPg0KPiBTYW1pOiBDb3JyZWN0Lg0KPg0KPiA+ Pj5JZiB0aGUgcG9pbnQgY291bGQgYmUgc2V0IGJ5IE9BTSBtZXNzYWdlLCB0aGUgbWV0aG9kIGFu ZCBwcm90b2NvbA0KPiA+Pj5uZWVkcyB0byBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdC4NCj4g Pj4NCj4gPj5TYW1pOiBXZSBkZWNpZGVkIG5vdCB0byB1c2UgYW4gT0FNIG1lc3NhZ2UgdG8gc2V0 IHRoZSBMb29wYmFjayBwb2ludCwgaXQNCj4gPj5pcyBvbmx5IGRvbmUgdmlhIE1hbmFnZW1lbnQu DQo+ID4NCj4gPltZS10gVGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCj4NCj4gU2Ft aTogVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KPg0KPiBTYW1pDQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0 DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo= From internet-drafts@ietf.org Fri Sep 2 10:54:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC421F8C67; Fri, 2 Sep 2011 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2cJFh9wb7Ma; Fri, 2 Sep 2011 10:54:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E602221F8AF0; Fri, 2 Sep 2011 10:54:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902175429.18163.22771.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 10:54:29 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 17:54:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-04.txt Pages : 13 Date : 2011-09-02 This document specifies one function and describes a second function which are applicable to MPLS transport networks. The first function enables an operator to lock a transport path while the second enables an operator to set, in loopback, a given node along a transport path. This document also defines the extension to MPLS operation, administration, and maintenance (OAM) to perform the lock function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt From tnadeau@lucidvision.com Fri Sep 2 11:07:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4D621F8BE7 for ; Fri, 2 Sep 2011 11:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FARAxn99PNof for ; Fri, 2 Sep 2011 11:07:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 675C221F8BD8 for ; Fri, 2 Sep 2011 11:07:27 -0700 (PDT) Received: from [192.168.1.148] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6D43F1DD3106 for ; Fri, 2 Sep 2011 14:09:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Thomas Nadeau In-Reply-To: <20110902175429.18163.22771.idtracker@ietfa.amsl.com> Date: Fri, 2 Sep 2011 14:08:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9920BCD1-C943-4E37-9E7E-DA8085C7C3E2@lucidvision.com> References: <20110902175429.18163.22771.idtracker@ietfa.amsl.com> To: mpls@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: [mpls] draft-ietf-mpls-tp-li-lb-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 18:07:28 -0000 A few questions/concerns about this draft. First, there does not seem to be any consideration given to the = expiry of the locking of a path. Once locked, there is no way to say set = a timer to automatically reinstate the path. This raises the concern = that someone could close down one a path and then crash, never = reenabling that path until someone notices that it is down. To this = effect, I suggest that a path that is down either automatically reenable = itself after some period of time, or triggers some sort of alarms that = should be sent out. Second, this draft comes back to the concerns I raised recently = regarding the use of the OAM channel to control (or provision) network = nodes or paths, in this case, using a means that is adjacent to the = typical management protocols used by management systems (i.e.: SNMP, = Netconf, etc...). So as I pointed out before, this could cause a = discontinuity in the provisioning state of the network. For example, it = is possible using this mechanism, for someone at one end of a network, = to affect the provisioning state of many nodes elsewhere in the network. = Along this line, this also seems (to me) to violate the first = tenant/requirement of MPLS-TP in that it should be able to run without a = signaling protocol. Well, the more and more functions that are added to = the OAM channel, the more and more this is starting to look like a = control protocol. Finally, along the lines of the above points, I don't find the = Security section very comforting given that this mechanism, if hi-jacked = or just fat fingered, could disable an entire network of MPLS-TP paths = (or at least change its configuration) based on gaining access via the = authentication of a single node in that network.=20 --Tom On Sep 2, 2011, at 1:54 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Multiprotocol Label = Switching Working Group of the IETF. >=20 > Title : MPLS Transport Profile lock Instruct and = Loopback Functions > Author(s) : Sami Boutros > Siva Sivabalan > Rahul Aggarwal > Martin Vigoureux > Xuehui Dai > Filename : draft-ietf-mpls-tp-li-lb-04.txt > Pages : 13 > Date : 2011-09-02 >=20 > This document specifies one function and describes a second > function which are applicable to MPLS transport networks. The = first > function enables an operator to lock a transport path while the > second enables an operator to set, in loopback, a given node along > a transport path. This document also defines the extension to MPLS > operation, administration, and maintenance (OAM) to perform the > lock function. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Fri Sep 2 11:12:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17D521F8BDC; Fri, 2 Sep 2011 11:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GufRUrMTnNLq; Fri, 2 Sep 2011 11:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D961021F8BBD; Fri, 2 Sep 2011 11:12:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902181206.23367.2241.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 11:12:06 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-fastreroute-mib-21.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 18:12:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Multiprotocol Label Switching (MPLS) Traffic Engineering= Management Information Base for Fast Reroute Author(s) : Thomas D. Nadeau Cisco Systems Riza Cetin Filename : draft-ietf-mpls-fastreroute-mib-21.txt Pages : 50 Date : 2011-09-02 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-21.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-21.txt From kingstonsmiler@gmail.com Fri Sep 2 13:01:30 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471CE21F8C76 for ; Fri, 2 Sep 2011 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C3gFjmpGuww for ; Fri, 2 Sep 2011 13:01:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7835C21F8C42 for ; Fri, 2 Sep 2011 13:01:29 -0700 (PDT) Received: by wyg8 with SMTP id 8so2908096wyg.31 for ; Fri, 02 Sep 2011 13:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=q5x8mdcu/oK+T1eYYinhzr/HJiE6T++4D15LgPCz4Jk=; b=nOmkXcPmxlJuhwBBuCSeIBydY/F6W9IVW9xhuMFeE5Xt4GWFNJySzYkYwZP7wRVMV+ P2h7lFpMmOdKDMnZKVuFxStmNIKuCdbZ0GZu0oIW8kBgelyu6NIStE4bSuM7XBguUE85 stoCYoTX6f2/S3l7xJdDhqobVXBWCqQIWXyE4= MIME-Version: 1.0 Received: by 10.216.179.140 with SMTP id h12mr143936wem.45.1314993656130; Fri, 02 Sep 2011 13:00:56 -0700 (PDT) Received: by 10.216.73.73 with HTTP; Fri, 2 Sep 2011 13:00:56 -0700 (PDT) Date: Sat, 3 Sep 2011 01:30:56 +0530 Message-ID: From: Kingston Smiler To: mpls@ietf.org Content-Type: multipart/alternative; boundary=0016e65ae0c4c16b2304abfad19e Cc: sboutros@cisco.com, rahul@juniper.net, msiva@cisco.com Subject: [mpls] Comments on draft-ietf-mpls-tp-li-lb-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 20:01:30 -0000 --0016e65ae0c4c16b2304abfad19e Content-Type: text/plain; charset=ISO-8859-1 Hi, Couple of comments / question about this draft. 1. The Introduction section of the draft says that "The Loopback is a function that enables a MEP to request a MEP or a MIP to enter a loopback state." This gives the notion that one MEP can request other MEP / MIP to enter into loopback state. So can you please rephrase this 2.Section 1 says that "As per RFC 5860 [1], lock is an administrative state in which it is expected that no client traffic may be carried. However, test traffic and *OAM messages* dedicated to the transport path can be mapped on that transport path" So when the LSPs are in locked state, it can carry OAM messages. With this, if the user configures loopback on both ingress and egress MEP, then there is a possibility of all these OAM packets looped across these two endpoints (until TTL gets expired). Regards, S. Kingston Smiler. --0016e65ae0c4c16b2304abfad19e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Couple of comments / question about this draft.

1. The Introduction section of the draft says that=A0<= /div>

"The Loopback is a function that enables a = MEP to request a MEP or a MIP to enter a loopback state."

This gives the notion that one MEP can request other ME= P / MIP to enter into loopback state. So can you please rephrase this=A0

2.Section 1 says that=A0

"As per RFC 5860 [1], lock is an administrat= ive state in which it is=20 expected that no client traffic may be carried. However, test traffic=20 and OAM messages dedicated to the transport path can be mapped on th= at=20 transport path"

So when the LSPs are i= n locked state, it can carry OAM messages. With this, if the user configure= s loopback on=A0
both ingress and egress MEP, then there is a pos= sibility of all these OAM packets looped across these two endpoints=A0
(until TTL gets expired).

Regards,
= S. Kingston Smiler.
--0016e65ae0c4c16b2304abfad19e-- From internet-drafts@ietf.org Fri Sep 2 13:23:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD50421F8CD6; Fri, 2 Sep 2011 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZH6Xqm1-gih; Fri, 2 Sep 2011 13:23:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9CD21F8BFB; Fri, 2 Sep 2011 13:23:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110902202359.15884.77656.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 13:23:59 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-p2mp-lsp-ping-18.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 20:23:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Detecting Data Plane Failures in Point-to-Multipoint Mul= tiprotocol Label Switching (MPLS) - Extensions to LSP Ping Author(s) : Shaleen Saxena George Swallow Zafar Ali Adrian Farrel Seisho Yasukawa Thomas D. Nadeau Filename : draft-ietf-mpls-p2mp-lsp-ping-18.txt Pages : 29 Date : 2011-09-02 Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping&quo= t;. The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. This document updates RFC 4379. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-18.txt From ssaxena@cisco.com Fri Sep 2 13:55:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DE721F8D6A for ; Fri, 2 Sep 2011 13:55:38 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scsahnk4fQUU for ; Fri, 2 Sep 2011 13:55:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 645D521F8D66 for ; Fri, 2 Sep 2011 13:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssaxena@cisco.com; l=8282; q=dns/txt; s=iport; t=1314997034; x=1316206634; h=mime-version:subject:date:message-id:from:to:cc; bh=4wC2oe0u5KlY2NUN5yFlunUu0SOqgonhPy1Q26pTAZg=; b=izx5yFui4in4i/xz3zMKBts9PLf7XKtLWhApmH4QbkSH9VRIKl4xQcS3 f6Rn8z1GH8LMLiJits4VYW246S6xUuE6nEjREQbUXeFPsWGuuna/vlytm uD46TeKkcVrWARi2sU7+6egGi42t81PvV7NHAH9913952DD1wDagc6joL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAINCYU6tJV2a/2dsb2JhbABCgk2mHHiBSAEBAxIBCREDSRIBKgYYB1cBBAEaARmHVJlQAZ8VhgVgBIdpkFuMEw X-IronPort-AV: E=Sophos;i="4.68,321,1312156800"; d="scan'208,217";a="18989604" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 02 Sep 2011 20:57:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p82KvDrs015662; Fri, 2 Sep 2011 20:57:13 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 15:57:13 -0500 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_01CC69B2.E3C2186E" Date: Fri, 2 Sep 2011 15:57:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of draft-ietf-mpls-p2mp-lsp-ping Thread-Index: AcxpsuNQMtpBlRBXQxqiNN6H8+umSw== From: "Shaleen Saxena (ssaxena)" To: , X-OriginalArrivalTime: 02 Sep 2011 20:57:13.0510 (UTC) FILETIME=[E3DFEC60:01CC69B2] Cc: draft-ietf-mpls-p2mp-lsp-ping@tools.ietf.org Subject: [mpls] New version of draft-ietf-mpls-p2mp-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 20:55:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC69B2.E3C2186E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello MPLS WG, Chairs: =20 We have posted a new version of draft-ietf-mpls-p2mp-lsp-ping. It is available at: =20 http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-ping-18.txt =20 This version addresses the comments from IESG review of version 17 of this draft. =20 The details of the changes made are at the bottom of this mail. One major change is to make some statement more compliant with RFC 2119 language (i.e. SHOULD, MUST, etc.).=20 =20 Please review this version and let us know if you have any comments. =20 Regards, Shaleen=20 =20 =20 Details of changes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Various editing changes to clarify the language used. 2. Changes to RECOMMENDED, SHOULD and MUST to be more in line with RFC 2119. =20 3. Fixed figures in sections 3.1.1.1 and 3.1.1.2 to make P2MP-ID 32 bits long. 4. Added figures for Responder Identifier sub-TLVs in section 3. 5. In section 2.1 indented the text copied from RFC 4379. 6. Added section 7.3, requesting IANA for a new registry for the Global Flags field.=20 7. Changed various TBD to TBD1, TBD2, etc to clarify the usage. 8. Added details for the Address Type field in the Downstream Detailed Mapping TLV. =20 =20 =20 ------_=_NextPart_001_01CC69B2.E3C2186E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello MPLS = WG, Chairs:

 

We have posted a new version of = draft-ietf-mpls-p2mp-lsp-ping. It is available at:

 

http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-lsp-pin= g-18.txt

 

This = version addresses the comments from IESG review of version 17 of this = draft.

 

The details of the changes made are at the bottom = of this mail. One major change is to make some statement more compliant = with RFC 2119 language (i.e. SHOULD, MUST, etc.).

 

Please = review this version and let us know if you have any = comments.

 

Regards,

Shaleen

 

 

Details of changes:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

1.  = Various editing changes to clarify the language = used.

2.  = Changes to RECOMMENDED, SHOULD and MUST to be = more in line with RFC 2119.  

3.  = Fixed figures in sections 3.1.1.1 and 3.1.1.2 to = make P2MP-ID 32 bits long.

4.  = Added figures for Responder Identifier sub-TLVs = in section 3.

5.  In = section 2.1 indented the text copied from RFC 4379.

6.  = Added section 7.3, requesting IANA for a new = registry for the Global Flags field.

7.  = Changed various TBD to TBD1, TBD2, etc to = clarify the usage.

8.  = Added details for the Address Type field in the = Downstream Detailed Mapping TLV.

 

 

 

------_=_NextPart_001_01CC69B2.E3C2186E-- From eric.gray@ericsson.com Sun Sep 4 20:34:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA021F85B8; Sun, 4 Sep 2011 20:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpImQfp3nAg7; Sun, 4 Sep 2011 20:34:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4404621F85B1; Sun, 4 Sep 2011 20:34:41 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p853YH3F000971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Sep 2011 22:36:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 4 Sep 2011 23:34:50 -0400 From: Eric Gray To: Yoshinori Koike , "ietf@ietf.org" Date: Sun, 4 Sep 2011 23:34:50 -0400 Thread-Topic: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Thread-Index: AcxjRMzj+g45E17eTyiFSmM6LOGPdAIJ+7yQ Message-ID: References: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> <4E5679AE.8010209@lab.ntt.co.jp> In-Reply-To: <4E5679AE.8010209@lab.ntt.co.jp> 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 Cc: "mpls@ietf.org" , 'IETF-Announce' Subject: Re: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 03:34:42 -0000 Yoshinori, The DSMAP/DDMAP was explicitly added to make it possible to direct the implementation to respond to the echo request as if it were directed to a specific interface (either the egress or ingress interface). This interface-specific echo request is what I believe=20 folks are referring to as "per-interface." This - in effect - is the primary use for the object in this draft, so any explicit statement to the effect that this=20 is the case would be redundant. While the object includes fields for both an ingress and=20 egress interface, when being used to direct the implementation to respond as if the echo request were directed to a specific interface, only one of these fields would contain valid info. It is possible that both interface numbers are valid. In this case, the object cannot be used for what you are calling a "per-interface" echo request. However, this case may be useful if - for example - the intention is to verify that the LSP is using this particular interface mapping at this node (i.e. -=20 the request is attempting to ascertain if this is the correct=20 mapping for the LSP). All of this is fairly intuitive to anyone who has read the draft and is reasonably familiar with the technology and protocols involved. This draft is a protocol specification, not a tutorial. As for what may be said in any other draft that is still in the process of being written, that is an issue that is not in scope for this draft. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Yos= hinori Koike Sent: Thursday, August 25, 2011 12:35 PM To: ietf@ietf.org Cc: mpls@ietf.org; 'IETF-Announce' Subject: Re: [mpls] Last Call: (MP= LSOn-demand Connectivity Verification and Route Tracing) toProposed Standar= d Hi, I would like to propose that this draft explicitly stipulate whether or=20 not it covers per-interface model. I think it is essential to avoid=20 confusion and clarify the appropriate I-D to discuss OAM solutions for=20 the per-interface model. "Per-interface model" is one of the two OAM maintenance models in=20 MPLS-TP networks which is specified in section 3 of=20 draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the=20 per-interface MIP draft (=20 http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the=20 on-demand-cv-06 covers the OAM solution for per-interface model, the=20 discussion for on-demand CV and route tracing must be removed from the=20 mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the=20 solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr.=20 Zhenlong Cui in the draft, whose email is attached at the bottom. It is=20 important to make clear for what purpose the "IF_Num" is used. It also=20 seems important to clarify the responder's behavior, because the=20 ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: > Hi, > > I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd = like to make sure it is not lost. > > 2.1. New address type for Downstream Mapping TLV > The new address type indicates that no address is present in the > DSMAP or DDMAP TLV. However, IF_Num information (see definition of > "IF_NUM" in [I-D.ietf-mpls-tp-identifiers]) for both ingress and > egress interfaces, as well as multipath information is included in > the format and MAY be present. > > > I believe the "IF_Num" can be used for per-interface MIP model. > But I'm not sure why we need use both "ingress IF_Num" and "egress IF_Num= " in a DSMAP TLV. > I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-ident= ifiers]. > > e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using= "IF_Num", but there is no Ingress_IF::Egress_IF. > - "IF_ID" > IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. > - "MIP ID" > For a MIP which is associated with particular interface, we simply > use the IF_ID (see Section 4) of the interfaces which are cross- > connected. > > If have any special means in the "IF_Num", I think MUST mention it clearl= y. > Also I feeling that this draft have to clarify the responder's behavior f= or each IF information of the "IF_Num". > > > Best regards, > zhenlong > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = The IESG >> Sent: Thursday, August 11, 2011 10:46 PM >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: (MPL= SOn-demand Connectivity Verification and Route >> Tracing) toProposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label Switching W= G >> (mpls) to consider the following document: >> - 'MPLS On-demand Connectivity Verification and Route Tracing' >> as a Proposed Standard >> >> 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 2011-08-25. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> Label Switched Path Ping (LSP-Ping) is an existing and widely >> deployed Operations, Administration and Maintenance (OAM) mechanism >> for Multi-Protocol Label Switching (MPLS) Label Switched Paths >> (LSPs). This document describes extensions to LSP-Ping so that LSP- >> Ping can be used for On-demand Connectivity Verification of MPLS >> Transport Profile (MPLS-TP) LSPs and Pseudowires. This document als= o >> clarifies procedures to be used for processing the related OAM >> packets. Further, it describes procedures for using LSP-Ping to >> perform Connectivity Verification and Route Tracing functions in >> MPLS-TP networks. Finally this document updates RFC 4379 by adding = a >> new address type and requesting an IANA registry. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From yaacov.weingarten@nsn.com Sun Sep 4 22:40:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBFD21F883A for ; Sun, 4 Sep 2011 22:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1drXSiLQq+PO for ; Sun, 4 Sep 2011 22:40:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7BC21F8802 for ; Sun, 4 Sep 2011 22:40:55 -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 p855ga3Q006595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2011 07:42:37 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p855gaBb022315; Mon, 5 Sep 2011 07:42:36 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 07:42:36 +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_01CC6B8E.9DDD0308" Date: Mon, 5 Sep 2011 07:42:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of Ring Protection Applicability draft Thread-Index: AcxrjpkJaqxXsdmpT8W4NW0Q0MjuSA== From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 05 Sep 2011 05:42:36.0625 (UTC) FILETIME=[9DF10C10:01CC6B8E] Cc: mpls-chairs@tools.ietf.org Subject: [mpls] New version of Ring Protection Applicability draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 05:40:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6B8E.9DDD0308 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We (the authors) have just posted a new version of draft-weingarten-mpls-tp-ring-protection. To remind you, this is an Applicability statement that points out how it is possible to provide MPLS-TP protection for ring topologies based on MPLS-TP Linear Protection. This has been presented to the WG several times in the past and we would like to ask for adoption as a WG draft. The main changes to this version are - change of title to reflect the true nature of the document (as an Applicability statement rather than a new mechanism), and removal of consideration for Interconnected rings - which is left for a future document. Best regards, Yaacov Weingarten Nokia Siemens Networks Industry Environment, PTE ph#: +972-9-775 1827 mob#: +972-54-220 0977 ------_=_NextPart_001_01CC6B8E.9DDD0308 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New version of Ring Protection Applicability draft

Hi all,

We (the authors) have just = posted a new version = of draft-weingarten-mpls-tp-ring-protection.  To remind = you, this is an Applicability statement that points out how it is = possible to provide MPLS-TP protection for ring topologies based = on MPLS-TP Linear Protection.  This has been = presented to the WG several times in the past and we would = like to ask for adoption as a WG draft.

The main = changes to this version are = – change of title to reflect = the true nature of the document (as an Applicability statement = rather than a new mechanism), and removal of consideration for = Interconnected rings – which is left for a future document.

Best = regards,

Yaacov = Weingarten

Nokia Siemens Networks

Industry Environment, PTE

ph#:  +972-9-775 1827

mob#: +972-54-220 0977

------_=_NextPart_001_01CC6B8E.9DDD0308-- From kam.lam@alcatel-lucent.com Fri Sep 2 09:00:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CF721F8BB9 for ; Fri, 2 Sep 2011 09:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2pbFcY4oNbj for ; Fri, 2 Sep 2011 09:00:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BF55521F8BB2 for ; Fri, 2 Sep 2011 09:00:29 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p82G24J4006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Sep 2011 11:02:04 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p82G23eK004503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Sep 2011 11:02:04 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 2 Sep 2011 11:02:04 -0500 From: "Lam, Hing-Kam (Kam)" To: Loa Andersson , "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Date: Fri, 2 Sep 2011 11:02:02 -0500 Thread-Topic: [mpls] Verification call on draft-ietf-mpls-tp-mib-management-overview Thread-Index: AcxlYyJ53YQEsqbURYqz2ixCEQ70KgEJSMFQ Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD57FB42DB1@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <4E5A0753.2010801@pi.nu> In-Reply-To: <4E5A0753.2010801@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_7F76AEFB05C38145BABA0D545E3CFFD57FB42DB1USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 X-Mailman-Approved-At: Mon, 05 Sep 2011 23:33:05 -0700 Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-mib-management-overview X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 16:00:32 -0000 --_002_7F76AEFB05C38145BABA0D545E3CFFD57FB42DB1USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa, We have verified and found that our LC comments raised in our previous liai= son (Ref 055.02) have been adequately addressed. Attached for your early i= nformation is an informal LS that confirms our support on the draft. The fo= rmal LS will be transmitted as soon as possible by the SG15 TSB. Regards, Kam Q14/15 Rapporteur=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Sunday, August 28, 2011 5:16 AM > To: mpls@ietf.org; MPLS-TP ad hoc team; draft-ietf-mpls-tp-mib- > management-overview@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: [mpls] Verification call on draft-ietf-mpls-tp-mib-management- > overview >=20 > All, >=20 > This is to start a one week verification call on > draft-ietf-mpls-tp-mib-management-overview > The authors has published version -05 of the draft. This document > is updated after working group last call. >=20 > A complete diff between version -04 and -05 is found at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mib-management- > overview-05.txt >=20 > The comment resolution will be found at: >=20 > http://www.pi.nu/~loa/man-overview-comments-resollution..txt >=20 > This verification call ends September 4, 2011. >=20 > Loa > for the MPLS wg chairs >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_002_7F76AEFB05C38145BABA0D545E3CFFD57FB42DB1USNAVSXCHMBSA2n_ Content-Type: application/msword; name="oLS_MPLS-WG_055-03.doc" Content-Description: oLS_MPLS-WG_055-03.doc Content-Disposition: attachment; filename="oLS_MPLS-WG_055-03.doc"; size=42496; creation-date="Fri, 02 Sep 2011 15:32:40 GMT"; modification-date="Fri, 02 Sep 2011 16:02:02 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASwAAAAAAAAAA EAAATQAAAAEAAAD+////AAAAAEwAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAA4AJBAAA+BK/AAAAAAAAEAAAAAAACAAAJAsAAA4AYmpiarRWtFYAAAAAAAAAAAAAAAAAAAAA AAAJBBYALh4AANY8AQDWPAEAJAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAN4HAAAAAAAA3gcAACEV AAAAAAAAIRUAAAAAAAAhFQAAAAAAACEVAAAAAAAAIRUAABQAAAAAAAAAAAAAAP////8AAAAANRUA AAAAAAA1FQAAAAAAADUVAAAAAAAANRUAABQAAABJFQAAPAAAADUVAAAAAAAAnTUAAPgBAACFFQAA FgAAAJsVAAAAAAAAmxUAAAAAAACbFQAAAAAAAJsVAAAAAAAAlhYAAAAAAACWFgAAAAAAAJYWAAAA AAAAHDUAAAIAAAAeNQAAAAAAAB41AAAAAAAAHjUAAAAAAAAeNQAAAAAAAB41AAAAAAAAHjUAACQA AACVNwAAogIAADc6AABiAAAAQjUAABUAAAAAAAAAAAAAAAAAAAAAAAAAIRUAAAAAAACWFgAAAAAA AAAAAAAAAAAAAAAAAAAAAACWFgAAAAAAAJYWAAAAAAAAlhYAAAAAAACWFgAAAAAAAEI1AAAAAAAA AAAAAAAAAAAhFQAAAAAAACEVAAAAAAAAmxUAAAAAAAAAAAAAAAAAAJsVAAD7AAAAVzUAABYAAADA FwAAAAAAAMAXAAAAAAAAwBcAAAAAAACWFgAALgAAACEVAAAAAAAAmxUAAAAAAAAhFQAAAAAAAJsV AAAAAAAAHDUAAAAAAAAAAAAAAAAAAMAXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAlhYAAAAAAAAcNQAAAAAAAAAAAAAAAAAAwBcAAAAAAADAFwAA OgAAAHwdAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB4AAAAAAACbFQAAAAAAAP////8AAAAAUFRrjYVp zAEAAAAAAAAAADUVAAAAAAAAxBYAADoAAACoHQAACgAAAAAAAAAAAAAACDUAABQAAABtNQAAMAAA AJ01AAAAAAAAsh0AAFIAAACZOgAAAAAAAP4WAABAAAAAmToAABQAAAAEHgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJk6AAAAAAAAAAAAAAAAAAAhFQAAAAAAAAQeAAAEFwAAlhYAAAAAAACWFgAAAAAAAMAX AAAAAAAAlhYAAAAAAACWFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlhYA AAAAAACWFgAAAAAAAJYWAAAAAAAAQjUAAAAAAABCNQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAPhcAAIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJYWAAAA AAAAlhYAAAAAAACWFgAAAAAAAJ01AAAAAAAAlhYAAAAAAACWFgAAAAAAAJYWAAAAAAAAlhYAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAJk6AAAAAAAAlhYAAAAAAACW FgAAAAAAAJYWAAAAAAAAlhYAAAAAAACWFgAAAAAAAJYWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACWFgAAAAAAAJYWAAAAAAAAlhYA AAAAAADeBwAACQwAAOcTAAA6AQAABQASAQAACQQEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1RdWVz dGlvbihzKToHMTQHTWVldGluZywgZGF0ZToHQ29ycmVzcG9uZGVuY2UHB1N0dWR5IEdyb3VwOgcx NQdXb3JraW5nIFBhcnR5OgczIAcHU291cmNlOgdTRyAxNQcHVGl0bGU6IAdvTFM6IFJlc3BvbnNl IHRvIHZlcmlmaWNhdGlvbiBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1taWItbWFuYWdlbWVu dC1vdmVydmlldy0wNS50eHQgIA1bUmVmIDA1NS4wM10HB0xJQUlTT04gU1RBVEVNRU5UBwdGb3Ig YWN0aW9uIHRvOgcHB0ZvciBjb21tZW50IHRvOgcHB0ZvciBpbmZvcm1hdGlvbiB0bzoHSUVURiBN UExTIFdHBwdBcHByb3ZhbDoHU0cgMTUHB0RlYWRsaW5lOgdOb25lBwdDb250YWN0OgdIaW5nLUth bSBMYW0NQWxjYXRlbC1MdWNlbnQNVVNBB1RlbDogKzEgOTA4IDU4MiAwNjcyDUZheDogKzEgOTA4 IDU4MiAxMTI0DUVtYWlsOiATIEhZUEVSTElOSyAibWFpbHRvOkthbS5MYW1AYWxjYXRlbC1sdWNl bnQuY29tIiABFEthbS5MYW1AYWxjYXRlbC1sdWNlbnQuY29tFQcHBwdXZSBub3RpY2UgdGhhdCB0 aGVyZSBpcyBhIHZlcmlmaWNhdGlvbiBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy10cC1taWItbWFu YWdlbWVudC1vdmVydmlldy0wNS50eHQuIFdlIGhhdmUgdmVyaWZpZWQgYW5kIGZvdW5kIHRoYXQg b3VyIExDIGNvbW1lbnRzIHJhaXNlZCBpbiBvdXIgcHJldmlvdXMgbGlhaXNvbiAoUmVmIDA1NS4w MikgaGF2ZSBiZWVuIGFkZXF1YXRlbHkgYWRkcmVzc2VkLiAgV2UgdGhlcmVmb3JlIHN1cHBvcnQg dGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgaW50ZXJuZXQgZHJhZnQuDV9fX19fX19fX19fX19fX18N DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAQgA ACAIAAAuCAAALwgAAEAIAABPCAAAWwgAAGEIAABqCAAAawgAAG8IAACQCAAAnQgAAL0IAADBCAAA wwgAAMQIAADMCAAAzQgAAM4IAADPCAAA0AgAANEIAADSCAAA5QgAAPQIAAD1CAAABgkAAAcJAAAc CQAAKAkAACkJAABFCQAASQkAAEoJAABUCQAAdAkAAPHn4NbnzufD57uwqJ2onZKKgnq7qLBv587n w+fD56jD56jD52QAAAAAAAAAAAAAABQVaIleFAAWaOls7ABtSAcEc0gHBAAUFWiCLXwAFmjpbOwA bUgJBHNICQQADhZoAGkmAG1ICQRzSAkEAA4WaFEy1ABtSAkEc0gJBAAOFmjcCxkAbUgJBHNICQQA FBVoAGkmABZoAGkmAG1ICQRzSAkEABQVaFEy1AAWaFEy1ABtSAkEc0gJBAAOFmjZKAEAbUgJBHNI CQQAFBVogi18ABZogi18AG1ICQRzSAkEAA4WaIItfABtSAkEc0gJBAAUFWhMIS0AFmjpbOwAbUgJ BHNICQQADxVoTCEtABZo6WzsADUIgRIVaIItfAAWaOls7AA1CIFcCIEADBZoAGkmADUIgVwIgQAS FWhMIS0AFmjpbOwANQiBXAiBABsVaNlpcQAWaOls7ABQSgMAbkgRBG8oAXRIEQQAJQAIAAABCAAA DggAABEIAAAgCAAALwgAADAIAAA9CAAAQAgAAE8IAABSCAAA+gAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAB7AAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAB1AABrZAAAAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWXAAEx/8YBg8QQheK JgAGUQYMAQAAAAAAAAAAAAAAAAAAAAb3CQwBAAAAAAAAAAAAAAAAAAAABjMHDAEAAAAAAAAAAAAA AAAAAAAGSA8MAQAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA /xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA /zTWBgABCgM5AGH2AwAAZjQBCQAAFiQBSWYBAAAAZ2TpbOwAAAQAAGdk6WzsAAAKUggAAFMIAABb CAAAYQgAAGIIAACJAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAAAnAAAAAAAA AAAAAAAAAAAAAAAAAE8AAGtkSgEAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/xgGiiYA BlEGAAAAAAAAAAAAAAAAAAAAAAAGciAAAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYI AAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0 AQkTABYkAUlmAQAAAGdk6WzsAAkAABYkAUlmAQAAAGdk6WzsAAB1AABrZKwAAAAWJAEXJAFJZgEA AAACljkAAzQBB5RlAQjWXAAEx/8YBk8IDxCKJgAGUQYAAAAAAAAAAAAAAAAAAAAAAAY3AgAAAAAA AAAAAAAAAAAAAAAABsAHAAAAAAAAAAAAAAAAAAAAAAAGexYAAAAAAAAAAAAAAAAAAAAAFPYDwyYX 9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA /wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAARiCAAAaggAAMQI AADRCAAA0ggAAOQIAADlCAAA9AgAAPUIAAD2AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAA AAAAAAAAAACdAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAFQAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAASwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJFgAWJAFJZgEAAABnZOls7AAAPAAAa2Q8AgAAFiQB FyQBSWYBAAAAApY5AAM0AQeUZQEI1hoAAcf/iiYABsMmDAEAAAAAAAAAAAAAAAAAABT2A8MmF/YD AAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQoDOQBh9gMAAGY0AQwAAAMk ARYkAUlmAQAAAGEkAWdk6WzsAABPAABrZLwBAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWMAAC x/8YBoomAAZRBgAAAAAAAAAADAEAAAAAAAAABnIgAAAAAAAAAAAMAQAAAAAAABT2A8MmF/YDAAAY 9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKAzkA YfYDAABmNAEJFAAWJAFJZgEAAABnZOls7AAJAAAWJAFJZgEAAABnZOls7AAACPUIAAD2CAAABgkA AAcJAAAICQAAHAkAACkJAACvAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAJ0AAAAAAAAAAAAAAABN AAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAJFQAWJAFJZgEAAABnZOls7AAATwAAa2QYAwAAFiQBFyQBSWYBAAAAApY5AAM0 AQeUZQEI1jAAAsf/cAiKJgAGqQgAAAAAAAAAAAAAAAAAAAAAAAYaHgAAAAAAAAAAAAAAAAAAAAAU 9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA /zTWBgABCgM5AGH2AwAAZjQBCRcAFiQBSWYBAAAAZ2TpbOwACQAAFiQBSWYBAAAAZ2TpbOwAAE8A AGtkpgIAABYkARckAUlmAQAAAAKWOQADNAEHlGUBCNYwAALH/3AIiiYABqkIAAAAAAAAAAAAAAAA AAAAAAAGGh4AAAAAAAAAAAAAAAAAAAAAFPYDwyYX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/ AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDOQBh9gMAAGY0AQAGKQkAACoJAAA0CQAA OgkAADsJAABFCQAASgkAAK8AAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAFYA AAAAAAAAAAAAAACmAAAAAAAAAAAAAAAATQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkSABYkAUlmAQAAAGdkUTLUAABPAABrZPwDAAAW JAEXJAFJZgEAAAACljkAAzQBB5RlAQjWMAACx/9wCIomAAapCAAAAAAAAAAAAAAAAAAAAAAABhoe AAAAAAAAAAAAAAAAAAAAABT2A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggA AAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEJAAAWJAFJZgEAAABnZOls7AAATwAA a2SKAwAAFiQBFyQBSWYBAAAAApY5AAM0AQeUZQEI1jAAAsf/cAiKJgAGqQgAAAAAAAAAAAAAAAAA AAAAAAYaHgAAAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAZKCQAASwkAAFQJAABh CQAAcAkAAHQJAACJCQAAngkAAPMJAACvAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAKYAAAAAAAAA AAAAAACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAACbAAAAAAAAAAAAAAAA mwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACwAAE6QAABYkAUlmAQAAAGdk6WzsAAkAABYkAUlmAQAAAGdk6WzsAABPAABr ZG4EAAAWJAEXJAFJZgEAAAACljkAAzQBB5RlAQjWMAACx/9wCIomAAapCAAAAAAAAAAADAEAAAAA AAAABhoeAAAAAAAAAAAMAQAAAAAAABT2A8MmF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAA AP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/NNYGAAEKAzkAYfYDAABmNAEACHQJAAClCQAApgkAALkJ AADTCQAA1QkAANYJAADXCQAA8QkAAPIJAADzCQAA9AkAAPYJAAAlCgAAVgoAAGkKAABzCgAA4AoA AAELAAASCwAAIwsAACQLAAD58e357eLx2fH5z8XBusG2wbLBq6cAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmjiOykAAAwVaB07dAAWaOls7AAA BhZoOxiZAAAGFmhKWRoAAAwVaNkoAQAWaNkoAQAABhZo2SgBAAATDCoHFWiyMuMAFmjpbOwAQ0oS ABIVaEwhLQAWaOls7AA1CIFcCIEAEBVoSxbUABZo6WzsADBKEQAAFQIIgQNq7gQAAAYIARZo6Wzs AFUIAQYWaOls7AAADwNqAAAAABZo6WzsAFUIAQwVaEwhLQAWaOls7AAV8wkAAPQJAAD1CQAA9gkA ABILAAAjCwAAJAsAAJwAAAAAAAAAAAAAAACRAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAAAE8AAAAA AAAAAAAAAABDAAAAAAAAAAAAAAAAQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAACxAABSQABiQAE6R4ABSkAABnZOls7AAABAAAZ2TpbOwAADwAAGtkcwYAABYkARckAUlm AQAAAAKWOQADNAEHlMwACNYaAAHH/4omAAbDJgwBAAAAAAAAAAAAAAAAAAAU9gPDJhf2AwAAGPYD AAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEKAzkAYfYDAABmNAELAAATpAAAFiQB SWYBAAAAZ2TpbOwAAGIAAGtk3QUAABYkARckAUlmAQAAAAKWOQADNAEHlMwACNZGAAPH/3AIQheK JgAGqQgMAQAAAAAAAAAAAAAAAAAAAAbSDgwBAAAAAAAAAAAAAAAAAAAABkgPDAEAAAAAAAAAAAAA AAAAABT2A8MmF/YDAAAY9gMAABrWDAAAAP8AAAD/AAAA/xvWDAAAAP8AAAD/AAAA/xzWDAAAAP8A AAD/AAAA/x3WDAAAAP8AAAD/AAAA/zTWBgABCgM5AGH2AwAAZjQBAAYsADGQaAEfsNAvILDgPSGw CAcisAgHI5CgBSSQoAUlsAAAF7DQAhiw0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKoAFiQBFyQBSWYBAAAAAZYA ACF2AARoATXWBQABA1EGNdYFAQID9wk11gUCAwMzBzXWBQMEA0gPI3YAAVEGI3YBAvcJI3YCAzMH I3YDBEgPOlYLAAKWOQADNAEHlGUBFPYDwyYY9gMAADXWBQABA1EGNdYFAQID9wk11gUCAwMzBzXW BQMEA0gPL9YLAAQBAAAA/wwBAAA01gYAAQUAAAA01gYAAQoDOQBmNAGcABYkARckAUlmAQAAAAGW AAAhdgAEaAE11gUAAQNRBjXWBQECAzcCNdYFAgMDwAc11gUDBAN7FiN2AAFRBiN2AQI3AiN2AgPA ByN2AwR7FjpWCwACljkAAzQBB5RlART2A8MmGPYDAAA11gUAAQNRBjXWBQECAzcCNdYFAgMDwAc1 1gUDBAN7FjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQAB A1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDUQY1 1gUBAgNyIDTWBgABBQAAADTWBgABCgM5AGY0AX4AFiQBFyQBSWYBAAAAAZYAACF2AAJoATXWBQAB A1EGNdYFAQIDciAjdgABUQYjdgECciA6VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDUQY1 1gUBAgNyIC/WCwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBaAAWJAEXJAFJZgEAAAAB lgAAIXYAAWgBNdYFAAEDwyYjdgABwyY6VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYFAAEDwyYv 1gsAAQEAAAD/DAEAADTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA6kINdYFAQIDGh4jdgABqQgjdgECGh46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDqQg11gUBAgMaHjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA6kINdYFAQIDGh4jdgABqQgjdgECGh46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDqQg11gUBAgMaHjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA6kINdYFAQIDGh4jdgABqQgjdgECGh46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDqQg11gUBAgMaHjTWBgABBQAAADTWBgABCgM5AGY0AXAAFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA6kINdYFAQIDGh4jdgABqQgjdgECGh46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDqQg11gUBAgMaHjTWBgABBQAAADTWBgABCgM5AGY0AX4AFiQBFyQBSWYBAAAAAZYAACF2AAJo ATXWBQABA6kINdYFAQIDGh4jdgABqQgjdgECGh46VgsAApY5AAM0AQeUZQEU9gPDJhj2AwAANdYF AAEDqQg11gUBAgMaHi/WCwACBAAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQB7wAAAEQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAGwAAAEsAYQBtAC4ATABhAG0AQABhAGwAYwBhAHQA ZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQtEAAAAbQBhAGkAbAB0 AG8AOgBLAGEAbQAuAEwAYQBtAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A AACUABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQOpCDXWBQECA9IONdYFAgMDSA8jdgABqQgj dgEC0g4jdgIDSA86VgsAApY5AAM0AQeUzAAU9gPDJhj2AwAANdYFAAEDqQg11gUBAgPSDjXWBQID A0gPL9YLAAMBAAAA/wwBAAA01gYAAQUAAAA01gYAAQoDOQBmNAFoABYkARckAUlmAQAAAAGWAAAh dgABaAE11gUAAQPDJiN2AAHDJjpWCwACljkAAzQBB5TMABT2A8MmGPYDAAA11gUAAQPDJi/WCwAB AQAAAP8MAQAANNYGAAEFAAAANNYGAAEKAzkAZjQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiBBgAEgABAAsBDwAHAAAABAAAAAAABAAI AAAACAAAAA4AAAAOAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyBgAA GAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQ BAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAwBAAAQAQAAFAE AABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA AGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAA YAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABg BAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAE AABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQA AHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAYAAAAUEoEAF9IAQRtSAkE bkgECHNICQR0SAQIAAAAAGYAAGDx/wIAZgAMEAAA6WzsAAAABgBOAG8AcgBtAGEAbAAAACcAAAAN xg4ABBoDpwQ0BsEHwMDAwBOkeAA1JAA3JAA4JAA5RAIASCQAABgAQ0oYAFBKAABfSAEEbUgJBHNI CQR0SAkEAAAAAAAAAAAAAAAAAAAAAAAARABBYPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBs AHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz/7MAUgAMBQAAAAAAAAAA DABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMA AAIACwAAACgAayD0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAMAAAAAABUAP4P AQACAFQADAAAAOls7AAAABAAQQBuAG4AZQB4AF8ATgBvACAAJgAgAHQAaQB0AGwAZQAAABIADwAD JAEFJAEGJAETpOABYSQBBwA1CIFDShwAADwA/k8BAAIAPAAMAAAA6WzsAAAABgBGAGkAZwB1AHIA ZQAAABYAEAADJAEFJAEGJAETpPAAFKR4AGEkAQAANgBVQKIAEQE2AAwAAADpbOwAAAAJAEgAeQBw AGUAcgBsAGkAbgBrAAAADAA+KgFCKgJwaAAA/wA+AP5PAQAiAT4ADAAAAOls7AAAAAoATABTAEQA ZQBhAGQAbABpAG4AZQAAAAIAEgAOADUIgVwIgW1ICQhzSAkIOgD+TwEAMgE6AAwAAADpbOwAAAAI AEwAUwBTAG8AdQByAGMAZQAAAAIAEwAOADUIgVwIgW1ICQhzSAkIOAD+TwEAQgE4AAwAAADpbOwA AAAHAEwAUwBUAGkAdABsAGUAAAACABQADgA1CIFcCIFtSAkIc0gJCDwA/k8BAFIBPAAMAAAA6Wzs AAAACQBMAFMARgBvAHIASQBuAGYAbwAAAAIAFQAOADUIgVwIgW1ICQhzSAkIQAD+TwEAYgFAAAwA AADpbOwAAAALAEwAUwBGAG8AcgBBAGMAdABpAG8AbgAAAAIAFgAOADUIgVwIgW1ICQhzSAkINAD+ T2EBcgE0AAwAAADpbOwAAAAMAEwAUwBGAG8AcgBDAG8AbQBtAGUAbgB0AAAAAgAXAAAAUEsDBBQA BgAIAAAAIQCCirwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C2 2HK6KKXYzqJJd30s0g8Y5LEtao+ENAnJ33fsuFC6CC10IxBizpl7Va6P46AOGJPzVOlVXmiFZH3j qKv0++4pu9cqMVADgyes9AmTXtfXV+XuFDApmaZU6Z45PBiTbI8jpNwHJHlpfRyB5Ro7E8B+QIfm tijujPXESJzxxNB1+SoLRNegeoPILzCKx7Cg8Pv5DCSAmAtYq8czYVqi0hDC4CywRDAHan7oM9+2 zmLj7X4UaT6DF9jNBDO/XGD1P+ov5wZb2A+stkfp4lx/xCH9LdtSay6Tc/7Uu5AuGC6Xt7Rh5r+t PwEAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH 74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JD P8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIk f6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe 0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3Ro ZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U 1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh 7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAA FgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboce aYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8e H6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i 13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy 4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqw trSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGe drfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63V hos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbY hyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLO qm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2B R2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMK eH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/Fu RBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sH dTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9 S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6 +w4ljrtPrwa3aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7 RPldhDtZdLtcBPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPG BmrKyA1pmmQJ+0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzM cCVtjYcmXdljYVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbXQp2ZW92I Zkqdw61QGXw4rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTH irkJgNip8JE+5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjH adsbw5kWHuMUvC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs 0Zys/MtNMOtFKWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAIjdhE7GNwvw5V 0CegEq4mTEXQL3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFulbIb5c6vikn5 C1KlHMb/M1X0fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9t zlkaJq3hwKf2aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaa ZGXA4E7Gn/ueZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XI swKYlbaCVpb2rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0M wgai+pJtPJAukHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH 1nZsoanBsydTFIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP// AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1h bmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+ mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidK k5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZ hQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQCCirwT+gAAABwCAAATAAAA AAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAA NgEAAAsAAAAAAAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAA igAAABwAAAAAAAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAU AAYACAAAACEAlrWt4pYGAABQGwAAFgAAAAAAAAAAAAAAAADRAgAAdGhlbWUvdGhlbWUvdGhlbWUx LnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAJsJAAB0aGVtZS90 aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAlgoAAAAAPD94 bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6 Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5n bWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNj ZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50 ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9Imhs aW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4AAAAAJAMAAB4AAB4AAAAA/////wAIAAB0CQAAJAsA AAYAAAANAAAAAAgAAFIIAABiCAAA9QgAACkJAABKCQAA8wkAACQLAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAAOAAAApQEAANYBAADxAQAAJAMAABNYFP8VhA8AAPBYAAAAAAAG8BgAAAACCAAAAgAA AAEAAAABAAAAAQAAAAIAAABDAAvwGAAAAIEANyIBAIIAuiIAAIMANyIBAIQAuiIAAEAAHvEQAAAA //8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAAB BAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA AAAAAGoAAABtAAAAVAEAAHQBAAD2AQAA+AEAACYDAAAHABwABwAFAAcABAAHAAAAAABUAQAAYAEA AGEBAABvAQAAcAEAAHMBAAD2AQAAWAIAACYDAAAHAAUABwAFAAcABQAHAAQABwAAAAAAAQAAAGoA AADEAAAA9AAAAPYAAABUAQAAdAEAAPYBAABXAgAAJgMAAAcABQAHAAUABwAFAAcABQAEAAcAAAAA AA4AAAAOAAAAbwAAAMEAAADKAAAAzAAAAM4AAADPAAAA9AAAAPQAAAAcAQAAHAEAACgBAAAoAQAA RQEAAEkBAABLAQAASwEAAPYBAAASAwAAJgMAAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAH AAQABwAEAAcABAAHAAIANDObG4z4eAL/D/8P/w//D/8P/w//D/8P/w8QAJgKsTmUhwAh/w//D/8P /w//D/8P/w//D/8PEAABAAAAFxAAAAAAAAAAAAAAGAMAAAAAAAAVGACVD4RoARGEmP4VxgUAAWgB Bl6EaAFghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQAt8AEAAAAXkAAAAAAAAAAAAAAYAwAAAAAA ABkYAAAPhIgCEYSY/hXGBQABiAIGXoSIAmCEmP5PSgUAUUoFAF5KBQBvKACHaAAAAACISAAAAQBv AAEAAAAXkAAAAAAAAAAAAAAYAwAAAAAAABUYAAAPhFgFEYSY/hXGBQABWAUGXoRYBWCEmP5PSgYA UUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAABgDAAAAAAAAFRgAAA+EKAgRhJj+ FcYFAAEoCAZehCgIYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAA GAMAAAAAAAAZGAAAD4T4ChGEmP4VxgUAAfgKBl6E+ApghJj+T0oFAFFKBQBeSgUAbygAh2gAAAAA iEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAGAMAAAAAAAAVGAAAD4TIDRGEmP4VxgUAAcgNBl6EyA1g hJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAAAYAwAAAAAAABUYAAAP hJgQEYSY/hXGBQABmBAGXoSYEGCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAA AAAAAAAAABgDAAAAAAAAGRgAAA+EaBMRhJj+FcYFAAFoEwZehGgTYISY/k9KBQBRSgUAXkoFAG8o AIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAABgDAAAAAAAAFRgAAA+EOBYRhJj+FcYFAAE4 FgZehDgWYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAA AAAVGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQAt8AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoF AF5KBQBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhHAIEYSY /hXGBQABcAgGXoRwCGCEmP5PSgYAUUoGAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAFRgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgA AAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+ T0oFAFFKBQBeSgUAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAA D4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oGAFFKBgBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdo AAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/k9KBQBRSgUAXkoFAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBgBRSgYAbygAh2gAAAAAiEgAAAEAp/AC AAAANDObGwAAAAAAAAAAAAAAAJgKsTkAAAAAAAAAAAAAAAD/////////////AgAAAAAAAAD//wIA AAASAJDmXHUDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIANM3ExgMACQQFAAkEAQAJ BAMACQQFAAkEAQAJBAMACQQFAAkEuwUAAAQAAAAIAAAA5QAAAAAAAAC6BQAAWiAAADJVAACZWQAA 2SgBAHZoAQDwagEAmBUCAHRhAgDDbgIAqHQCAJZ1AgAqJAMA4D0DABZIAwD1bAMAVRoEAMkeBABm JwQAQT8EAL9IBADlYQQA3WMEAEtnBAAeCAUAVAwFADF1BQAUAAYAJEcGAOZbBgCQXwYAvQQHALII BwB5GQcAFSYHAFwxBwBLYwcA/mgHAC5wBwCIAAgAQREIAE8aCAArHggAXB4IAFQmCACudAgAORcJ AIccCQAIIAkAsCgJAIhPCQA3UAkAtjQKAABUCgB6WQoAE20KANUaCwDwMgsAJjgLAHM+CwAWRQsA 1HILABl+CwCmDwwADBYMADUdDAApQgwAugINAJ4QDQBLFg0A1x0NAOAjDQCSOg0AZ2wNAKcyDgC/ Qg4AdFcOABdgDgAKZQ4AhHYOAGx9DgBZGg8AD0UPAKVFDwBdChAA1QwQAJgPEACNXBAALHAQADgA EQDOAREA7wcRAEgdEQBfYBEAcGQRACdsEQB1BBIA9BASAGQhEgCaVxIArmkSANoOEwCZGhMA3TMT AGJBEwBnRRMATFMTAKNWEwDmaBMApWsTAK8IFADRERQAOBoUAKk+FABCXhQAiV4UALheFAAtYBQA iGkUABZwFAAOcRQARR0VABYpFQBMLhUAY2sVAKdsFQBCeBUAEQwWAHsMFgBGGhYAkDIWAH88FgDm VxYAKngWAN15FgDufhYAcgYXACoZFwBZbRcAt3QXAJB4FwCEfBcAKikYAIdjGACGeBgA3AsZAOss GQAIXxkAIUQaAEpZGgDFfRoAfRgbAB8oGwD5LRsAazcbAHZNGwBmZxsAz2sbALhuGwDpdBsAXQ0c AKUmHAD5KBwAdjccAJ0/HADiRxwARkwcAKRPHADjXRwABhIdAO0XHQCpMB0AnD0dAE1DHQDTUh0A I2YdAMoYHgBMNB4AETgeAMVUHgB7WB4AlXMeAGUGHwCmEh8AghcfAEAdHwC4JR8AeDofAAxAHwAA Qh8AtlEfAOVZHwBiYh8AqHcfAMIDIABfIyAANCggAH5LIAAiWSAAyH8gADcCIQDRBSEAeQkhAPBI IQDhWSEAeHAhAIl6IQDxDCIAjCQiAPM4IgAyYCIAfiQjAJYzIwClNyMApHEjAPV0IwCwdyMAcn0j AEYuJADVQiQAi1ckANhbJAAjYCQAKwUlAIQGJQC9JSUAiSklACdBJQA9VSUAD2QlAGBxJQD+DSYA AiMmABdBJgA3RSYA2UkmAABpJgDQbiYAyUAnAGBNJwAVYicAGXAnAIB4JwAAeicAu34nAEMAKABp KSgAnSkoAH5uKAAgeygA/AApAEoRKQArEykAlxMpAMMnKQBtNykA4jspAKU+KQDmdCkAinUpAE0E KgDlOCoAyxkrAN4kKwD5KCsAcTUrAAdMKwAPdisAciQsAEsnLADUKSwAB0ksAEtgLADbaSwAuAEt AHEGLQDABi0ARSEtAARFLQB+RS0AKUwtAPRjLQDeaC0AJEIuADRNLgC8UC4AtCAvABUnLwCELC8A 6TovANJZLwAhYi8AGWYvANAOMACVDzAA6hAwAG0cMAAQHTAAPzUwAABwMAAfBjIAHBgyAOIqMgC0 MDIAGFsyAPM0MwBiZDMA3mozAAwRNAA4NjQAE0k0ANV6NABcITUAMUQ1APxiNQAudzUAVXk1AGAG NgBVDzYAMGQ2APF3NgDnJTcAKVE3ACNQOAA/VjgAsnY4APQGOQAoEDkAaRI5AHxJOQAMfDkASnw5 AFcFOgBfCToAvQs6ABwuOgAYQjoAEFE6APpuOgBRejoAWzk7AKA6OwCKQTsAA0c7AGFlOwDNBjwA ww88AP8/PACFSjwAQFc8AHkyPQAzRj0AY049AMBFPgB8Rz4AlUk+AKBTPgC7Vz4ADAk/AOwRPwAz Ij8A20Y/AIlpPwDhI0AAszRAALRuQABSKUEAQDdBAFdOQQDTbkEAFQpCAKkzQgC4U0IAKi5DAOlN QwCMU0MAGGlDADMHRAAmF0QAYChEAGctRAClLUQA/T1EAHJyRACieUQAan1EAI4BRQCcAUUAuwNF AMgKRQBzC0UAuwtFAGEfRQBLUkUAglRFAJhbRQA8cUUAryxGAKE1RgC8N0YAyXhGAM54RgAhGEcA ridHAH8pRwC3L0cACUBHAFJFRwAPYkcAnm9HAMJWSADZWEgA+XxIACISSQBANkkApzxJACBPSQDv XEkAXitKAEssSgB6REoAyltKAJpwSgCzckoApXxKAJcESwB7JUsA0ytLAFEwSwB9OEsAgFRLAKlv SwDwCUwAoBhMAKNBTADaZUwA5hhNAJoxTQDKN00A9VtNAOhsTQDWAE4AinJOAF8ATwB0Ck8AlTJP APUzTwBPQk8AMGpPAOV4TwChA1AAUSpQAAYyUAAcT1AA6llQADsGUQCIO1EAR01RAM9qUQCld1EA AyNSAHtJUgDRS1IAeQVTAA4nUwA9RFMAE15TAB5vUwChdVMALgJUAOsOVAAqGlQAH1BUABhVVABh ZVQAmnZUAKECVQDCFlUAqxlVADQuVgBmPFYAS0NWABJNVgDcXVYABWpWAJh6VgBjGFcAtCFXACYl VwA/JlcA9CdXAJpCVwDvRVcAKBdYADwyWABGO1gADz1YAD5rWABDcFgAWxVZAI0jWQCVNlkA0UtZ AF0iWgDsI1oAjSpaABY7WgDHQVoAgl1aANxeWgBAeFoA1gdbAEkiWwAMKlsAhjJbANkyWwA0QVsA JkJbAFwiXAAFP1wAMEBcACJHXAA+U1wAAWBcADNqXADAcVwAnXZcAEF3XAAiJl0AcWBdAHd8XQDm PV4AgmNeAEtlXgBHa14A9G9eAGJ4XgChFF8Awz1fAE9IXwBvbV8AxH5fAKoBYAAhCWAAfhtgALMi YAC9MmAAxkhgALgIYQBnGmEAazBhADI8YQBNVGEAiwdiAH8LYgA2JmIAOzJiACo7YgCpVmIAElpi AA8mYwA9LWMAA05jALdOYwBBImQAdylkAD1FZACbUGQAZWdkAD1tZADtfGQAkwxlALc1ZQDrR2UA DVdlAOhXZQCNX2UAmGNlADgCZgBbCGYAXBBmABwRZgB4dWYArRBnAMslZwDTPmcAjVxnAGJrZwAb AGgAAl9oANUAaQDfVWkAwQpqAKIXagDxYWoAWGlqAFluagA9f2oAnRZrANEhawAnKmsACT5rANps awAAHGwAyh5sAEMkbAAcKWwAnENsAAdEbABwY2wAlSptABRCbQAvV20APCtuAHIsbgD8XW4ARRJv AHgvbwCENG8AtVNvAGoocAAgMHAA+UdwANBccABKAHEAxgZxAHAKcQBoGXEA80lxACNhcQC2ZHEA 2WlxAHVrcQA1bnEAtRpyAK0ccgAGO3IAm0FyABpJcgDyX3IAM2pyAGEZcwA6G3MAJDpzAFk/cwAr SXMAdVpzAHRzcwBzFHQAEzZ0AO9PdAC2YnQA32R0ADhydAAefXQArwJ1AM4IdQBHEnUAOht1AB8m dQAlInYA1SN2AHA8dgBfRHYAzwN3ANhIdwDwX3cAxgx4AOsQeADjGXgAZUJ4AKFGeACgT3gAQAd5 AGMNeQC1HnkABid5AIoxeQCUNXkAnjZ5ACY5eQDqRXkA42h5ALN1eQA3fXkANn55AB4HegDZEnoA 1xN6AFAUegCVF3oABB96AAdgegAdJ3sAcSt7AM09ewAbSXsAxFZ7AI9hewAJHHwA3yR8AIItfACL QHwAvUZ8AJ55fADUHH0AyCJ9AENWfQAmZH0AxmR9AP06fgDgWH4A5Ft+ALkLfwDDU38AD2Z/AK0u gAAEaoAAz2uAAG8CgQDLH4EA8TGBABpAgQALRIEAr0iBAJNKgQB3XYEA/2CBALZugQArDIIA9jCC APEAgwBoLYMANDaDAIU5gwDsXYMA3W2DAPV4gwA/e4MA0gaEAGMghACeKYQAni2EAK18hAA/AYUA 70yFAChQhQCWUoUAolaFAAxhhQAyZ4UAfW6FAH0BhgDXAoYASQSGAOYshgAhV4YA2iqHAF43hwDT OIcARUuHAKh3hwABJIgAJzOIAPVEiABGT4gA7lGIAHpZiACce4gA932IAAAZiQAbNokA4G+JAIZ/ iQAZAYoAnm6KAHlxigB+dooA9H2KAGISiwB/aYsACAmMAC4SjADcN4wAhTmMADNzjADiA40AQwSN AGwNjQDgDY0AqyeNAIFfjQDZZo0Adg6OACcpjgDzMY4AmkKOANdJjgCfVI4AyHOOAOQDjwCmBI8A uBCPAPQTjwBFIY8AryWPAKRBjwBDdo8AAxOQAA0ckAAUKJAAJTiQADxSkACgVZAAaHaQAE0qkQAJ QZEAL2ORAKtskQB0bZEAOxKSAEoakgA4KZIATTySAEpMkgD3W5IAcWWSAFFqkgDhapIAWHKSAO95 kgA2BZMAEQeTANUjkwAZJJMAojSTANQ7kwCpTZMAVlOTAO9jkwDJZJMAgwiUAPImlABGLJQArTKU AE86lACISJQAME+UAAxZlADzZZQAkE+VAO9PlQBPVpUATGyVAC4ElgBTJZYAVUeWAI1NlgDnU5YA R1eWAB9blgBuYJYAF3SWAA58lgDKJpcAJTGXAJJDlwAqS5cApVOXABwemADLMJgAJDyYAFZSmAAE YJgAb2SYADNymAA7GJkAyiKZAKgmmQCxLJkASlOZAFpamQC8YJkAg2iZAMJrmQBIC5oAzw6aAK0P mgCuMpoAxkSaAP8WmwAsK5sAKEObACVdmwBfaJsA8A2cAPwrnACLR5wAAEqcADpXnAD4fJwAaRGd AHkenQDnI50AQS6dAKFDnQBqb50AbjOeANJpngBqfJ4AvB6fAHs1nwDDZp8A7AegAO9CoAAGbKAA gW2gALoEoQDMJaEAAUmhAOVnoQBYd6EADQKiANVVogAyVqIAiWGiAAF5ogCKfKIALA+jAIwlowC2 VqMAY1qjALFkowBwb6MAkzKkAMNCpAC1XqQAJGekAPI7pQAOXqUANwCmAIcEpgANDqYA/iSmAFdc pgDdYKYAMGSmAFx6pgByfqYARgqnADYNpwCWHKcAaDOnAAVfpwCDb6cA3n2nAPIaqACyJ6gAt0io ABNZqADBAqkAywKpAJYNqQAHGqkAVjCpAG07qQCcW6kAmWGpADALqgBJN6oAeWmqAGV1qgBxEKsA ayWrAIlEqwASEKwAah2sABcmrABEOawAMkWsAIkOrQAdMa0AVUutAIFOrQCvVK0Am2KtAE1prQDS G64A+x+uAJ12rgCFHa8AvjuvAAlCrwAbLbAAAV2wAMEysQDhQ7EAQ1SxAGhXsQApMrIAR0iyAPRV sgBmCLMALxCzAA0fswA/YrMAbmWzAOJuswApfrMArQ+0AH0RtACSEbQA6xq0AKgptAA7LbQAh3C0 ANEItQCVFbUA6TC1AIJHtQBVe7UAawG2ADQXtgBSGrYAryS2ANUvtgAnObYAFzy2APxatgDTXbYA 1WS2ADdotgDYc7YA3QG3ACkEtwB5EbcAAye3AMostwCOMLcA4ky3ACN8twBRAbgASw24AHcOuAAA GLgAGB64AAYEuQCGCrkAzEe5AGVLuQAeALoAeBS6AMUfugBGRLoABEm6AIBMugDQUboA6n26APAL uwDbFbsA/h+7ALoiuwD1R7sAfHC7AIx8uwCUDbwA3A68AHERvACYFLwAbxe8AKwxvACuPbwAYXK8 AGU8vQAfS70A9k29ANJvvQA6f70AsxC+AN8WvgAgKb4AMU2+ALdcvgBFcL4ACAG/AEgHvwCwI78A vSe/APQxvwD0Nb8AFje/AKA3vwBgOr8AVD6/AAdHvwCMar8AjiXAAHNAwACQXcAALF/AADRqwAB0 E8EA0RXBAIknwQDJKcEAC0jBAEpKwQCyUMEA21jBAPpbwQBZasEAzAPCAEMUwgCxIcIA9iXCAE4+ wgDudsIAaHzCAEAMwwCAIsMABUfDAG9bwwDzaMMAbgHEALY6xADOWcQA2V3EAChkxAAwZsQATg3F AEMwxQCPW8UAxnzFAGAGxgB4EsYATBTGAIwgxgDGJsYAMC3GALxHxgBhSMYAMQHHABQVxwDHF8cA tyvHAENExwDkVMcAkFrHADBnxwBEEcgAfxnIAAUzyACYW8gAxWDIAF5yyAAVA8kAhxDJACxByQCW T8kAogfKAF4NygCZD8oAlz7KAPJEygBoVcoAnFzKAA1lygBfZ8oAJXXLAD94ywDvf8sARQTMADYf zAC6H8wApSHMADg1zADnOMwAoVPMALlfzAClY8wACWnMAJQWzQAwKs0Aci/NAEYEzgDaJ84A/ETO ACgIzwAEHc8AjSDPAN0mzwCNJ9AAlizQAK5H0ACmSNAArlXQADJd0AA9EdEAPjbRACY70QDtStEA YFXRAC960QC0IdIAfyvSAA8s0gArLtIAfD7SACZw0gCGf9IAHwfTAJMl0wBcKtMAEz7TAAQq1ABR MtQAzzfUAKJA1ACMR9QA50fUAPNx1ADqddQA8QvVAHIU1QAjPNUA3lnVAB5b1QC2ZdUAjQnWALwQ 1gALLdYAGz3WAEtK1gD8WNYANRPXAMoY1wC5UdcAxGXXAL8O2ADwENgAJRLYAMgl2AAGLtgAETbY AGFt2ACxbdgA5ADZANsB2QCaDNkA0iPZAJRe2QDVZ9kAy3XZAHAD2gCaCNoAzA3aABIW2gCiGtoA cSfaAAtX2gBQedoA9RvbAHUc2wDIPtsAQmHbAFhl2wBQcNsA6HTbAFxH3AD9R9wA4U3cALZv3ABd ftwAgxTdADka3QB7Ht0AaR/dAItV3QBCed0A3RfeACof3gBAUN4AbFfeAO513gCmd94AJVjfAJFl 3wAybN8AWXzfAK4N4ABXQ+AAEQXhAM4d4QBQNeEAmUjhAL5Q4QC6XuEAWmDhAD5k4QAgKuIAfUbi ALFH4gC0YOIAm2LiACd54gAke+IAPgHjAKMG4wAICeMADizjAKQu4wC/OOMAZGTjAPR24wCSAOQA 0AnkAGkR5AB5Y+QAIXLkAGE25QD6J+YAEyjmAPpk5gCUduYAXhDnACIS5wB4F+cAwCHnAE4q5wAf R+cA71bnAFBe5wBDYucAaQHoANcE6ABsDegA0BnoAE5D6AA1T+gAbH7oAKV/6ADZB+kAJyPpAKgp 6QD+NekAkWnpACZz6QDsI+oAIj/qAIxv6gDNf+oANQLrAPoS6wBWGesAtyjrAIA06wASPesApz3r AMlc6wAkbusA8y3sAIsw7AAZTuwAQFbsABVZ7ADpbOwAPRDtAKIZ7QD+Hu0AyDbtAL8B7gBKBe4A vwfuABdB7gCoWu4AGwnvABMK7wCwLu8AE0XvAJNb7wD+Xu8A42HvALNr7wBnB/AAtTDwAFA78AB8 A/EA6RHxAA4x8QBpMfEA1j7xADN28QAWEfIAKBzyAJUl8gBrS/IAWlLyAA0L8wBlEPMAmi/zAP5K 8wBjWvMA8gL0AIQc9ABVKvQAWS30AKw09ACVN/QAIzz0AE0+9ACrUvQAvGr0AHsB9QBKCfUAKhn1 AB8l9QCAJvUAYi/1AA0w9QCVQfUAQm/1AGt59QD+FPYAshn2AC4n9gDzM/YAfDz2AFRa9gCjFvcA iSL3AA4n9wCNMfcASTz3AK089wDOVfcAi2n3ACgF+AC8CfgA5y74AK04+AAnT/gAbwz5ALsf+QBD IvkA4Sn5AJRG+QDeWvkAvmP5ADsi+gCLIvoAlyz6ANA2+gA6PvoA/VT6AG4v+wD4UPsAdHP7AGp8 +wD+IPwAMjT8AMIB/QAPTv0AI3T+ABwZ/wDUN/8Ap1T/ABxW/wAEV/8AAAAAACQDAAAmAwAAAAAA AAEAAAD/QAGAAQD2AQAA9gEAAACI+BMBAAEA9gEAAAUAAAD2AQAAAAAAAAIQAAAAAAAAACQDAADw AAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAA AgD//wAAAAD//wAAAgD//wAAAAAIAAAARx6QAQAAAgIGAwUEBQIDBIcqACAAAACACAAAAAAAAAD/ AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAA AAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMy6QAQAAAgsGBAICAgICBIcqACAA AACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEc1kAGACgICBgkEAgUIAwS/AgCg+/zHaBAA AAAAAAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcAADsOkAGGBwIBBgAD AQEBAQEDAAAAAAAOCBAAAAAAAAAAAQAEAAAAAABTAGkAbQBTAHUAbgAAAItbU08AAD89kAEAAAIH AwkCAgUCBASHKgAgAAAAgAgAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7 DpABAgAFAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMA AABBHpABAAACBAUDBQQGAwIE7wIAoOsgAEIAAAAAAAAAAJ8AAAAAAAAAQwBhAG0AYgByAGkAYQAg AE0AYQB0AGgAAAAiAAQAcQiIGADw0AIAAGgBAAAAAOAS+abgEvmmAAAAAAIAAQAAAHgAAACsAgAA AQABAAAABAADEAUAAAB4AAAArAIAAAEAAQAAAAUAAAAAAAAA0QIA8BAAAAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACAegBbQAtACBgXI0AAAQABkAZAAAABkAAAAjAwAAIwMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAA AAANM4NxAPAQAAjc//0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEhYAAAAAAnw/w8BCAE/AADk BAAA////f////3////9/////f////3////9/////f+ls7AAABAAAMgAAAAAAAAAAAAAAAAAAAAAA AAAAACEEAAAAAAAAAAAAAAAAAAAAAAAAEBwAAAcAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUA AP//EgAAAAAAAAASAEEATgBOAEUAWAAgAEgAIAB0AG8AIABUAEQAMwAyADQALwBQAAAAAAAAAAcA SwBhAG0AIABMAEEATQADAEsAYQBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAYAAAACAAAAAAAM AAEADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAB4AQAAEQAA AAEAAACQAAAAAgAAAJgAAAADAAAAtAAAAAQAAADAAAAABQAAANAAAAAGAAAA3AAAAAcAAADoAAAA CAAAAPwAAAAJAAAACAEAABIAAAAUAQAACgAAADQBAAAMAAAAQAEAAA0AAABMAQAADgAAAFgBAAAP AAAAYAEAABAAAABoAQAAEwAAAHABAAACAAAAtgMAAB4AAAAUAAAAQU5ORVggSCB0byBURDMyNC9Q AAAeAAAABAAAAAAAAAAeAAAACAAAAEthbSBMQU0AHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAA AAwAAABOb3JtYWwuZG90bQAeAAAABAAAAEthbQAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jvc29m dCBPZmZpY2UgV29yZAAAAEAAAAAARsMjAAAAAEAAAAAAmOp0hWnMAUAAAAAAmOp0hWnMAQMAAAAB AAAAAwAAAHgAAAADAAAArAIAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUB AgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5 rlABAAAMAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwAAAAXAAAA pAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAA6wAAAAIAAAC2 AwAAHgAAABQAAABMdWNlbnQgVGVjaG5vbG9naWVzAAMAAAAFAAAAAwAAAAEAAAADAAAAIwMAAAMA AAAAAAwACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABMAAABBTk5FWCBI IHRvIFREMzI0L1AADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAxAAAAAMAAAAAAAAA IAAAAAEAAAA4AAAAAgAAAEAAAAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAAtgMAAEEAAAB8 AAAABgAAAAMAAABmAF8AAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAAACIAAABtAGEAaQBsAHQA bwA6AEsAYQBtAC4ATABhAG0AQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQAA AB8AAAABAAAAAAD6HQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQA AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAAP7///8RAAAAEgAA ABMAAAAUAAAAFQAAABYAAAAXAAAA/v///xkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAA IQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAv AAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA/v///zcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0A AAD+////PwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAP7////9////SAAAAP7////+/////v// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0 AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAIIV5jYVpzAFKAAAAgAAAAAAAAABE AGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABAAAAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGAAAAK06AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALh4AAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAAAEAAAAAAAAAUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA PgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAA AADAAAAAAAAARicAAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgOTctMjAwMyBEb2N1bWVudAAKAAAA TVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////////// AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABgxQOniWnMAVEAAACABAAAAAAAAEQAYQB0 AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAA AAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAYAAAArToAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuHgAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAAP7///8RAAAAEgAAABMAAAAU AAAAFQAAABYAAAAXAAAA/v///xkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAA ADEAAAAyAAAAMwAAADQAAAA1AAAA/v///zcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAD+//// /////////////////////////////////////////////////////////////////////1AAAAD9 /////v///08AAAD+/////v///04AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////AQAAAP7///8DAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8FAAAAgAEAAAYAAAAYAgAABwAAAFgC AAAGAAAAAgAAAAwAAABfUElEX0hMSU5LUwADAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQABAAA ABAAAABfTmV3UmV2aWV3Q3ljbGUABQAAAA4AAABfRW1haWxTdWJqZWN0AAYAAAANAAAAX0F1dGhv ckVtYWlsAAcAAAAYAAAAX0F1dGhvckVtYWlsRGlzcGxheU5hbWUAAAIAAAC2AwAAQQAAAHwAAAAG AAAAAwAAAGYAXwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIgAAAG0AYQBpAGwAdABvADoA SwBhAG0ALgBMAGEAbQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAAAAHwAA AAEAAAAAAPodAwAAAP9o9bMfAAAAAQAAAAAAAAAfAAAARwAAAFsAbQBwAGwAcwBdACAAVgBlAHIA aQBmAGkAYwBhAHQAaQBvAG4AIABjAGEAbABsACAAbwBuAAkAZAByAGEAZgB0AC0AaQBlAHQAZgAt AG0AcABsAHMALQB0AHAALQBtAGkAYgAtAG0AYQBuAGEAZwBlAG0AZQBuAHQALQBvAHYAZQByAHYA aQBlAHcAAAAAAB8AAAAbAAAAawBhAG0ALgBsAGEAbQBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBl AG4AdAAuAGMAbwBtAAAAAAAfAAAAFAAAAEwAYQBtACwAIABIAGkAbgBnAC0ASwBhAG0AIAAoAEsA YQBtACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAABAAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC AQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADYAwAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAA AABGJwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCA5Ny0yMDAzIERvY3VtZW50AAoAAABNU1dvcmRE b2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5QAQAA DAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAAL AAAArAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAOsAAAACAAAAtgMAAB4A AAAUAAAATHVjZW50IFRlY2hub2xvZ2llcwADAAAABQAAAAMAAAABAAAAAwAAACMDAAADAAAAAAAM AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAATAAAAQU5ORVggSCB0byBU RDMyNC9QAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAIgCAAAIAAAAAAAAAEgAAAAB AAAA4AAAAAIAAADoAAAAAwAAAGwBAAAEAAAAdAEAAA== --_002_7F76AEFB05C38145BABA0D545E3CFFD57FB42DB1USNAVSXCHMBSA2n_-- From eric.gray@ericsson.com Tue Sep 6 00:41:44 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759D721F84AA; Tue, 6 Sep 2011 00:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMt9T6-aumQn; Tue, 6 Sep 2011 00:41:43 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0D21F84A3; Tue, 6 Sep 2011 00:41:43 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p867fDep002211; Tue, 6 Sep 2011 02:43:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 6 Sep 2011 03:42:56 -0400 From: Eric Gray To: Zhenlong Cui , "ietf@ietf.org" , "'IETF-Announce'" Date: Tue, 6 Sep 2011 03:42:54 -0400 Thread-Topic: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Thread-Index: AcxYLQ19hjJdrZawTPmNVdgC6iRmUQKwNaAQAl4xZ+A= Message-ID: References: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> In-Reply-To: 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 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 07:41:44 -0000 Zhenlong, I responded to this as part of a response to Yoshinori Koike. =20 If the intention of the requesting MEP is to specify a specific=20 interface, then the appropriate IF_NUM would be set to the IF_NUM=20 of that interface. The format used allows either IF_NUM to be set. If only one=20 is intended (as in the per-interface case), then only that IF_NUM=20 would be set (the other would be set to Zero). There is at least one case where setting both may be useful.=20 Also, while it is not useful to include this TLV if neither is set,=20 this is not explicitly disallowed. As you may have seen, the use of IF_NUM - together with the=20 destination identifier - exactly matches the way that MIP ID is=20 defined in section 7.3 of "MPLS-TP Identifiers." Hence the combination of Destination Identifier and DSMAP or DDMAP TLVs - with a specific interface's IF_NUM set - is clearly sufficient to identify the "per-interface" MIP. -- Eric=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Zhe= nlong Cui Sent: Thursday, August 25, 2011 2:17 AM To: ietf@ietf.org; 'IETF-Announce' Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: (MP= LSOn-demand Connectivity Verification and Route Tracing) toProposed Standar= d Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd li= ke to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of "IF_NUM" in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the "IF_Num" can be used for per-interface MIP model. But I'm not sure why we need use both "ingress IF_Num" and "egress IF_Num" = in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identif= iers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using "I= F_Num", but there is no Ingress_IF::Egress_IF. - "IF_ID"=20 IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. =20 - "MIP ID" For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected.=20 If have any special means in the "IF_Num", I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for= each IF information of the "IF_Num". Best regards, zhenlong > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of T= he IESG > Sent: Thursday, August 11, 2011 10:46 PM > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: (MPLS= On-demand Connectivity Verification and Route > Tracing) toProposed Standard >=20 >=20 > The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'MPLS On-demand Connectivity Verification and Route Tracing' > as a Proposed Standard >=20 > 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 2011-08-25. 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. >=20 > Abstract >=20 > Label Switched Path Ping (LSP-Ping) is an existing and widely > deployed Operations, Administration and Maintenance (OAM) mechanism > for Multi-Protocol Label Switching (MPLS) Label Switched Paths > (LSPs). This document describes extensions to LSP-Ping so that LSP- > Ping can be used for On-demand Connectivity Verification of MPLS > Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also > clarifies procedures to be used for processing the related OAM > packets. Further, it describes procedures for using LSP-Ping to > perform Connectivity Verification and Route Tracing functions in > MPLS-TP networks. Finally this document updates RFC 4379 by adding a > new address type and requesting an IANA registry. >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Tue Sep 6 02:57:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E319221F85B5; Tue, 6 Sep 2011 02:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.134 X-Spam-Level: X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=2.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2d5P1RA9LfX; Tue, 6 Sep 2011 02:57:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAAA21F8593; Tue, 6 Sep 2011 02:57:53 -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 <0LR300H3GIEEQN@szxga04-in.huawei.com>; Tue, 06 Sep 2011 17:59:03 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR3004DJIE5MS@szxga04-in.huawei.com>; Tue, 06 Sep 2011 17:59:02 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV08440; Tue, 06 Sep 2011 17:59:02 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 17:58:59 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.122]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 06 Sep 2011 17:58:57 +0800 Date: Tue, 06 Sep 2011 09:58:56 +0000 From: Xuxiaohu In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C474@szxeml525-mbx.china.huawei.com> X-Originating-IP: [10.110.98.53] To: "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C49F@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt Thread-index: AQHMbGsFjE6nNbiPlUqa5mAsL2AVYZVAAOgwgAATWMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE72C474@szxeml525-mbx.china.huawei.com> Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-xu-l2vpn-vpls-isis-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 09:57:54 -0000 SGkgYWxsLA0KDQpJIGp1c3QgcmVhbGl6ZWQgdGhhdCB0aGUgbG9jYWxseSB1bmlxdWUgVlBMUyBs YWJlbCB3aGljaCBpcyBhZHZlcnRpc2VkIGluIHRoZSB0by1iZS1kZWZpbmVkIElTLUlTIFRMViBj b3VsZCBhY3R1YWxseSBiZSB1c2VkIGZvciBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdC4gSW4g b3RoZXIgd29yZHMsIHRoZSBzYW1lIFZQTFMgbGFiZWwgY291bGQgYmUgdHJlYXRlZCBhcyBhIGRv d25zdHJlYW0tYXNzaWduZWQgbGFiZWwgZm9yIHVuaWNhc3QgYW5kIGEgdXBzdHJlYW0tYXNzaWdu ZWQgbGFiZWwgZm9yIG11bHRpY2FzdC4gRm9yIGV4YW1wbGUsIGFzc3VtZSBQRS0xIGFkdmVydGlz ZXMgYSBsb2NhbGx5IHVuaXF1ZSBsYWJlbCBMIGZvciBWUExTIGluc3RhbmNlIFggd2l0aCB0aGF0 IHRvLWJlLWRlZmluZWQgSVMtSVMgVExWLCBvdGhlciBQRSByb3V0ZXJzIGNvdWxkIHNlbmQga25v d24gdW5pY2FzdCBwYWNrZXQgZGVzdGluZWQgZm9yIFBFLTEgd2l0aCBsYWJlbCBMIGNvbnRhaW5l ZCBhcyBhIGRvd25zdHJlYW0tYXNzaWduZWQgbGFiZWwuIE1lYW53aGlsZSwgUEUtMSBjb3VsZCBz ZW5kIGEgbXVsdGljYXN0IHBhY2tldCBmb3IgVlBMUyBYIGNvbnRhaW5pbmcgbGFiZWwgTCBhcyBh biB1cHN0cmVhbS1hc3NpZ25lZCBsYWJlbC4gVGhlIGVncmVzcyBQRSByb3V0ZXJzIGNvdWxkIGRp c3Rpbmd1aXNoIHdoZXRoZXIgdGhlIE1QTFMgbGFiZWwgY29udGFpbmVkIGluIHRoZSBlbmNhcHN1 bGF0ZWQgVlBMUyBwYWNrZXQgaXMgYW4gdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwgb3IgYSBkb3du c3RyZWFtLWFzc2lnbmVkIGxhYmVsIGFjY29yZGluZyB0byB0aGUgIk1QTFMgbGFiZWwgdHlwZSIg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSBlbmNhcHN1bGF0ZWQgVlBMUyBwYWNrZXRzLCB0 YWtlbiB0aGUgTVBMUy1pbi1HUkUgZW5jYXBzdWxhdGlvbiBhcyBhbiBleGFtcGxlLCB0aGUgcHJv dG9jb2wgdHlwZSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciB3b3VsZCBiZSBzZXQgdG8gMHg4ODQ3 IGZvciBNUExTIHVuaWNhc3QgYW5kIDB4ODg0OCBmb3IgbXVsdGljYXN0LiANCg0KQW55IGNvbW1l bnRzPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQo+IOWPkeS7tuS6ujogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBYdXhpYW9odQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQ5 5pyINuaXpSAxNjoyNA0KPiDmlLbku7bkuro6IGwydnBuQGlldGYub3JnDQo+IOS4u+mimDogZndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LWwydnBuLXZwbHMtaXNpcy0w MS50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IFRoZSBuZXcgdmVyc2lvbiBvZiBJUy1JUyBWUExT IGlzIG5vdyBhdmFpbGFibGUgYXQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt eHUtbDJ2cG4tdnBscy1pc2lzLTAxLiBJUy1JUyBWUExTIGlzIGEgbGlnaHQtd2VpZ2h0DQo+IFZQ TFMgd2hpY2ggaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHNjYWxhYmxlIGNsb3VkIGRhdGEg Y2VudGVyIG5ldHdvcmsNCj4gc29sdXRpb24uDQo+IA0KPiBBbnkgY29tbWVudHMgYXJlIHdlbGNv bWUuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLemCruS7tuWO n+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0Oeac iDbml6UgMTU6NTgNCj4gPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4g5oqE6YCBOiBoc2hhaEBj aWVuYS5jb207IFh1eGlhb2h1DQo+ID4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXh1LWwydnBuLXZwbHMtaXNpcy0wMS50eHQNCj4gPg0KPiA+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC14dS1sMnZwbi12cGxzLWlzaXMtMDEudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseQ0KPiA+IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6CSBkcmFmdC14dS1sMnZwbi12cGxzLWlz aXMNCj4gPiBSZXZpc2lvbjoJIDAxDQo+ID4gVGl0bGU6CQkgVmlydHVhbCBQcml2YXRlIExBTiBT ZXJ2aWNlIChWUExTKSBVc2luZyBJUy1JUw0KPiA+IENyZWF0aW9uIGRhdGU6CSAyMDExLTA5LTA2 DQo+ID4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gTnVtYmVyIG9mIHBhZ2Vz OiA5DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IGxpZ2h0LXdlaWdodCBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2UNCj4gPiAgICAoVlBMUykg d2hpY2ggdXNlcyBJUy1JUyBmb3IgYXV0by1kaXNjb3ZlcnkgYW5kIHNpZ25hbGluZy4NCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From rcallon@juniper.net Tue Sep 6 13:51:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8BA21F8E1B for ; Tue, 6 Sep 2011 13:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf-K8Qw2qJ85 for ; Tue, 6 Sep 2011 13:51:10 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB721F8E19 for ; Tue, 6 Sep 2011 13:51:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTmaIJljSS2jAxRfqmcYN2tAV5nVZx1aL@postini.com; Tue, 06 Sep 2011 13:52:55 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 6 Sep 2011 10:40:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 6 Sep 2011 13:40:08 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 6 Sep 2011 13:40:06 -0400 Thread-Topic: WG last call on draft-ietf-mpls-ldp-iana-01 Thread-Index: AcxsvAO9OlUM0NimTJmOhPh+NTTJqQ== Message-ID: 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: [mpls] WG last call on draft-ietf-mpls-ldp-iana-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 20:51:10 -0000 Working Group, This is to start a two week working group last call on draft-ietf-mpls-ldp-iana-01 ["Label Distribution Protocol (LDP)=20 Internet Assigned Numbers Authority (IANA) Considerations Update"]. Please send comments to the mpls@ietf.org mailing list. This working group last call ends on Tuesday September 20th.=20 George, Loa and Ross MPLS WG co-chairs From jeff.tantsura@ericsson.com Tue Sep 6 14:06:09 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CEF21F8E13 for ; Tue, 6 Sep 2011 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G2k08+irWhR for ; Tue, 6 Sep 2011 14:06:08 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9D84A21F8E11 for ; Tue, 6 Sep 2011 14:06:08 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p86L79d4021423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Sep 2011 16:07:55 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 6 Sep 2011 17:07:41 -0400 From: Jeff Tantsura To: Ross Callon , "mpls@ietf.org" Date: Tue, 6 Sep 2011 17:07:40 -0400 Thread-Topic: WG last call on draft-ietf-mpls-ldp-iana-01 Thread-Index: AcxsvAO9OlUM0NimTJmOhPh+NTTJqQAHPlCg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6135D801574@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: 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: Re: [mpls] WG last call on draft-ietf-mpls-ldp-iana-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 21:06:09 -0000 yes/support Regards, Jeff =20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, September 06, 2011 10:40 To: mpls@ietf.org Subject: [mpls] WG last call on draft-ietf-mpls-ldp-iana-01 Working Group, This is to start a two week working group last call on draft-ietf-mpls-ldp-iana-01 ["Label Distribution Protocol (LDP)=20 Internet Assigned Numbers Authority (IANA) Considerations Update"]. Please send comments to the mpls@ietf.org mailing list. This working group last call ends on Tuesday September 20th.=20 George, Loa and Ross MPLS WG co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From wwwrun@rfc-editor.org Wed Sep 7 14:40:39 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED921F8D5F; Wed, 7 Sep 2011 14:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.038 X-Spam-Level: X-Spam-Status: No, score=-102.038 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qsdPCHDmusE; Wed, 7 Sep 2011 14:40:39 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 20B4821F8D5E; Wed, 7 Sep 2011 14:40:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AF03B98C26B; Wed, 7 Sep 2011 14:42:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110907214229.AF03B98C26B@rfc-editor.org> Date: Wed, 7 Sep 2011 14:42:29 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6348 on Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 21:40:39 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6348 Title: Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol Author: J. Le Roux, Ed., T. Morin, Ed. Status: Historic Stream: IETF Date: September 2011 Mailbox: jeanlouis.leroux@orange-ftgroup.com, thomas.morin@orange-ftgroup.com Pages: 20 Characters: 38902 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-mp-ldp-reqs-08.txt URL: http://www.rfc-editor.org/rfc/rfc6348.txt This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure. This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. HISTORIC: This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC From agmalis@gmail.com Tue Sep 6 07:57:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B964421F8B03 for ; Tue, 6 Sep 2011 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWzxaTYUB6h8 for ; Tue, 6 Sep 2011 07:57:08 -0700 (PDT) Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2C21F8B01 for ; Tue, 6 Sep 2011 07:57:08 -0700 (PDT) Received: by qwb8 with SMTP id 8so5433827qwb.25 for ; Tue, 06 Sep 2011 07:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=45XuBSSr6nInRUCzqe6FURJbz4rqlj7ijKOycbINiAQ=; b=CweIBdyJicTvf2cziJ0zVd/7KHb75K8Q5SjB3RNNLJFPXSgR6dj4WFqmEArAKwf+KZ Bo7bthQN7rLjgHpLIdFDH4s4UQnT6XA1w4mJPwE+/MxWvq85/zLpLJ/monqnvq9PH4ZT uJTLxlPcIG3AjLZx1lq8a2W6gCdRl3gRqyvuo= Received: by 10.229.205.169 with SMTP id fq41mr3891197qcb.119.1315321134611; Tue, 06 Sep 2011 07:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.29.1 with HTTP; Tue, 6 Sep 2011 07:58:34 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 6 Sep 2011 22:58:34 +0800 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 07 Sep 2011 18:45:33 -0700 Subject: [mpls] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 14:57:08 -0000 This email begins a two-week poll on the PWE3 working group adoption of draft-zhang-mpls-tp-pw-oam-config-06, to end on Sept. 20. You can read the draft at https://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-06 . The MPLS working group was bcc:ed for their information. Please respond with any comments to pwe3@ietf.org ONLY. Thanks, Andy From eric.gray@ericsson.com Wed Sep 7 19:38:28 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C221F8C34; Wed, 7 Sep 2011 19:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-v538DR1RQe; Wed, 7 Sep 2011 19:38:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8921F8C26; Wed, 7 Sep 2011 19:38:26 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p882e5Xv007084; Wed, 7 Sep 2011 21:40:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 7 Sep 2011 22:40:00 -0400 From: Eric Gray To: Yoshinori Koike , "ietf@ietf.org" Date: Wed, 7 Sep 2011 22:39:57 -0400 Thread-Topic: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard Thread-Index: AcxjRMzj+g45E17eTyiFSmM6LOGPdAIJ+7yQAD7/GSA= Message-ID: References: <20110811134542.25435.61281.idtracker@ietfa.amsl.com> <4E5679AE.8010209@lab.ntt.co.jp> In-Reply-To: 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 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-on-demand-cv-all@tools.ietf.org" Subject: Re: [mpls] Last Call: (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 02:38:28 -0000 Yoshinori, et al, On thinking about this a little further, and considering that this is a recurring question, it seems likely that there is ambiguity that should be addressed. What I propose to do is add the following to the end of=20 section 2.1.1 that says (something along the lines of): =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=3D=3D=3D=3D=3D 'Including this TLV, with one or the other IF_Num (but not both) set to a non-zero value, in a request message that also includes a destination identifier TLV (as described in section 2.2.3), is sufficient to identify the "per-interface" MIP in section 7.3 of . Inclusion of this TLV with both IF_Num fields set to zero would be interpretted as specifying neither an ingress, nor an egress, interface. Note that this is the same as not including the TLV, hence including this TLV with both IF_Num values set to zero is=20 NOT RECOMMENDED. Including this TLV with both IF_NUM fields set to a non-zero=20 value will result in the responder sending a Return Code of 5 ("Downstream Mapping Mis-match") if either IF_Num is incorrect for this LSP or PW.' =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=3D=3D=3D=3D=3D The above text is intended for clarification, and to remove potential for ambiguity. The above interpretations are based on procedures spelled out in RFC 4379, section 4.4 ("Receiving an=20 MPLS Echo Request"). Hence this text does not substantively change the content of the draft in this respect. I believe this should clarify the point you were hoping we=20 could clarify. Please let me know if it does not... -- Eric -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Eri= c Gray Sent: Sunday, September 04, 2011 11:35 PM To: Yoshinori Koike; ietf@ietf.org Cc: mpls@ietf.org; 'IETF-Announce' Subject: RE: [mpls] Last Call: (MP= LSOn-demand Connectivity Verification and Route Tracing) toProposed Standar= d Yoshinori, The DSMAP/DDMAP was explicitly added to make it possible to direct the implementation to respond to the echo request as if it were directed to a specific interface (either the egress or ingress interface). This interface-specific echo request is what I believe=20 folks are referring to as "per-interface." This - in effect - is the primary use for the object in this draft, so any explicit statement to the effect that this=20 is the case would be redundant. While the object includes fields for both an ingress and=20 egress interface, when being used to direct the implementation to respond as if the echo request were directed to a specific interface, only one of these fields would contain valid info. It is possible that both interface numbers are valid. In this case, the object cannot be used for what you are calling a "per-interface" echo request. However, this case may be useful if - for example - the intention is to verify that the LSP is using this particular interface mapping at this node (i.e. -=20 the request is attempting to ascertain if this is the correct=20 mapping for the LSP). All of this is fairly intuitive to anyone who has read the draft and is reasonably familiar with the technology and protocols involved. This draft is a protocol specification, not a tutorial. As for what may be said in any other draft that is still in the process of being written, that is an issue that is not in scope for this draft. -- Eric -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Yos= hinori Koike Sent: Thursday, August 25, 2011 12:35 PM To: ietf@ietf.org Cc: mpls@ietf.org; 'IETF-Announce' Subject: Re: [mpls] Last Call: (MP= LSOn-demand Connectivity Verification and Route Tracing) toProposed Standar= d Hi, I would like to propose that this draft explicitly stipulate whether or=20 not it covers per-interface model. I think it is essential to avoid=20 confusion and clarify the appropriate I-D to discuss OAM solutions for=20 the per-interface model. "Per-interface model" is one of the two OAM maintenance models in=20 MPLS-TP networks which is specified in section 3 of=20 draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the=20 per-interface MIP draft (=20 http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the=20 on-demand-cv-06 covers the OAM solution for per-interface model, the=20 discussion for on-demand CV and route tracing must be removed from the=20 mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the=20 solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr.=20 Zhenlong Cui in the draft, whose email is attached at the bottom. It is=20 important to make clear for what purpose the "IF_Num" is used. It also=20 seems important to clarify the responder's behavior, because the=20 ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: > Hi, > > I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd = like to make sure it is not lost. > > 2.1. New address type for Downstream Mapping TLV > The new address type indicates that no address is present in the > DSMAP or DDMAP TLV. However, IF_Num information (see definition of > "IF_NUM" in [I-D.ietf-mpls-tp-identifiers]) for both ingress and > egress interfaces, as well as multipath information is included in > the format and MAY be present. > > > I believe the "IF_Num" can be used for per-interface MIP model. > But I'm not sure why we need use both "ingress IF_Num" and "egress IF_Num= " in a DSMAP TLV. > I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-ident= ifiers]. > > e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using= "IF_Num", but there is no Ingress_IF::Egress_IF. > - "IF_ID" > IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. > - "MIP ID" > For a MIP which is associated with particular interface, we simply > use the IF_ID (see Section 4) of the interfaces which are cross- > connected. > > If have any special means in the "IF_Num", I think MUST mention it clearl= y. > Also I feeling that this draft have to clarify the responder's behavior f= or each IF information of the "IF_Num". > > > Best regards, > zhenlong > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = The IESG >> Sent: Thursday, August 11, 2011 10:46 PM >> To: IETF-Announce >> Cc: mpls@ietf.org >> Subject: [mpls] Last Call: (MPL= SOn-demand Connectivity Verification and Route >> Tracing) toProposed Standard >> >> >> The IESG has received a request from the Multiprotocol Label Switching W= G >> (mpls) to consider the following document: >> - 'MPLS On-demand Connectivity Verification and Route Tracing' >> as a Proposed Standard >> >> 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 2011-08-25. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> Label Switched Path Ping (LSP-Ping) is an existing and widely >> deployed Operations, Administration and Maintenance (OAM) mechanism >> for Multi-Protocol Label Switching (MPLS) Label Switched Paths >> (LSPs). This document describes extensions to LSP-Ping so that LSP- >> Ping can be used for On-demand Connectivity Verification of MPLS >> Transport Profile (MPLS-TP) LSPs and Pseudowires. This document als= o >> clarifies procedures to be used for processing the related OAM >> packets. Further, it describes procedures for using LSP-Ping to >> perform Connectivity Verification and Route Tracing functions in >> MPLS-TP networks. Finally this document updates RFC 4379 by adding = a >> new address type and requesting an IANA registry. >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From masahiko.mizutani.ew@hitachi.com Wed Sep 7 22:21:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2E21F8B30 for ; Wed, 7 Sep 2011 22:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKi3f8EkJohY for ; Wed, 7 Sep 2011 22:21:34 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8331A21F8B3D for ; Wed, 7 Sep 2011 22:21:34 -0700 (PDT) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id F192F37C85; Thu, 8 Sep 2011 14:23:24 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id p885NOJe028008; Thu, 8 Sep 2011 14:23:24 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id p885NJlj024756; Thu, 8 Sep 2011 14:23:24 +0900 Received: from vshuts2.hitachi.co.jp ([vshuts2.hitachi.co.jp [10.201.6.71]]) by mfilter05.hitachi.co.jp with RELAY id p885NNoZ024790 ; Thu, 8 Sep 2011 14:23:24 +0900 X-AuditID: b753bd60-a1479ba0000050a4-d4-4e68514b4f24 Received: from gmml23.itg.hitachi.co.jp (unknown [158.213.165.143]) by vshuts2.hitachi.co.jp (Symantec Mail Security) with ESMTP id A0D358B02A4; Thu, 8 Sep 2011 14:23:23 +0900 (JST) Received: from [127.0.0.1] by gmml23.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id p885NNZ6221940; Thu, 8 Sep 2011 14:23:23 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Thu, 8 Sep 2011 14:23:16 +0900 References: <020f01cc5434$1b1734c0$51459e40$@olddog.co.uk> <4E3D3510.8060208@gmail.com> Priority: normal Importance: normal X400-Content-Identifier: X4E68513D00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml23110908142309ZL8] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-mpls-tp-rosetta-stone@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] Definition of MIP and MEP (again) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 05:21:35 -0000 Hi Huub, Adrian and rosetta-stone editors, I agree with the correction of MEP/MIP description. I think I, too, have pointed it out before. However, it doesn't seem to be reflected yet. Please do the correction at your earliest convenience. Thank you. Regards, Masahiko >Hello Adrian, > >You wrote: > >> I'm reviewing another I-D and turned to draft-ietf-mpls-tp-rosetta-stone-04 for >> a definitive expansion of MIP and MEP. >> >> I found section 1.2 >> MEP MEG End Point >> MIP MEG Intermediate Point > >This is the correct expansion. > >> However... >> 3.43. Maintenance End Points (MEPs) > >This should be also MEG End Points (MEPs), or completely expanded: >Maintenance Entity Group End Points (MEPs). > >> 3.44. Maintenance Intermediate Points (MIPs) > >This should be also MEG Intermediate Points (MIPs), or completely expanded: >Maintenance Entity Group Intermediate Points (MIPs). > >> Have I got caught on formality versus the colloquial, or is this something you >> need to fix in the draft? > >It will be fixed in the rosetta draft > >Best regards, Huub. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From internet-drafts@ietf.org Sat Sep 10 17:49:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DFB21F8A7B; Sat, 10 Sep 2011 17:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBzoNeokykkC; Sat, 10 Sep 2011 17:49:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7904121F8888; Sat, 10 Sep 2011 17:49:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110911004947.28797.94319.idtracker@ietfa.amsl.com> Date: Sat, 10 Sep 2011 17:49:47 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 00:49:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Mechanism for performing LSP-Ping over MPLS tunnels Author(s) : Nitin Bahadur Kireeti Kompella George Swallow Filename : draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt Pages : 23 Date : 2011-09-10 This document describes methods for performing LSP-Ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS label-switched-paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap= -11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-= 11.txt From loa@pi.nu Sun Sep 11 03:59:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611D121F8513 for ; Sun, 11 Sep 2011 03:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpNJEnNHfPfJ for ; Sun, 11 Sep 2011 03:59:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A3CCE21F8509 for ; Sun, 11 Sep 2011 03:59:25 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 788652A8002; Sun, 11 Sep 2011 13:01:22 +0200 (CEST) Message-ID: <4E6C9500.6020406@pi.nu> Date: Sun, 11 Sep 2011 13:01:20 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , draft-ietf-mpls-tp-mib-management-overview@tools.ietf.org, "mpls-chairs@tools.ietf.org" References: <4E5A0753.2010801@pi.nu> In-Reply-To: <4E5A0753.2010801@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-mib-management-overview X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 10:59:26 -0000 Working Group, this verification call has ended. All comments has been correctly addressed. The working gorup chairs will go ahead and request publication. /Loa for the mpls wg co-chairs On 2011-08-28 11:16, Loa Andersson wrote: > All, > > This is to start a one week verification call on > draft-ietf-mpls-tp-mib-management-overview > The authors has published version -05 of the draft. This document > is updated after working group last call. > > A complete diff between version -04 and -05 is found at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-mib-management- > overview-05.txt > > The comment resolution will be found at: > > http://www.pi.nu/~loa/man-overview-comments-resollution..txt > > This verification call ends September 4, 2011. > > Loa > for the MPLS wg chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@rfc-editor.org Sun Sep 11 10:48:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37221F84B4 for ; Sun, 11 Sep 2011 10:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3F8dqvGDMoy for ; Sun, 11 Sep 2011 10:48:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CC92D21F84B2 for ; Sun, 11 Sep 2011 10:48:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0342B98C248; Sun, 11 Sep 2011 10:50:37 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20110911175038.0342B98C248@rfc-editor.org> Date: Sun, 11 Sep 2011 10:50:37 -0700 (PDT) Cc: mpls@ietf.org, fl@n621.de, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3031 (2967) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 17:48:37 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=2967 -------------------------------------- Type: Editorial Reported by: fl Section: 3.20 Original Text ------------- When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs. Corrected Text -------------- When ordered control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From iesg-secretary@ietf.org Mon Sep 12 10:32:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0C21F8B9E; Mon, 12 Sep 2011 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duxEL9HAzj1X; Mon, 12 Sep 2011 10:32:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C850C21F8BA9; Mon, 12 Sep 2011 10:32:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912173240.12967.27291.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 10:32:40 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute' to Proposed Standard (draft-ietf-mpls-fastreroute-mib-21.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 17:32:41 -0000 The IESG has approved the following document: - 'Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute' (draft-ietf-mpls-fastreroute-mib-21.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-fastreroute-mib/ Technical Summary This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. Working Group Summary No controversies, but lots of discussion that have converged on this document, and the document has taken a rather a long time to progress. Protocol Quality We are aware of one implementation, but we have not polled the working group list for other implementations. Personnel Loa Andersson (loa@pi.nu) is the document shepherd Adrian Farrel (adrian.farrel@huawei.com) is the responsible AD RFC Editor Note Section 1.1 Please add NOT RECOMMENDED to the 2119 terms Section 6.1 definition of mplsFrrGeneralConstraintsEntry Please s/STRONGLY RECOMMENDED/strongly RECOMMENDED/ From daniel@olddog.co.uk Mon Sep 12 10:45:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ABC21F8C34 for ; Mon, 12 Sep 2011 10:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.881 X-Spam-Level: X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52cSi29YEqwt for ; Mon, 12 Sep 2011 10:45:09 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4121F8C1F for ; Mon, 12 Sep 2011 10:45:09 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8CHlCLs017317 for ; Mon, 12 Sep 2011 18:47:12 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8CHlBAf017308 for ; Mon, 12 Sep 2011 18:47:11 +0100 From: "Daniel King" To: Date: Mon, 12 Sep 2011 18:47:07 +0100 Message-ID: <003401cc7173$fdf74440$f9e5ccc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AcxxZ3oWecV0DbpWR3mGMyAP9V+OwQ== Subject: [mpls] draft-li-mpls-mt-applicability-requirement-02 Comments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 17:45:10 -0000 Hi draft-li-mpls-mt-applicability-requirement authors, A great to start to an interesting area. Please find a review of draft-li-mpls-mt-applicability-requirement-02. I have made a number of general comments, as well as specific suggestions, and where possible suggested text for clarity. If it would help, I can unicast a MS word document with change modification indicators to the current editor(s). 1. Some of the document is rather hard to read, I suggest bulleting and splitting some sections into sub-sections. Where possible, I have included specific text and recommendations. 2. Considering the document defines requirements. You might want to use numbering for specific requirements, this will help solution developers and they can specifically refer to requirement(s) and corresponding numbering as necessary. 3. There should be more emphasis on Security and Manageability Considerations. In some cases, potential issues can be addressed by referring to existing mechanisms. New Security and Manageability issues need to clearly articulated, as does potential impact to network operation. 4. Please see specific comments, NITs and text suggestions below: Line 8: s/ Verison Business/ Verizon Business Line 9: s/ B. zhang/ B. Zhang Line 19: I suggest further descriptive text in your abstract. Perhaps something along the lines of: >> Existing Multiple Topology (MT) technology provides a mechanism to compute paths and direct traffic based on specific topologies. These topologies are comprised of traffic types, links and interfaces. It would be advantageous to extend Multiprotocol Label Switching (MPLS) to support multiple topologies. These extensions, known as Multiprotocol Label Switching Multiple Topology (MPLS-MT), would allow the configuration of multiple topologies within an MPLS enabled network. This document describes the applicability and requirements of MPLS-MT. The applicability statement, use cases, and specific requirements are presented from the perspective of the customer (end-user), service provider and vendors. << Line 68: Just need some constancy with ToC. Some section headings are capitalised, others are not. Line 199: This is a good introduction on the whole. I might suggest the use of "Motivation" and "Scope" sub-sections. This would be useful for organising the Introduction text. Line 271: s/ Providerprovisioned / Provider Provisioned Line 286: s/ Multiple-Topologycan / Multiple-Topology can Line 300: You might want to consider the use of "Applicability" with the addition of "Use Cases". This will help vendors with developing solutions. I also think the initial text can be bulleted to help with readability. Line 324: s/ NHLFE / Next Hop Label Forwarding Entry (NHLFE) Line 347: s/ subobject / sub-object Line 355: Some minor nits with the diagram. P link, R3 interface, E-PE link need to use lines instead of a full stop. Line 378: Duplicate figure name (line 367). Line 382: s/ As stated above, MPLS-MT abstracts link state topology and identifies it by a unique MT-ID, which need not be the same as the IGP-MT ID. / As stated above, MPLS-MT abstracts link state topology which is identified using a unique MT-ID. An MT-ID does not need to be the same as the IGP-MT ID. Line 405: General comment. I would split the section into various sub-sections. This will help with readability and also highlight how enhanced protection and restoration mechanisms, using MPLS-MT, can be deployed. Line 408: s/ backup-mt / backup-MT Line 411: MPLS-LDP-MT, it looks like this could be a referenced. If so, it needs square brackets and entering as an informative or normative references. Personally, I think you should avoid referencing potential MPLS-MT solutions. Line 419: s/ undeterministic / non-deterministic Line 423: s/ diffult / difficult Line 426: s/ differnt / different Line 427: s/ differnt / different Line 463: s/ PCE / Path Computation Element. Actually are you sure the statement is correct? The router at the domain stitching point requires PCC/PCE capability. If the LSP is end-to-end, then only the head-end needs PCC/PCE capability, then it assumes the PCE performing the end-to-end path computation has source, transit and destination domain visibility. Finally, you might add an informative reference to relevant PCE drafts (RFC4655). Line 468: s/ differnt / different Line 471: s/ singe / single Line 477: s/ 6PE / IPv6 Provider Edge routers (6PE) and IPv6 VPN (6VPN). You might also want to add a normative reference (RFC4798?) Line 486: s/ gateway router,those tables / gateway router, those tables Line 486: s/ consequentlly / consequently Line 489: s/ plane / IPv6 plane Line 492: s/ intergation / integration Line 493: s/ It helps to capture the data on each hop and get a thorough view by hop by hop analyzing. / This would also help capture data on a hop by hop basis for further analyses. Line 515: You start using RFC2119 terminology, if this is intended then you will need to add the RFC2119 section/text to the start of the document. I would also challenge the use of RFC2119 terminology for some of the requirements, if for instance MPLS-MT services MUST have high availability stable, how would you quantify high availability? Or perhaps provide an informative reference to other RFCs that have definitions. Line 551: Just need some consistency with the use of P2P and P2MP (point-to-point, point-to-multipoint) across the document. Line 578: Security. I wonder if it would be best to move this section towards the end of the document (Security Considerations). This is also relevant for Management requirements split across various sections, these could be moved to a Manageability Considerations section. Line 627: Suggest capitalising/punctuating bullet sentences. Line 682: s/ Diffserv / DiffServ. It would be beneficial to include some informative references. Line 690: Looks to be an editor's note in the section heading. Editors notes are fine if you want to leave them in, but you should caveat with an additional comment . For instance: "(Editor's note to be removed before publication - This section will include further text regarding network resource partitioning") Line 715: s/ -effective / cost-effective Line 722: s/ MPLS -MTs / MPLS-MTs Line 741: This section (Service Provider Capacity Sizing Projections) may want further analyses. It's likely that MPLS-MT will run simultaneously with other protocols on a PE/P router. Do you want to mandate that a minimum set of MPLS-MTs should always be supported, regardless of the size of router (CPU/memory), etc. As performance and sizing/scalability is important you may just want to split the relevant sections out into a new Internet Draft that deals with scalability and performance issues (RFC5439 - An Analysis of Scaling Issues in MPLS-TE Core Networks, et al.). With further quantitative analysis and demonstrable findings, specific recommendations or requirements can be made. Line 767: s/ multiprovider / multi-provider Line 818: As mentioned earlier, I think the Manageability Considerations section should be added to the document and the relevant sections moved to this new section. Line 855: You need to be careful with the use of "real-time" as it's a relative term and subjective to each person. Line 927: s/ singleprovider / single-provider From adrian@olddog.co.uk Mon Sep 12 11:00:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380C421F8C6F for ; Mon, 12 Sep 2011 11:00:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIXu81R92CWh for ; Mon, 12 Sep 2011 11:00:00 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5D58821F8C68 for ; Mon, 12 Sep 2011 11:00:00 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8CI23Sl021850 for ; Mon, 12 Sep 2011 19:02:03 +0100 Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8CI20wD021833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Sep 2011 19:02:02 +0100 From: "Adrian Farrel" To: Date: Mon, 12 Sep 2011 19:02:02 +0100 Message-ID: <006801cc7176$14cd9a00$3e68ce00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcxxdgBQyuJo4WZNQA+uLej5qDrURw== Content-Language: en-gb Subject: [mpls] Late change to draft-ietf-mpls-tp-loss-delay-profile X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:00:04 -0000 Hi Wg, I just wanted to let you know about a very late change to this draft just as it is being made into an RFC. In Section 4, we had > This profile uses the MPLS Delay Measurement (DM) Channel Type in the > Associated Channel Header (ACH) [RFC5586]. While this is true, it is also confusing because if combined measurement is being used (e.g. DM and LM) then the appropriate channel type will be used. In order to avoid confusion and to make sure we don't appear to incorrectly limit the channel type over which DM can be run, this paragraph is being deleted. You might note that the section on LM used to have a similar paragraph, and this was deleted several revisions ago. Cheers, Adrian From iesg-secretary@ietf.org Mon Sep 12 13:31:07 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6731C21F8DA2; Mon, 12 Sep 2011 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugzZfsGZqA1V; Mon, 12 Sep 2011 13:31:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0521F8DA3; Mon, 12 Sep 2011 13:31:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912203105.1789.92681.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 13:31:05 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping' to Proposed Standard (draft-ietf-mpls-p2mp-lsp-ping-18.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 20:31:07 -0000 The IESG has approved the following document: - 'Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping' (draft-ietf-mpls-p2mp-lsp-ping-18.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-lsp-ping/ Technical Summary Mechanisms to detect data plane failures in point-to-point (P2P) LSP are described in RFC 4379 - these mechanisms are known as "LSP Ping". The working group has also documented requirements for P2MP LSP Ping. This document extends the techniques described in RFC 4379 such that they may be applied to P2MP LSPs. This document stresses the reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation. Working Group Summary LSP Ping is one of the key OAM tools developed by the MPLS working, the draft has well reviewed and is strongly supported by the working group. Document Quality The document is well reviewed in all the groups mentioned above. Personnel Ross Callon is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From internet-drafts@ietf.org Tue Sep 13 05:21:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8321F8AEC; Tue, 13 Sep 2011 05:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnAPBXsRdVB7; Tue, 13 Sep 2011 05:21:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369DE21F8797; Tue, 13 Sep 2011 05:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110913122102.20974.90142.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 05:21:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-csf-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 12:21:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Indication of Client Failure in MPLS-TP Author(s) : Jia He Han Li Elisa Bellagamba Filename : draft-ietf-mpls-tp-csf-02.txt Pages : 12 Date : 2011-09-13 This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) protocol to propagate a client failure indication across an MPLS-TP network in the case that propagation of failure status in the client layer is not supported as required in [RFC5860]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-csf-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-csf-02.txt From amalis@gmail.com Wed Sep 14 18:14:45 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDADA21F8B4A; Wed, 14 Sep 2011 18:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Md2UoYJw+1p; Wed, 14 Sep 2011 18:14:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 262EB21F8AFE; Wed, 14 Sep 2011 18:14:45 -0700 (PDT) Received: by iaby26 with SMTP id y26so773964iab.31 for ; Wed, 14 Sep 2011 18:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=cab8nzwusj8rrZJBczsXZ+BmZnoaE0w/yeAAKKUANjM=; b=ujtfHTLta2eT11fpwi0/FUQO2wJh2HWlWO5S6ChE1KKcAgAzETg8mk9rqHc49Qwq+9 djeBGkf4CCJe7byj2E1tZV48Zyh6OBJ/dByjhFPsxxkACdq4XLQx5fag+bA5eysB/5D9 zz8ifuvB0Aupjqwyd2oTzMPLOBQyuH6pNsilI= Received: by 10.42.159.201 with SMTP id m9mr90017icx.10.1316049415438; Wed, 14 Sep 2011 18:16:55 -0700 (PDT) MIME-Version: 1.0 Sender: amalis@gmail.com Received: by 10.42.225.3 with HTTP; Wed, 14 Sep 2011 18:16:35 -0700 (PDT) From: "Andrew G. Malis" Date: Thu, 15 Sep 2011 09:16:35 +0800 X-Google-Sender-Auth: j6DVoCEZVP5TvAkmTsuSoLMqWeM Message-ID: To: pwe3@ietf.org, mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mpls] New Liaison Statement, "LS320 - Request for promoting the discussion of new path segment monitoring in MPLS-TP" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 01:14:46 -0000 I want bring a new liaison statement from SG15 to the attention of the mpls and pwe3 working groups. While the liaison is for information only, they would appreciate it if people could read the draft https://tools.ietf.org/html/draft-koike-mpls-tp-temporal-hitless-psm-03 and comment on the mpls list (only, please don't cross-post). Please see the liaison file1260.pdf for the background as an introduction to the draft. See below for the URL of the liaison text (file1260). Thanks, Andy On 9/14/2011 23:16 , "Liaison Statement Management Tool" wrote: Title: LS320 - Request for promoting the discussion of new path segment monitoring in MPLS-TP - pwe3 Submission Date: 2011-09-14 URL of the IETF Web page: /liaison/1093/ From: ITU-T SG 15 =A0(Greg Jones ) To: Pseudowire Emulation Edge to Edge (andrew.g.malis@verizon.com, matthew.bocci@alcatel-lucent.com) Cc: yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,pwe3@ietf.org Reponse Contact: tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int Technical Contact: koike.yoshinori@lab.ntt.co.jp,Ghani.Abbas@ericsson.com,huub.van.helvoort@hu awei.com,malcolm.betts@zte.com.cn,Kam.Lam@alcatel-lucent.com Purpose: For information Body: Attachment(s): =A0 =A0LS320 - Request for promoting the discussion of new path segment monitoring in MPLS-TP - body https://datatracker.ietf.org/documents/LIAISON/file1260.pdf =A0 =A0LS320 - Request for promoting the discussion of new path segment monitoring in MPLS-TP - attach https://datatracker.ietf.org/documents/LIAISON/file1261.pdf From scott.mansfield@ericsson.com Thu Sep 15 04:58:54 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C021F8A67; Thu, 15 Sep 2011 04:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8tZb-bh3gkl; Thu, 15 Sep 2011 04:58:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC621F886D; Thu, 15 Sep 2011 04:58:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8FC11eO006015; Thu, 15 Sep 2011 07:01:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 15 Sep 2011 08:00:57 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Thu, 15 Sep 2011 08:00:45 -0400 Thread-Topic: Liaison Statement: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 Thread-Index: AcxznxnxDY7fmYK9SYCe+dKxCwhMgg== Message-ID: 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 Cc: 'ITU-T Liaison coordination' , "pwe3@ietf.org" Subject: [mpls] Liaison Statement: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 11:58:54 -0000 MPLS and PWE3 working groups, Please find the liaison announcing the AAP LC of G.8110.1. As noted below = the document was consented at the February 2011 plenary and is now in last = call. Comments are due by 12 October 2011. ITU-T sector members can acces= s the document on the AAP Announcement site here --> http://www.itu.int/ITU= -T/aap/AAPRecDetails.aspx?AAPSeqNo=3D2281 Comments are submitted by pressi= ng the "Submit Comment" button found on that page. If you are not an ITU-T= sector member and would like to comment on the document (https://datatrack= er.ietf.org/documents/LIAISON/file1263.pdf), please send your comments to t= he mpls list and ISOC as a sector member (regional and other International = Organization) can submit comments. ---------- Liaison Statement: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370= .1=20 Submission Date: 2011-09-14=09 From: ITU-T SG 15 (Greg Jones )=09 To: Multiprotocol Label Switching (rcallon@juniper.net, swallow@cisco.com,= loa@pi.nu)=09 Cc: yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com mpls@ietf.org=09 Response Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int =09 Technical Contact: koike.yoshinori@lab.ntt.co.jp Ghani.Abbas@ericsson.com huub.van.helvoort@huawei.com malcolm.betts@zte.com.cn Kam.Lam@alcatel-lucent.com=09 Purpose: For information=09 Attachments: LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 - = pdf body =20 LS321 - Progress of Recommendation ITU-T G.8110.1/Y.1370.1 - pdf attach =09 Body: Recommendation ITU-T G.8110.1/Y.1370.1, "Architecture of MPLS Transp= ort Profile (MPLS-TP) layer network", was consented at the February meeting of SG15. The last call comment period has recently started and will close on 12 October 2011. Attach: Last Call text of ITU-T G.8110.1/Y.1370.1. =09 Regards, -scott. SCOTT MANSFIELD=20 IETF ITU-T MPLS Liaison Manager Ericsson US BNET DUIB Technology, Network Architecture Mobile +1 (724) 931-9316 scott.mansfield@ericsson.com www.ericsson.com=20 From scott.mansfield@ericsson.com Thu Sep 15 05:09:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFCE21F85BB; Thu, 15 Sep 2011 05:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.476 X-Spam-Level: X-Spam-Status: No, score=-5.476 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llm7weXHqBGK; Thu, 15 Sep 2011 05:09:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0721F893C; Thu, 15 Sep 2011 05:09:41 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8FCBnYM007179; Thu, 15 Sep 2011 07:11:51 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 15 Sep 2011 08:11:46 -0400 From: Scott Mansfield To: "mpls@ietf.org" Date: Thu, 15 Sep 2011 08:11:35 -0400 Thread-Index: AcxzoJ0FpCD1kyujTs2ywLgrbVsmNw== Message-ID: 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 Cc: 'ITU-T Liaison coordination' , "pwe3@ietf.org" Subject: [mpls] (no subject) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 12:09:46 -0000 MPLS and PWE3 working groups, Please find a liaison below announcing the intention to consent G.8121, G.8= 121.1, G.8121.2, and G.8151 at the SG15 Plenary meeting being held December= 2011. This liaison is a call for comment on the documents. Before the 21= st of November 2011 (the deadline for documents going for consent), G.8121,= G.8121.2, and G.8151 need to be updated and ready to submit to the ITU for= consideration at the December plenary. Therefore it is imperative to revi= ew and comment on the document as soon as possible so the comments can be w= orked into the documents before the 21st of November. Liaison Statement: LS322 - MPLS-TP equipment and management -> MPLS=20 Submission Date: 2011-09-14=09 From: ITU-T SG 15 (Greg Jones )=09 To: Multiprotocol Label Switching (rcallon@juniper.net, swallow@cisco.com,= loa@pi.nu)=09 Cc: yoichi.maeda@ttc.or.jp steve.trowbridge@alcatel-lucent.com mpls@ietf.org=09 Response Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int =09 Technical Contact: koike.yoshinori@lab.ntt.co.jp Ghani.Abbas@ericsson.com huub.van.helvoort@huawei.com malcolm.betts@zte.com.cn Kam.Lam@alcatel-lucent.com=09 Purpose: For comment=09 Deadline: 2011-11-21 Action Needed =09 Attachments: LS322 - MPLS-TP equipment and management - pdf body =20 LS322 - MPLS-TP equipment and management -> Attach1 =20 LS322 - MPLS-TP equipment and management -> Attach2 =20 LS322 - MPLS-TP equipment and management -> Attach3 =20 LS322 - MPLS-TP equipment and management -> Attach4 =09 Body: Q9/15 is continuing to develop Recommendations ITU-T G.8121 "Characteristics of MPLS-TP equipment functional blocks", ITU-T G.8121.1 "Characteristics of MPLS-TP equipment functional blocks supporting G.8113.1/Y.1372.1" and ITU-T G.8121.2 "Characteristics of MPLS-TP equipment functional blocks supporting G.8113.2/Y.1372.2".=20 Q14/15 is continuing to develop Recommendation ITU-T G.8151 "Management aspects of the MPLS-TP network element". Since we intend to consent these four draft Recommendations at the December 2011 SG15 meeting, we request your comments on these documents. Attach: WD44r6, WD45r1, WD46r3, WD11r2. Regards, -scott. SCOTT MANSFIELD IETF ITU-T MPLS Liaison Manager Ericsson US BNET DUIB Technology, Network Architecture Mobile +1 (724) 931-9316 scott.mansfield@ericsson.com=20 From gregimirsky@gmail.com Thu Sep 15 10:13:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2021F88A0; Thu, 15 Sep 2011 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOoMnX2C0E2Z; Thu, 15 Sep 2011 10:13:02 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F921F8558; Thu, 15 Sep 2011 10:13:02 -0700 (PDT) Received: by gxk9 with SMTP id 9so3291310gxk.40 for ; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VK1j4kprTSPE/srMnLNRXgPxf7zSjcl9V3E3ZM9wxyo=; b=GuVzwQeWdNlITOLm6t4kDMojsHBULuohf+Ql4QhnvzMPxysx8l7ohEcSPZEuiK8vI2 PJgaG48GoZ2vGdrSxRamDOI1mTO/xgaXo+ggqINMAYUEifCwrH9/SNPwHtX6iRkyXSqR wDVUfmdIvHaJl84DA9q90wurCP1Kl0xJLyYdI= MIME-Version: 1.0 Received: by 10.52.66.70 with SMTP id d6mr357612vdt.351.1316106914494; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) Received: by 10.52.158.73 with HTTP; Thu, 15 Sep 2011 10:15:14 -0700 (PDT) In-Reply-To: References: <339AB015E0D8994084533A6EE52303B0A49C28F1@USNAVSXCHMBSB2.ndc.alcatel-lucent.com> Date: Thu, 15 Sep 2011 10:15:14 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , mpls@ietf.org Subject: Re: [mpls] implementation of BFD in passive mode? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 17:13:03 -0000 Dear Sasha, I believe that changing timers through taking session into Admin Down is compliant with RFC 5880. It is mentioned in parameter update method in MPLS-TP CC-CV-RDI. Section 3.7.1: In the rare circumstance where an operator has a reason to further change session parameters, beyond the initial migration from default values; poll/final discipline can be used with the caveat that a peer implementation may consider a session change unacceptable and/or bring the BFD session down via the use of the ADMIN DOWN state. Regards, Greg On Thu, Sep 15, 2011 at 12:59 AM, Alexander Vainshtein wrote: > Jinny, > > Lots of thanks for a prompt response. > > > > I am not sure that changing the parameters in AdminDown state of the sess= ion > is compliant with 5880. > > Please note that the fragment I=92ve quoted refers to the situation when = the > BFD session is not Up, =A0which clearly includes AdminDown. > > Note also that the session may go Down for natural reasons (if they were > not, why should we bother to set them up anyway?), and should resume thei= r > original fast operation once they come up back. > > > > Last but not least, I am aware of at least two implementations that use B= FD > HW accelerators (what you call the fast path ASICs) to support intervals = and > timers in the millisecond range combined with 5880-compliant Final/Poll > processing in SW. The protocol has been specifically designed to facilita= te > this kind of HW/SW interaction IMO. > > > > Regards, > > =A0=A0=A0=A0 Sasha > > > > From: binny jeshan [mailto:binnyjeshan@gmail.com] > Sent: Thursday, September 15, 2011 8:31 AM > To: Alexander Vainshtein > Cc: rtg-bfd@ietf.org; Robert Rennison > > Subject: Re: implementation of BFD in passive mode? > > > > Hi Sasha, > > > > Your points are correct. In the same section, i find the below aspects al= so. > > > > > > > > The time values used to determine BFD packet transmission intervals > > =A0=A0 and the session Detection Time may be modified at any time without > > =A0=A0 affecting the state of the session. =A0When the timer parameters a= re > > =A0=A0 changed for any reason, the requirements of this section apply. > > > > > > > > If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, > > =A0=A0 the actual transmission interval used MUST NOT change until the Po= ll > > =A0=A0 Sequence described above has terminated.=A0 This is to ensure that= the > > =A0=A0 remote system updates its Detection Time before the transmission > > =A0=A0 interval increases. > > > > Changing timers can be done in two ways as per my understanding. > > > > 1. Router A operator can initiate the timing change through poll request = and > at the end of the poll sequence the new timer values are applied. > 2. Route A and B can bring the session Admin Down, Change its timers and > start-off again.. > > > > Slow interval can be used in below cases as per my understanding. > > 1. When session starts up in Down state > > 2. When session goes down due to any defects > > > > When you start a session, you need not do a polling, since the timer > negotiation section=A06.8.2,=A0will be used, and not the polling. > > Polling will be used only when timer is 'modified'. > > > > Why some routers may not implement Polling? > > One reason could be that in cases if BFD is accelerated in a Fast Path AS= IC > (for sub-second interval configurations), it becomes hard to change > parameters in run-time using polling without affecting the running sessio= n. > This is due to implementation limitations at hardware level. In such case= , > these routers allow polling for sessions running at software. > > > > Thanks for the question.. > > > > Regards, > > Binny Jeshan > > > > > > On 15 September 2011 10:10, Alexander Vainshtein > wrote: > > Binny, > > You say that some routers may not implement the poll-final sequence for B= FD > and require bringing down their BFD sessions in order to change the sessi= on > parameters. > > > > I wonder how this is supposed to be compatible with the following in RFC > 5880: > > > > From Section 6.2 "BFD State Machine": > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 +--+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 |=A0 | UP, ADMIN DOWN, TIMER > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0= =A0=A0=A0=A0|=A0 V > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DOWN=A0 +---= ---+=A0 INIT > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------|=A0=A0=A0=A0=A0 |--= ----------+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 | DOWN |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +-------->|=A0=A0=A0=A0=A0 |= <--------+=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 +-= -----+=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | > > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ADMIN DOWN,|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |ADMIN DOWN,=A0=A0=A0=A0=A0= =A0=A0=A0=A0 DOWN,|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |TIMER=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 TIMER|=A0 | > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 V=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 V > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+ > > =A0=A0=A0=A0=A0=A0 +----|=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |----+ > > =A0=A0 DOWN|=A0=A0=A0 | INIT |--------------------->|=A0 UP=A0 |=A0=A0=A0= |INIT, UP > > =A0=A0=A0=A0=A0=A0 +--->|=A0=A0=A0=A0=A0 | INIT, UP=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 |<---+ > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------+ > > > > > > From Section 6.8.3 "Timer Manipulation": > > > > =A0=A0 When bfd.SessionState is not Up, the system MUST set > > =A0=A0 bfd.DesiredMinTxInterval to a value of not less than one second > > =A0=A0 (1,000,000 microseconds).=A0 This is intended to ensure that the > > =A0=A0 bandwidth consumed by BFD sessions that are not Up is negligible, > > =A0=A0 particularly in the case where a neighbor may not be running BFD. > > > > > > To me these two fragments mean that BFD sessions are always started as > "slow" (i.e., not faster than 1 packet/second), revert to "slow" every ti= me > they go=A0down,=A0and can only progress to the desired rate via the Final= /Poll > negotiation. > > > > Did I miss something substantial? > > > > Regards, > > =A0=A0=A0=A0 Sasha > > ________________________________ > > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of bi= nny > jeshan [binnyjeshan@gmail.com] > Sent: Thursday, September 15, 2011 5:25 AM > To: Das, Bevan N (Bevan) > Cc: rtg-bfd@ietf.org > Subject: Re: implementation of BFD in passive mode? > > Hi Bevan, > > > > As per my understanding about BFD in passive mode, its should be implemen= ted > in all routes supporting 5880, except when explicitly passive mode is sai= d > to be not supported. I believe the Spirent Test Center BFD base package h= as > already implemented this and you can test your SUT using it. You can test > the negative=A0scenario passive-passive too. > > > > The same applies for Poll-final sequence also. Some routers may implement > this, whereas some may not. They require to bring down the session and ed= it > the BFD session parameters. > > > > Hope this helps you. > > > > Thanks, > > Binny Jeshan. > > On 15 September 2011 01:52, Das, Bevan N (Bevan) > wrote: > > Hi, > > I am a software tester in Alcatel-Lucent, and part of my current work is > verifying BFD interoperability of one of our products with routers. > > In reading through RFC 5880 and in searching through web guides for BFD, = I > have seen two modes possible for BFD: =A0"active" and "passive". =A0Howev= er, all > the routers that I have worked with up until now only implement "active" > mode. =A0Are there any implementations of BFD that actually use "passive" > mode? =A0In other words, am I safe in just verifying interoperability wit= h > routers in "active" mode? > > Thank you for your time, > > Bevan Das > bevan.das@alcatel-lucent.com > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. > > > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform u= s > by e-mail, phone or fax, and then delete the original and all copies > thereof. From internet-drafts@ietf.org Thu Sep 15 19:53:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87E711E80B0; Thu, 15 Sep 2011 19:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRnJiJRg2cMZ; Thu, 15 Sep 2011 19:53:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D93B21F8A7A; Thu, 15 Sep 2011 19:53:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110916025310.12629.41273.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 19:53:10 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 02:53:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-05.txt Pages : 13 Date : 2011-09-15 This document specifies one function and describes a second function which are applicable to MPLS transport networks. The first function enables an operator to lock a transport path while the second enables an operator to set, in loopback, a given node along a transport path. This document also defines the extension to MPLS operation, administration, and maintenance (OAM) to perform the lock function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-05.txt From eric.gray@ericsson.com Fri Sep 16 06:00:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9B21F8BEB for ; Fri, 16 Sep 2011 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ODAKVpQPbwT for ; Fri, 16 Sep 2011 06:00:37 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 219C621F8BBC for ; Fri, 16 Sep 2011 06:00:37 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8GD2mKq017917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Sep 2011 08:02:49 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 16 Sep 2011 09:02:48 -0400 From: Eric Gray To: "'Sami Boutros'" Date: Fri, 16 Sep 2011 09:02:46 -0400 Thread-Topic: [mpls] draft-ietf-mpls-tp-li-lb-05.txt Thread-Index: Acxpm26DifB9XDfnRqS3OneUgv063QKuUTEwAAKpT3A= Message-ID: 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 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-li-lb-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 13:00:38 -0000 Sami, Some minor comments on the current (9/15/2011) version. In the second para of the intro, "defines the extensions" should be "specifies extensions"... _________________________________________________________________ First para, page 3, a space needs to be added after "Pseudowires" and before the open paren. In the same para, "dedicated to the transport path" is redundant and should be removed. _________________________________________________________________ Next para, "tight coordination" should be "timely coordination." _________________________________________________________________ Sixth para, page 3, this para should be broken up into multiple paragraphs. The following sentence should be replaced with text similar to the suggested replacement text below, as the start of a second paragraph: Replace -=20 "The Loopback is a function that enables a MEP to request a MEP=20 or a MIP to enter a loopback state." With -=20 "Loopback is a function that enables a receiving MEP to return=20 traffic to the sending MEP, when in the loopback state." The sentence in the current para that starts with "Note that ..." should probably be in a separate paragraph. _________________________________________________________________ Next para, the sentence that starts with "It should be noted ..." should be in a separate paragraph. As it now stands, however, this setence has a few issues. I cannot parse the portion that says "applied to data plane loopback points that can resides on ..."=20 If the intent is to say that the loopback points can be part of interfaces that are separate from applicable MEP(s) or MIP(s), then "that can resides" should be replaced with "residing"... _________________________________________________________________ Next para, change the paragraph to read something along the lines of: "For data plane loopback at an intermediate point in a transport path, the loopback needs to be configured to occur at either the ingress or egress interface. This is done using management." Note that loopback at both interfaces is not reasonable. _________________________________________________________________ Next para, "insure" should be "ensure"... _________________________________________________________________ There is an extra line-feed between the last paragraph and the next one (starting with "The Lock function ..."). _________________________________________________________________ Next para, "tight coordination" should be "timely coordination" (this should be done generally, as "tight" is an ambiguous term. For instance, I find coordination difficult when I am "tight.") _________________________________________________________________ Section 3.2, please try to keep the message format from spanning multiple pages. _________________________________________________________________ Section 4, second para: "sender" should be changed to "sending"=20 in both instances. While the MEP in this case is originating test traffic, it is not exclusively a "sender." _________________________________________________________________ Section 5.1, first para: change to read along the lines of - "Lock is used to request a MEP to take a transport path out of=20 service for administrative reasons. For example, Lock can be used to allow some form of maintenance to be done for a transport path." _________________________________________________________________ Next para: change the first sentence to read as follows - "When performing Lock, in response to a management request, the MEP MUST take the transport path out of service and MUST begin sending LI messages periodically to the remote MEP at the remote end of the transport path." _________________________________________________________________ The next two paragraphs should be in reverse order (i.e. - talk first about taking the transport path out of service and then about keeping it out of service). _________________________________________________________________ Change the next para to read: "A MEP is locked either Lock was requested by management (and - as a result it is sending LI messages), or it is receiving LI messages from the remote MEP." Note that "by management" is more general (and therefore more accurate) that "by NMS" - since Lock may be requested by CLI, or as a result of pushing a control panel button. In general, anywhere where we currently use the term "NMS", we should verify that the meaning is not broader than this. _________________________________________________________________ Section 5.2, second paragraph: it is not possible to unlock a MEP via the control plane. If the MEP stops receiving LI, and is itself not administratively in a Lock state, then the MEP is required to unlock the transport path, putting it in service. Delete "or control" from the first sentence in this paragraph. _________________________________________________________________ Next para, "would" should be "SHALL" (i.e. - "A MEP SHALL unlock ..."). _________________________________________________________________ Next para, "NMS" should be "management" - also "no LI OAM=20 messages are received" should be "no LI messages have been received in the most recent 3.5*(Refresh Timer) seconds." _________________________________________________________________ Section 5.3, delete "first" from the text in this section. _________________________________________________________________ Section 5.5, change "Management system" to "management" (this is also something to consider doing generally, for the same reason as was described for "NMS"). _________________________________________________________________ Next para, change "event is logged. Processing ceases." to "event is logged and processing of the LI message ceases." This is=20 necessary to ensure that 1) we use the same preconditions for ceasing processing as we use for logging the event, and 2) so it is unambiguous as to what it is that we are to cease processing. The last sentence can be omitted as this is implicit in that we have not indicated that processing should cease. _________________________________________________________________ Section 5.6, change "Management system" to "management"... _________________________________________________________________ Next para is not correct. Please replace this paragraph with=20 text along the lines of: "After both MEP A and MEP D have not received an LI message in at least 3.5 times the refresh timer, and each MEP has not=20 received a new management request to Lock the transport path, both MEPs SHALL put the transport path back in service." _________________________________________________________________ Section 6, second para - to reduce the potential for ambiguity, replace "those two documents" with "[4] and [7]." _________________________________________________________________ For IANA considerations, we refer to the value of the "to be determined" (assigned by IANA) value as "0xHH"; in the IANA Considerations section, the value is represented as "0xHHHH"=20 - we should be consistent in using this representation. _________________________________________________________________ -- Eric= From ietfc@btconnect.com Fri Sep 16 09:57:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805E021F8BA6 for ; Fri, 16 Sep 2011 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV2+m2SQFIjg for ; Fri, 16 Sep 2011 09:57:56 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 806A021F8B9C for ; Fri, 16 Sep 2011 09:57:55 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr13.btconnect.com with SMTP id EKA26521; Fri, 16 Sep 2011 18:00:08 +0100 (BST) Message-ID: <01d301cc7489$20e32380$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <20110711172028.4572.63103.idtracker@ietfa.amsl.com> Date: Fri, 16 Sep 2011 17:54:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E738097.00F6, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.16.154215:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __INT_PROD_LOC, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E738098.0166,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 16:57:56 -0000 I think that Section 3.3, IANA Considerations, needs more attention in this I-D. It would help IANA if you told them - which registry the new TLV is part of - named the new sub-registry (and the sub-sub registry?) and clarified the status of Section 4 which, while not labelled as IANA Considerations, would appear to be instructions for IANA to act upon. And while I am excited by the prospect of liveliness in BFD in Section 1, I suspect that liveness is intended. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Monday, July 11, 2011 7:20 PM Subject: I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping > Author(s) : Elisa Bellagamba > Loa Andersson > Pontus Skoldstrom > Dave Ward > John Drake > Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02.txt > Pages : 21 > Date : 2011-07-11 > > This specification describes the configuration of pro-active MPLS-TP > Operations, Administration, and Maintenance (OAM) Functions for a > given LSP using a set of TLVs that are carried by the LSP Ping > protocol > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02 .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-02. txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wwwrun@rfc-editor.org Sun Sep 18 10:28:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D921F84BC; Sun, 18 Sep 2011 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F3ATyGN-3gJ; Sun, 18 Sep 2011 10:28:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7289421F84CC; Sun, 18 Sep 2011 10:28:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8A57898C22D; Sun, 18 Sep 2011 10:31:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110918173113.8A57898C22D@rfc-editor.org> Date: Sun, 18 Sep 2011 10:31:13 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6374 on Packet Loss and Delay Measurement for MPLS Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 17:28:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6374 Title: Packet Loss and Delay Measurement for MPLS Networks Author: D. Frost, S. Bryant Status: Standards Track Stream: IETF Date: September 2011 Mailbox: danfrost@cisco.com, stbryant@cisco.com Pages: 52 Characters: 123462 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-loss-delay-04.txt URL: http://www.rfc-editor.org/rfc/rfc6374.txt Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching 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 Association Management Solutions, LLC From wwwrun@rfc-editor.org Sun Sep 18 10:29:04 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05AA21F869E; Sun, 18 Sep 2011 10:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPtqoIVFeRmG; Sun, 18 Sep 2011 10:29:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B421F8677; Sun, 18 Sep 2011 10:29:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D60F98C268; Sun, 18 Sep 2011 10:31:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110918173124.4D60F98C268@rfc-editor.org> Date: Sun, 18 Sep 2011 10:31:24 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6375 on A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 17:29:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6375 Title: A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks Author: D. Frost, Ed., S. Bryant, Ed. Status: Informational Stream: IETF Date: September 2011 Mailbox: danfrost@cisco.com, stbryant@cisco.com Pages: 5 Characters: 10026 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-loss-delay-profile-04.txt URL: http://www.rfc-editor.org/rfc/rfc6375.txt Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374. The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC From mach.chen@huawei.com Sun Sep 18 18:27:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E87C21F8B01 for ; Sun, 18 Sep 2011 18:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.187 X-Spam-Level: X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6m2nlewn3p6 for ; Sun, 18 Sep 2011 18:27:20 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E95A421F8AF4 for ; Sun, 18 Sep 2011 18:27:19 -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 <0LRQ006ETXG54C@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 19 Sep 2011 09:28:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRQ0074MXG5HD@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 19 Sep 2011 09:28:53 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADT37588; Mon, 19 Sep 2011 09:28:52 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 09:28:50 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.219]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 09:28:49 +0800 Date: Mon, 19 Sep 2011 01:28:48 +0000 From: Mach Chen In-reply-to: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> X-Originating-IP: [10.110.98.47] To: "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt Thread-index: AQHMXIsBs9gYS7rVVUqSH/T+evUCOpVUGi/g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> Cc: "ppan@infinera.com" Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 01:27:20 -0000 Hi, We submitted a new draft that updates RFC4379 to explicitly constraint the existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6 scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where the Sender's and Receiver's IP addresses are IPv6 addresses.) We'd appreciate that you could spend some time to read the draft (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your comments! Thanks, Mach ----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, August 17, 2011 11:08 AM > To: Mach Chen > Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; cpignata@cisco.com > Subject: New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > Filename: draft-chen-mpls-ipv6-pw-lsp-ping > Revision: 01 > Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > Creation date: 2011-08-16 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > and Traceroute mechanisms are commonly used to detect and isolate > data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > The PW LSP Ping and Traceroute elements, however, are not specified > for IPv6 address usage. > > Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > the LSP Ping and Traceroute mechanism are implicitly defined only for > IPv4 Provider Edge (PEs) routers, and are not applicable for the case > where PEs use IPv6 addresses. There is, additionally, a degree of > potential ambiguity in the specification of these sub-TLVs since the > address family is not explicitly specified but it is to be inferred > from the sub-TLV length. > > This document updates RFC4379 to explicitly constraint these existing > PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > are IPv6 addresses.) This is done by defining two new LSP Ping sub- > TLVs for IPv6 Pseudowire FECs. > > > > > > The IETF Secretariat From ietfc@btconnect.com Tue Sep 20 02:35:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86F21F8B86 for ; Tue, 20 Sep 2011 02:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB17-jdWSi98 for ; Tue, 20 Sep 2011 02:35:59 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8965D21F8B74 for ; Tue, 20 Sep 2011 02:35:57 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr09.btconnect.com with SMTP id EMV83261; Tue, 20 Sep 2011 10:37:58 +0100 (BST) Message-ID: <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mach Chen" , References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 10:28:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E785EF5.0001, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.20.83315:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, __CP_URI_IN_BODY, __C230066_P2, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E785EF7.00CC,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: ppan@infinera.com Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 09:35:59 -0000 ---- Original Message ----- From: "Mach Chen" To: Cc: Sent: Monday, September 19, 2011 3:28 AM > Hi, > > We submitted a new draft that updates RFC4379 to explicitly constraint the existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6 scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where the Sender's and Receiver's IP addresses are IPv6 addresses.) > > We'd appreciate that you could spend some time to read the draft (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your comments! Mach It looks ok, but I sort of get worried when I have to spend too much time working out the details. Specifically, the IANA registries that RFC4379 created have been given names by IANA, even though RFC4379 itself did not do so, so I think that this I-D should use these names. The registry in question, MPLS - LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making early allocations to it so it is quite a big and volatile registry. Technically this is not a problem but it sort of worries me. This I-D is in a sense putting right a lack of foresight in RFC4379, nailing down what RFC4379 might have nailed down, so is there anything still missing that needs nailing down? I cannot see anything but think I am probably missing something:-( Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you are updating three. TLV Type21 has 19 sub-TLVs which closely parallel those of Type 1 which you are not updating (ok there is another I-D that should do so but have the authors of that I-D - namely you! - any thoughts on this?). Should the registry be looked at more widely to see if it can better be rationalised? Tom Petch > > Thanks, > Mach > > ----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, August 17, 2011 11:08 AM > > To: Mach Chen > > Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; cpignata@cisco.com > > Subject: New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > > > A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF repository. > > > > Filename: draft-chen-mpls-ipv6-pw-lsp-ping > > Revision: 01 > > Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > > Creation date: 2011-08-16 > > WG ID: Individual Submission > > Number of pages: 9 > > > > Abstract: > > Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > > and Traceroute mechanisms are commonly used to detect and isolate > > data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > > The PW LSP Ping and Traceroute elements, however, are not specified > > for IPv6 address usage. > > > > Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > > the LSP Ping and Traceroute mechanism are implicitly defined only for > > IPv4 Provider Edge (PEs) routers, and are not applicable for the case > > where PEs use IPv6 addresses. There is, additionally, a degree of > > potential ambiguity in the specification of these sub-TLVs since the > > address family is not explicitly specified but it is to be inferred > > from the sub-TLV length. > > > > This document updates RFC4379 to explicitly constraint these existing > > PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > > Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > > the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > > are IPv6 addresses.) This is done by defining two new LSP Ping sub- > > TLVs for IPv6 Pseudowire FECs. > > > > > > > > > > > > The IETF Secretariat > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From huanglu@chinamobile.com Tue Sep 20 03:47:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3021F8C22 for ; Tue, 20 Sep 2011 03:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.929 X-Spam-Level: **** X-Spam-Status: No, score=4.929 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_50=0.001, FR_IMPORT_CSS=1.889, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aONb8tKMn4kr for ; Tue, 20 Sep 2011 03:47:56 -0700 (PDT) Received: from hqmta.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E821F8C28 for ; Tue, 20 Sep 2011 03:47:55 -0700 (PDT) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id 64F942E2180; Tue, 20 Sep 2011 18:50:18 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id 44457176ED8; Tue, 20 Sep 2011 18:50:18 +0800 (CST) Received: from PC-20110530UGBE ([10.2.0.242]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011092018501688-22481 ; Tue, 20 Sep 2011 18:50:16 +0800 Date: Tue, 20 Sep 2011 18:50:15 +0800 From: "Huang Lu" To: "daniel" , "mpls" Message-ID: <201109201850146349588@chinamobile.com> Organization: ChinaMobile X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-20 18:50:16, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-20 18:50:17, Serialize complete at 2011-09-20 18:50:17 Content-Type: multipart/alternative; boundary="=====003_Dragon725133111251_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18396.006 X-TM-AS-Result: No--10.741-7.0-31-10 X-imss-scan-details: No--10.741-7.0-31-10;No--10.741-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: lichenyj , 'Boris Zhang' , "quintin.zhao" , Li Lianyuan Subject: Re: [mpls] draft-li-mpls-mt-applicability-requirement-02 Comments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huanglu@chinamobile.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 10:47:57 -0000 This is a multi-part message in MIME format. --=====003_Dragon725133111251_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Hi Dan, Thanks for your review and comments. We will need a few days to review your suggestions then we will respond to specific points as needed. 2011-09-16 Best Regards! Lu Huang Research Institute of China Mobile Floor 11, Door 2, Dacheng Plaza No.28 Xuanwumen West Ave, Xuanwu District Beijing 100053, China Phone: +86 10-15801696688-3287 Mobile: +86 13810820540 Email: huanglu@chinamobile.com --=====003_Dragon725133111251_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+QGltcG9ydCB1cmwoIEM6 XFVzZXJzXEFkbWluaXN0cmF0b3JcQXBwRGF0YVxSb2FtaW5nXEZveG1haWxcRm94VGVtcDYuNSg0 OSlcXHNjcm9sbGJhci5jc3MgKTsNCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD1nYjIzMTIiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1H RU5FUkFUT1IgY29udGVudD0iTVNIVE1MIDkuMDAuODExMi4xNjQzNCI+PExJTksgcmVsPXN0eWxl c2hlZXQgDQpocmVmPSJCTE9DS1FVT1RFe21hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRvbTog MHB4OyBtYXJnaW4tTGVmdDogMmVtfSI+PC9IRUFEPg0KPEJPRFkgc3R5bGU9Ik1BUkdJTjogMTBw eDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7IEZPTlQtU0laRTogMTBwdCI+DQo8RElWPjxGT05UIHNp emU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPkhpJm5ic3A7RGFuLCZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+VGhhbmtzJm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNwO3JldmlldyZu YnNwO2FuZCZuYnNwO2NvbW1lbnRzLiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+V2UmbmJzcDt3aWxsJm5ic3A7bmVlZCZuYnNwO2EmbmJzcDtmZXcmbmJzcDtkYXlzJm5ic3A7 dG8mbmJzcDtyZXZpZXcmbmJzcDt5b3VyJm5ic3A7c3VnZ2VzdGlvbnMmbmJzcDt0aGVuJm5ic3A7 d2UmbmJzcDt3aWxsJm5ic3A7cmVzcG9uZCZuYnNwO3RvJm5ic3A7c3BlY2lmaWMmbmJzcDtwb2lu dHMmbmJzcDthcyZuYnNwO25lZWRlZC48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRk9OVD48 Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVYg YWxpZ249bGVmdD48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMS0w OS0xNiANCjwvRk9OVD48L0RJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxl PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCg0KPERJVj48 Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+DQo8RElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDsgDQo8RElWPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+QmVzdCBSZWdhcmRzITxCUj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9MiBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTIgZmFjZT3LzszlPkx1IEh1YW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT3LzszlPlJlc2VhcmNoIEluc3RpdHV0ZSBvZiBDaGluYSBNb2JpbGU8QlI+Rmxvb3IgMTEs IERvb3IgDQoyLCBEYWNoZW5nIFBsYXphPEJSPk5vLjI4IFh1YW53dW1lbiBXZXN0IEF2ZSwgWHVh bnd1IERpc3RyaWN0PEJSPkJlaWppbmcgMTAwMDUzLCANCkNoaW5hPEJSPlBob25lOiZuYnNwOyAr ODYgMTAtMTU4MDE2OTY2ODgtMzI4NzxCUj5Nb2JpbGU6ICs4NiANCjEzODEwODIwNTQwPEJSPkVt YWlsOiZuYnNwOyA8L0ZPTlQ+PEEgDQpocmVmPSJtYWlsdG86aHVhbmdsdUBjaGluYW1vYmlsZS5j b20iPjxGT05UIHNpemU9MiANCmZhY2U9y87M5T5odWFuZ2x1QGNoaW5hbW9iaWxlLmNvbTwvRk9O VD48L0E+PC9ESVY+PC9ESVY+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9CT0RZ PjwvSFRNTD4NCg== --=====003_Dragon725133111251_=====-- From cpignata@cisco.com Tue Sep 20 05:27:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6041521F8C0C for ; Tue, 20 Sep 2011 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+aqz5CdfgVg for ; Tue, 20 Sep 2011 05:27:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5921F8BA8 for ; Tue, 20 Sep 2011 05:27:42 -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 p8KCTVjd022945; Tue, 20 Sep 2011 08:29:31 -0400 (EDT) Received: from [64.103.236.113] ([64.103.236.113]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8KCTREJ024178; Tue, 20 Sep 2011 08:29:29 -0400 (EDT) Message-ID: <4E788726.3050008@cisco.com> Date: Tue, 20 Sep 2011 17:59:26 +0530 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "t.petch" References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> In-Reply-To: <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.3.1 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: mpls@ietf.org, ppan@infinera.com Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 12:27:43 -0000 Tom, Many thanks for the comments, please see inline. On 9/20/2011 1:58 PM, t.petch wrote: > ---- Original Message ----- > From: "Mach Chen" > To: > Cc: > Sent: Monday, September 19, 2011 3:28 AM >> Hi, >> >> We submitted a new draft that updates RFC4379 to explicitly constraint the > existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping > (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6 > scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where > the Sender's and Receiver's IP addresses are IPv6 addresses.) >> >> We'd appreciate that you could spend some time to read the draft > (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your > comments! > > Mach > > It looks ok, but I sort of get worried when I have to spend too much time > working out the details. Specifically, the IANA registries that RFC4379 created > have been given names by IANA, even though RFC4379 itself did not do so, so I > think that this I-D should use these names. The registry in question, MPLS - > LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making early > allocations to it so it is quite a big and volatile registry. This is a good point, and frankly I'm not sure why we didn't -- I meant to. We can add "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" "TLVs and sub-TLVs Registry", and a pointer to (although it would be changed to ). Thanks. > > Technically this is not a problem but it sort of worries me. This I-D is in a > sense putting right a lack of foresight in RFC4379, nailing down what RFC4379 > might have nailed down, so is there anything still missing that needs nailing > down? I cannot see anything but think I am probably missing something:-( > Please note that this I-D is not a cleanup exercise for RFC4379; it's purposely narrowly focused to LSP Ping for IPv6 PW FECs. > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel those of > Type 1 which you are not updating (ok there is another I-D that should do so but > have the authors of that I-D - namely you! - any thoughts on this?). I am not an author of this I-D, draft-ietf-mpls-return-path-specified-lsp-ping, but my sense is that this I-D draft-ietf-mpls-return-path-specified-lsp-ping should point to draft-chen-mpls-ipv6-pw-lsp-ping and figure out TLV 21. This is because TLV 21 is defined by draft-ietf-mpls-return-path-specified-lsp-ping, and compounded by the fact that these are temporary allocations. > Should the > registry be looked at more widely to see if it can better be rationalised? I think you just did, mostly -- note that a cleanup or rationalization of this registry is not a goal of this I-D. Thanks, -- Carlos. > > Tom Petch > >> >> Thanks, >> Mach >> >> ----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Wednesday, August 17, 2011 11:08 AM >>> To: Mach Chen >>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; cpignata@cisco.com >>> Subject: New Version Notification for > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt >>> >>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been >>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF > repository. >>> >>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping >>> Revision: 01 >>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs >>> Creation date: 2011-08-16 >>> WG ID: Individual Submission >>> Number of pages: 9 >>> >>> Abstract: >>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping >>> and Traceroute mechanisms are commonly used to detect and isolate >>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. >>> The PW LSP Ping and Traceroute elements, however, are not specified >>> for IPv6 address usage. >>> >>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in >>> the LSP Ping and Traceroute mechanism are implicitly defined only for >>> IPv4 Provider Edge (PEs) routers, and are not applicable for the case >>> where PEs use IPv6 addresses. There is, additionally, a degree of >>> potential ambiguity in the specification of these sub-TLVs since the >>> address family is not explicitly specified but it is to be inferred >>> from the sub-TLV length. >>> >>> This document updates RFC4379 to explicitly constraint these existing >>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP >>> Ping to the IPv6 scenario where an IPv6 LDP session is used to signal >>> the Pseudowire (i.e., where the Sender's and Receiver's IP addresses >>> are IPv6 addresses.) This is done by defining two new LSP Ping sub- >>> TLVs for IPv6 Pseudowire FECs. >>> >>> >>> >>> >>> >>> The IETF Secretariat >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From ietfc@btconnect.com Tue Sep 20 08:23:03 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF9321F8C6A for ; Tue, 20 Sep 2011 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wgveCUZSjMD for ; Tue, 20 Sep 2011 08:23:02 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 9035D21F8C5D for ; Tue, 20 Sep 2011 08:23:00 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr13.btconnect.com with SMTP id ELE14679; Tue, 20 Sep 2011 16:25:12 +0100 (BST) Message-ID: <010801cc77a0$84b79c00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Carlos Pignataro" References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> <4E788726.3050008@cisco.com> Date: Tue, 20 Sep 2011 16:20:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E78B058.0013, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.20.143620:17:7.944, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __STOCK_PHRASE_24, __CP_URI_IN_BODY, __C230066_P2, BODY_SIZE_6000_6999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E78B05C.00B5,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org, ppan@infinera.com Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:23:03 -0000 ----- Original Message ----- From: "Carlos Pignataro" To: "t.petch" Cc: "Mach Chen" ; ; Sent: Tuesday, September 20, 2011 2:29 PM > Tom, > > Many thanks for the comments, please see inline. > > On 9/20/2011 1:58 PM, t.petch wrote: > > ---- Original Message ----- > > From: "Mach Chen" > > To: > > Cc: > > Sent: Monday, September 19, 2011 3:28 AM > >> Hi, > >> > >> We submitted a new draft that updates RFC4379 to explicitly constraint the > > existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP Ping > > (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the IPv6 > > scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., where > > the Sender's and Receiver's IP addresses are IPv6 addresses.) > >> > >> We'd appreciate that you could spend some time to read the draft > > (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give your > > comments! > > > > Mach > > > > It looks ok, but I sort of get worried when I have to spend too much time > > working out the details. Specifically, the IANA registries that RFC4379 created > > have been given names by IANA, even though RFC4379 itself did not do so, so I > > think that this I-D should use these names. The registry in question, MPLS - > > LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making early > > allocations to it so it is quite a big and volatile registry. > > This is a good point, and frankly I'm not sure why we didn't -- I meant > to. We can add "Multi-Protocol Label Switching (MPLS) Label Switched > Paths (LSPs) Ping Parameters" "TLVs and sub-TLVs Registry", and a > pointer to > (although it would be changed to ). Thanks. > > > > > Technically this is not a problem but it sort of worries me. This I-D is in a > > sense putting right a lack of foresight in RFC4379, nailing down what RFC4379 > > might have nailed down, so is there anything still missing that needs nailing > > down? I cannot see anything but think I am probably missing something:-( > > > > Please note that this I-D is not a cleanup exercise for RFC4379; it's > purposely narrowly focused to LSP Ping for IPv6 PW FECs. Yup, I understand that, and that is my concern, that we are getting to the point where a cleanup may be needed. With the benefit of (wonderful) hindsight, how much better it would be to have a range of sub-TLVs, say 1-63, that are common across TLVs, and another, say 128-191 that are unique to a TLV. Reading draft-ietf-mpls-return-path-specified-lsp-ping makes the need for that clear, but, too late. At the moment, RFC4379 is clear; "The number spaces for the sub-TLVs of various TLVs are independent." which is a problem for draft-ietf-mpls-return-path-specified-lsp-ping and not for you; sigh. But I think that it does behove authors like yourself to keep an eye on, e.g., draft-ietf-mpls-return-path-specified-lsp-ping to see if it needs the same actions as you are proposing, and since they have an Editor in common ( I was referring to M. Chen(Ed.) rather than yourself), hopefully that will be the case. Tom Petch > > > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you > > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel those of > > Type 1 which you are not updating (ok there is another I-D that should do so but > > have the authors of that I-D - namely you! - any thoughts on this?). > > I am not an author of this I-D, > draft-ietf-mpls-return-path-specified-lsp-ping, but my sense is that > this I-D draft-ietf-mpls-return-path-specified-lsp-ping should point to > draft-chen-mpls-ipv6-pw-lsp-ping and figure out TLV 21. This is because > TLV 21 is defined by draft-ietf-mpls-return-path-specified-lsp-ping, and > compounded by the fact that these are temporary allocations. > > > Should the > > registry be looked at more widely to see if it can better be rationalised? > > I think you just did, mostly -- note that a cleanup or rationalization > of this registry is not a goal of this I-D. > > Thanks, > > -- Carlos. > > > > > Tom Petch > > > >> > >> Thanks, > >> Mach > >> > >> ----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Wednesday, August 17, 2011 11:08 AM > >>> To: Mach Chen > >>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; cpignata@cisco.com > >>> Subject: New Version Notification for > > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > >>> > >>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > >>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > repository. > >>> > >>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping > >>> Revision: 01 > >>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > >>> Creation date: 2011-08-16 > >>> WG ID: Individual Submission > >>> Number of pages: 9 > >>> > >>> Abstract: > >>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > >>> and Traceroute mechanisms are commonly used to detect and isolate > >>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > >>> The PW LSP Ping and Traceroute elements, however, are not specified > >>> for IPv6 address usage. > >>> > >>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > >>> the LSP Ping and Traceroute mechanism are implicitly defined only for > >>> IPv4 Provider Edge (PEs) routers, and are not applicable for the case > >>> where PEs use IPv6 addresses. There is, additionally, a degree of > >>> potential ambiguity in the specification of these sub-TLVs since the > >>> address family is not explicitly specified but it is to be inferred > >>> from the sub-TLV length. > >>> > >>> This document updates RFC4379 to explicitly constraint these existing > >>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > >>> Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > >>> the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > >>> are IPv6 addresses.) This is done by defining two new LSP Ping sub- > >>> TLVs for IPv6 Pseudowire FECs. > >>> From cpignata@cisco.com Tue Sep 20 08:58:59 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2221F8C8A for ; Tue, 20 Sep 2011 08:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.795 X-Spam-Level: X-Spam-Status: No, score=-98.795 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067, SARE_UNSUB22=0.948, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akpoCqO3Itxf for ; Tue, 20 Sep 2011 08:58:58 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7782121F8C7C for ; Tue, 20 Sep 2011 08:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=7827; q=dns/txt; s=iport; t=1316534485; x=1317744085; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=tswFeruROBsJ/MlIxpYLhlaMeiXvy+qZ2a440MMcDnk=; b=airApRLXain7FqdW41qYtx2l1IDJCN4Ymp+iJxUva8wafPzBTvmIxB3J 9O/TPcdxx2voPdf/if3+JwK/8BuvaBANC53DzVAwvdqJncX55NIlNq4jH miX/ER21DQhcuXh1hmRjUElVm7RaCNb06Q+RHL78MA0mA+8mK05fDoOzo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAHO4eE6tJXHB/2dsb2JhbABCmGyOCGYCeIFTAQEBAQIBEgEnPQIFBwQCAQgRBAEBAScHRgkIAQEECwgJEgeHVQaUXQGePoYdYASHbotdhSeMEA X-IronPort-AV: E=Sophos;i="4.68,412,1312156800"; d="scan'208";a="22752005" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 20 Sep 2011 16:01:24 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p8KG1O9q006681; Tue, 20 Sep 2011 16:01:24 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 11:01:24 -0500 Received: from 72.163.62.204 ([72.163.62.204]) by XMB-RCD-206.cisco.com ([72.163.62.213]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Sep 2011 16:01:23 +0000 References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> <4E788726.3050008@cisco.com> <010801cc77a0$84b79c00$4001a8c0@gateway.2wire.net> Content-Transfer-Encoding: quoted-printable From: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt Thread-Index: Acx3rotUhsd9mkncR0yNehIy1T5tVA== Content-Type: text/plain; charset="us-ascii" In-Reply-To: <010801cc77a0$84b79c00$4001a8c0@gateway.2wire.net> Message-ID: <2FF146F8-BF8A-4C0A-957C-052A62B15212@cisco.com> Date: Tue, 20 Sep 2011 21:31:13 +0530 To: "t.petch" MIME-Version: 1.0 (iPhone Mail 8L1) X-OriginalArrivalTime: 20 Sep 2011 16:01:24.0470 (UTC) FILETIME=[8C0ED960:01CC77AE] Cc: mpls@ietf.org, ppan@infinera.com Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:58:59 -0000 Tom, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Sep 20, 2011, at 8:55 PM, "t.petch" wrote: > ----- Original Message ----- > From: "Carlos Pignataro" > To: "t.petch" > Cc: "Mach Chen" ; ; > Sent: Tuesday, September 20, 2011 2:29 PM >=20 >> Tom, >>=20 >> Many thanks for the comments, please see inline. >>=20 >> On 9/20/2011 1:58 PM, t.petch wrote: >>> ---- Original Message ----- >>> From: "Mach Chen" >>> To: >>> Cc: >>> Sent: Monday, September 19, 2011 3:28 AM >>>> Hi, >>>>=20 >>>> We submitted a new draft that updates RFC4379 to explicitly constraint t= he >>> existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire L= SP > Ping >>> (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the I= Pv6 >>> scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e= ., > where >>> the Sender's and Receiver's IP addresses are IPv6 addresses.) >>>>=20 >>>> We'd appreciate that you could spend some time to read the draft >>> (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and gi= ve > your >>> comments! >>>=20 >>> Mach >>>=20 >>> It looks ok, but I sort of get worried when I have to spend too much tim= e >>> working out the details. Specifically, the IANA registries that RFC4379= > created >>> have been given names by IANA, even though RFC4379 itself did not do so,= so > I >>> think that this I-D should use these names. The registry in question, > MPLS - >>> LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making ea= rly >>> allocations to it so it is quite a big and volatile registry. >>=20 >> This is a good point, and frankly I'm not sure why we didn't -- I meant >> to. We can add "Multi-Protocol Label Switching (MPLS) Label Switched >> Paths (LSPs) Ping Parameters" "TLVs and sub-TLVs Registry", and a >> pointer to >> (although it would be changed to ). Thanks. >>=20 >>>=20 >>> Technically this is not a problem but it sort of worries me. This I-D i= s in > a >>> sense putting right a lack of foresight in RFC4379, nailing down what > RFC4379 >>> might have nailed down, so is there anything still missing that needs > nailing >>> down? I cannot see anything but think I am probably missing something:-= ( >>>=20 >>=20 >> Please note that this I-D is not a cleanup exercise for RFC4379; it's >> purposely narrowly focused to LSP Ping for IPv6 PW FECs. >=20 > Yup, I understand that, and that is my concern, that we are getting to the= point > where a cleanup may be needed. With the benefit of (wonderful) hindsight,= how > much better it would be to have a range of sub-TLVs, say 1-63, that are co= mmon > across TLVs, and another, say 128-191 that are unique to a TLV. Reading > draft-ietf-mpls-return-path-specified-lsp-ping > makes the need for that clear, but, too late. I think that this I-D makes clear the need for two particular TLVs to share s= ub-TLVs, but not necessarily have common sub-TLVs across the whole TLV range= (which includes Experimental, etc) > At the moment, RFC4379 is clear; > "The number spaces for the > sub-TLVs of various TLVs are independent." > which is a problem for > draft-ietf-mpls-return-path-specified-lsp-ping > and not for you; sigh. I think that the problem perhaps is that this ID refers directly to (the fro= zen in time) RFC 3479 and not jus say explicitly that subTLVs are shared bet= ween those two: http://tools.ietf.org/html/draft-ietf-mpls-return-path-specified-lsp-ping-03= #section-6.2.1 >=20 > But I think that it does behove authors like yourself to keep an eye on, e= .g., > draft-ietf-mpls-return-path-specified-lsp-ping > to see if it needs the same actions as you are proposing, and since > they have an Editor in common ( I was referring to M. Chen(Ed.) rather tha= n > yourself), hopefully that will be the case. I do see the point you bring up. I agree. I think however that for a solutio= n, the direction of expectation is backwards: mpls-return-path needs to ensu= re alignment on the TLV is itself defining.=20 And EFFJI in the response earlier, I expect Mach will speak about mpls-retur= n-path.=20 Thanks, Carlos.=20 >=20 > Tom Petch >=20 >>=20 >>> Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of whic= h > you >>> are updating three. TLV Type21 has 19 sub-TLVs which closely parallel t= hose > of >>> Type 1 which you are not updating (ok there is another I-D that should d= o so > but >>> have the authors of that I-D - namely you! - any thoughts on this?). >>=20 >> I am not an author of this I-D, >> draft-ietf-mpls-return-path-specified-lsp-ping, but my sense is that >> this I-D draft-ietf-mpls-return-path-specified-lsp-ping should point to >> draft-chen-mpls-ipv6-pw-lsp-ping and figure out TLV 21. This is because >> TLV 21 is defined by draft-ietf-mpls-return-path-specified-lsp-ping, and >> compounded by the fact that these are temporary allocations. >>=20 >>> Should the >>> registry be looked at more widely to see if it can better be rationalise= d? >>=20 >> I think you just did, mostly -- note that a cleanup or rationalization >> of this registry is not a goal of this I-D. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>>=20 >>> Tom Petch >>>=20 >>>>=20 >>>> Thanks, >>>> Mach >>>>=20 >>>> ----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Wednesday, August 17, 2011 11:08 AM >>>>> To: Mach Chen >>>>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; cpignata@cisco.com= >>>>> Subject: New Version Notification for >>> draft-chen-mpls-ipv6-pw-lsp-ping-01.txt >>>>>=20 >>>>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been= >>>>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF >>> repository. >>>>>=20 >>>>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping >>>>> Revision: 01 >>>>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs >>>>> Creation date: 2011-08-16 >>>>> WG ID: Individual Submission >>>>> Number of pages: 9 >>>>>=20 >>>>> Abstract: >>>>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping= >>>>> and Traceroute mechanisms are commonly used to detect and isolate >>>>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs.= >>>>> The PW LSP Ping and Traceroute elements, however, are not specified >>>>> for IPv6 address usage. >>>>>=20 >>>>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack i= n >>>>> the LSP Ping and Traceroute mechanism are implicitly defined only fo= r >>>>> IPv4 Provider Edge (PEs) routers, and are not applicable for the cas= e >>>>> where PEs use IPv6 addresses. There is, additionally, a degree of >>>>> potential ambiguity in the specification of these sub-TLVs since the= >>>>> address family is not explicitly specified but it is to be inferred >>>>> from the sub-TLV length. >>>>>=20 >>>>> This document updates RFC4379 to explicitly constraint these existin= g >>>>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP >>>>> Ping to the IPv6 scenario where an IPv6 LDP session is used to signa= l >>>>> the Pseudowire (i.e., where the Sender's and Receiver's IP addresses= >>>>> are IPv6 addresses.) This is done by defining two new LSP Ping sub-= >>>>> TLVs for IPv6 Pseudowire FECs. >>>>>=20 >=20 From loa@pi.nu Tue Sep 20 10:57:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FFB1F0C3D; Tue, 20 Sep 2011 10:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2adFh18vQwxe; Tue, 20 Sep 2011 10:57:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0887B1F0C3B; Tue, 20 Sep 2011 10:57:57 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 947FD2A8002; Tue, 20 Sep 2011 20:00:22 +0200 (CEST) Message-ID: <4E78D4B6.2000706@pi.nu> Date: Tue, 20 Sep 2011 20:00:22 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-li-lb@tools.ietf.org, pwe3@ietf.org, MPLS-TP ad hoc team Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] verification call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 17:57:58 -0000 Working Group, the draft-ietf-mpls-tp-li-lb has completed working group last call and the authors has updated the document considering the comments. A new version (-05) has been published and will be found here: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/ This is to start a one week verification call, to make sure that all comments has been correctly addressed. A list of all comments and how they been resolved will be found at: http://www.pi.nu/~loa/li-lb-05-Comments.xls This verification call ends Tuesday Sep 27 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Tue Sep 20 11:13:08 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EFB1F0C47 for ; Tue, 20 Sep 2011 11:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur0wCah4p0Yo for ; Tue, 20 Sep 2011 11:13:07 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id EFB4B1F0C44 for ; Tue, 20 Sep 2011 11:13:06 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 9A96C2A8003; Tue, 20 Sep 2011 20:15:32 +0200 (CEST) Message-ID: <4E78D844.4090809@pi.nu> Date: Tue, 20 Sep 2011 20:15:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 18:13:08 -0000 Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From rcallon@juniper.net Tue Sep 20 12:43:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ECF21F8C7F for ; Tue, 20 Sep 2011 12:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RsJGMBbspsM for ; Tue, 20 Sep 2011 12:43:11 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1021F8C7C for ; Tue, 20 Sep 2011 12:43:03 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTnjtWW7eCYtvIeZjpe8Z9hEM5XRlew6S@postini.com; Tue, 20 Sep 2011 12:45:38 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 20 Sep 2011 12:44:04 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 20 Sep 2011 15:44:03 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Tue, 20 Sep 2011 15:43:59 -0400 Thread-Topic: draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB Thread-Index: Acx3zaP9pBvz5QrkRo6DwIhB+Her7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {2C40E03C-DD35-4426-9EE4-48F45D59D9E7} x-cr-hashedpuzzle: ArmF B8sC CkZb DNiO DdK5 E1ol GfR+ G0KD IVU1 IbI7 Imox IqT5 JcaC JjuB KF1l Kyp2; 1; bQBwAGwAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {2C40E03C-DD35-4426-9EE4-48F45D59D9E7}; cgBjAGEAbABsAG8AbgBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Tue, 20 Sep 2011 19:43:59 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAG0AcABsAHMALQB0AHAALQB0AGUALQBtAGkAYgAgAEMAbwBuAHMAZQBuAHMAdQBzACAAQwBhAGwAbAAgAG8AbgAgAFIAZQBhAGQALQBPAG4AbAB5ACAATQBJAEIA acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C5415BC80FEMBX01WFjnprn_" MIME-Version: 1.0 Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 19:43:12 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C5415BC80FEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB= (it currently contains relatively few writeable objects). This is compatib= le with my understanding of how MIBs are often used. However, this also var= ies from normal IETF convention where MIBs contain both read and write obje= cts. We therefore are asking for comments from the WG regarding whether people a= re okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only. Thanks, Ross (for the MPLS WG co-chairs) --_000_DF7F294AF4153D498141CBEFADB17704C5415BC80FEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-onl= y MIB (it currently contains relatively few writeable objects). This is com= patible with my understanding of how MIBs are often used. However, this als= o varies from normal IETF convention where MIBs contain both read and write objects.
 
We therefore are asking for comments from the WG regarding whether peo= ple are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only= .
 
Thanks, Ross
(for the MPLS WG co-chairs)
 
 --_000_DF7F294AF4153D498141CBEFADB17704C5415BC80FEMBX01WFjnprn_-- From emily.chenying@huawei.com Tue Sep 20 15:43:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822B911E80D8 for ; Tue, 20 Sep 2011 15:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9Yjh4RE3TLQ for ; Tue, 20 Sep 2011 15:43:41 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D148611E80D5 for ; Tue, 20 Sep 2011 15:43:40 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU008X6F8TT1@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 06:46:05 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU00M84F8SP0@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 06:46:05 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB56968; Wed, 21 Sep 2011 06:46:02 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 06:45:56 +0800 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.73]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 06:45:45 +0800 Date: Tue, 20 Sep 2011 22:45:43 +0000 From: "Emily Chen(Ying)" In-reply-to: <4E78D844.4090809@pi.nu> X-Originating-IP: [10.212.246.233] To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8FZocLgFdNyz0idcqkEJ7QnhJVW3jlA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:50:03 -0000 WWVzL3N1cHBvcnSjoQ0KDQpSZWdhcmRzLA0KRW1pbHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NClNlbnQ6IFR1ZXNkYXksIFNlcHRl bWJlciAyMCwgMjAxMSAxMToxNiBBTQ0KVG86IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBt cGxzQGlldGYub3JnDQpTdWJqZWN0OiBbbXBsc10gcG9sbCBvbiBtYWtpbmcgZHJhZnQtemhhby1t cGxzLWxkcC1tdWx0aS10b3BvbG9neS0wMi50eHQgYW4gbXBscyB3ZyBkb2N1bWVudA0KDQpXb3Jr aW5nIEdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCB0byBzZWUgaWYg dGhlcmUgaXMgc3VwcG9ydCB0byBtYWtlDQoNCiAgICAgTERQIEV4dGVuc2lvbiBmb3IgTXVsdGkg VG9wb2xvZ3kgU3VwcG9ydA0KICAgICBkcmFmdC16aGFvLW1wbHMtbGRwLW11bHRpLXRvcG9sb2d5 LTAyLnR4dA0KDQphbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClNlbmQgeW91ciBv cGluaW9ucyB0byBtcGxzQGlldGYub3JnDQoNClBsZWFzZSByZW1lbWJlciB0aGF0IGl0IGlzIHBh cnRpY3VsYXIgaW1wb3J0YW50IHRoYXQgeW91IGluY2x1ZGUgYSB0ZWNobmljYWwgbW90aXZhdGlv biBpZiB5b3UgZG9uJ3Qgd2FudCB0aGUgSUQgdG8gYmVjb21lIGEgd29ya2luZyBncm91cCBkb2N1 bWVudC4NCg0KVGhlIHBvbGwgZW5kcyBXZWRuZXNkYXkgT2N0IDUsIDIwMTEuDQoNCi9Mb2ENCmZv ciB0aGUgTVBMUyB3ZyBjby1jaGFpcnMNCg0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3Ig U3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmlj c3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEz DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3 MiA5MiAxMyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K From lucy.yong@huawei.com Tue Sep 20 16:00:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5718F11E8073 for ; Tue, 20 Sep 2011 16:00:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADPWQmvvjd+V for ; Tue, 20 Sep 2011 16:00:30 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id A953911E80B6 for ; Tue, 20 Sep 2011 16:00:30 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU007DFG0WM2@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 20 Sep 2011 18:02:57 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU008SPG0WAZ@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 20 Sep 2011 18:02:56 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 16:02:52 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 16:02:52 -0700 Date: Tue, 20 Sep 2011 23:02:50 +0000 From: Lucy yong In-reply-to: <4E78D844.4090809@pi.nu> X-Originating-IP: [10.192.11.127] To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D104CFD6F@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8Fc3VaH7Ye1OUWe3z+p42oUrpVW40WQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 23:00:31 -0000 Support! Lucy -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, September 20, 2011 1:16 PM To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From huaimo.chen@huawei.com Tue Sep 20 16:52:38 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5987E1F0C63 for ; Tue, 20 Sep 2011 16:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD6zXNbJR3uC for ; Tue, 20 Sep 2011 16:52:37 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 76D891F0C5D for ; Tue, 20 Sep 2011 16:52:37 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU00L75IFR2D@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 20 Sep 2011 18:55:04 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRU00I36IFRZJ@usaga04-in.huawei.com> for mpls@ietf.org; Tue, 20 Sep 2011 18:55:03 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 16:54:59 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 16:55:01 -0700 Date: Tue, 20 Sep 2011 23:54:58 +0000 From: Huaimo Chen In-reply-to: X-Originating-IP: [10.212.244.192] To: "mpls@ietf.org" Message-id: <5316A0AB3C851246A7CA5758973207D4104997EF@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd/C1RYrAAbPDBU6WY3tKXaB32Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 23:52:38 -0000 Hi Loa and All, First, a disclosure, I am a co-author. Second, I support the document! Best Regards, Huaimo Date: Tue, 20 Sep 2011 20:15:32 +0200 From: Loa Andersson To: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Message-ID: <4E78D844.4090809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ------------------------------ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls End of mpls Digest, Vol 89, Issue 20 ************************************ From wwwrun@rfc-editor.org Tue Sep 20 22:19:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52F21F8C9D; Tue, 20 Sep 2011 22:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.178 X-Spam-Level: X-Spam-Status: No, score=-102.178 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3t6EsHg3zPG; Tue, 20 Sep 2011 22:19:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A622A21F8CA3; Tue, 20 Sep 2011 22:19:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 927FF98C243; Tue, 20 Sep 2011 22:22:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110921052220.927FF98C243@rfc-editor.org> Date: Tue, 20 Sep 2011 22:22:20 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6370 on MPLS Transport Profile (MPLS-TP) Identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 05:19:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6370 Title: MPLS Transport Profile (MPLS-TP) Identifiers Author: M. Bocci, G. Swallow, E. Gray Status: Standards Track Stream: IETF Date: September 2011 Mailbox: matthew.bocci@alcatel-lucent.com, swallow@cisco.com, eric.gray@ericsson.com Pages: 17 Characters: 35294 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-identifiers-07.txt URL: http://www.rfc-editor.org/rfc/rfc6370.txt This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK] This document is a product of the Multiprotocol Label Switching 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 Association Management Solutions, LLC From mach.chen@huawei.com Tue Sep 20 23:26:31 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1521F8C3A for ; Tue, 20 Sep 2011 23:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+4TiMYrYGdI for ; Tue, 20 Sep 2011 23:26:30 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4B521F8C31 for ; Tue, 20 Sep 2011 23:26:29 -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 <0LRV00MPG0O3NM@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 14:28:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRV00MT90O03B@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 14:28:51 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB78216; Wed, 21 Sep 2011 14:28:50 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 14:28:43 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.219]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 14:28:46 +0800 Date: Wed, 21 Sep 2011 06:28:44 +0000 From: Mach Chen In-reply-to: <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> X-Originating-IP: [10.110.98.47] To: "t.petch" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt Thread-index: AQHMd354rYPqbLnZg06gjJiaGpzqnpVXCf0Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> Cc: "ppan@infinera.com" Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 06:26:31 -0000 Hi Tom, Many thanks for your comments. Please see my response inline... > > Mach > > It looks ok, but I sort of get worried when I have to spend too much time > working out the details. Specifically, the IANA registries that RFC4379 > created > have been given names by IANA, even though RFC4379 itself did not do so, so I > think that this I-D should use these names. The registry in question, MPLS - > LSP Ping Parameters - TLVs and sub-TLVs, Good suggestion, will do that in the later version. >already has four I-Ds making early > allocations to it so it is quite a big and volatile registry. > > Technically this is not a problem but it sort of worries me. This I-D is in a > sense putting right a lack of foresight in RFC4379, nailing down what RFC4379 > might have nailed down, so is there anything still missing that needs nailing > down? I cannot see anything but think I am probably missing something:-( I did a rough checking when I wrote this draft, and found that the PW FEC is the only one that needs nailing down, which impacts two documents, one is RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. > > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel those > of > Type 1 which you are not updating (ok there is another I-D that should do so but > have the authors of that I-D - namely you! - any thoughts on this?). Should the > registry be looked at more widely to see if it can better be rationalised? As the author of the two drafts, I have noticed that and have plan to update the return-path-specified-lsp-ping draft, and make a point to this new draft is the straightforward and simple solution. Since that draft is still working in progress and has the common author, it's easier to update. Best regards, Mach > > Tom Petch > > > > > Thanks, > > Mach > > > > ----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Wednesday, August 17, 2011 11:08 AM > > > To: Mach Chen > > > Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; > cpignata@cisco.com > > > Subject: New Version Notification for > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > > > > > A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > repository. > > > > > > Filename: draft-chen-mpls-ipv6-pw-lsp-ping > > > Revision: 01 > > > Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > > > Creation date: 2011-08-16 > > > WG ID: Individual Submission > > > Number of pages: 9 > > > > > > Abstract: > > > Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > > > and Traceroute mechanisms are commonly used to detect and isolate > > > data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > > > The PW LSP Ping and Traceroute elements, however, are not specified > > > for IPv6 address usage. > > > > > > Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > > > the LSP Ping and Traceroute mechanism are implicitly defined only for > > > IPv4 Provider Edge (PEs) routers, and are not applicable for the case > > > where PEs use IPv6 addresses. There is, additionally, a degree of > > > potential ambiguity in the specification of these sub-TLVs since the > > > address family is not explicitly specified but it is to be inferred > > > from the sub-TLV length. > > > > > > This document updates RFC4379 to explicitly constraint these existing > > > PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > > > Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > > > the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > > > are IPv6 addresses.) This is done by defining two new LSP Ping sub- > > > TLVs for IPv6 Pseudowire FECs. > > > > > > > > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mach.chen@huawei.com Tue Sep 20 23:49:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2696521F8C8D for ; Tue, 20 Sep 2011 23:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.548 X-Spam-Level: X-Spam-Status: No, score=-4.548 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeewRkCJzUDY for ; Tue, 20 Sep 2011 23:49:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BE19421F8B20 for ; Tue, 20 Sep 2011 23:49:33 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRV00JGO1NAY2@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 14:49:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRV00ISA1MV4Y@szxga05-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 14:49:58 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADU67443; Wed, 21 Sep 2011 14:49:56 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 14:49:51 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.219]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 14:49:51 +0800 Date: Wed, 21 Sep 2011 06:49:50 +0000 From: Mach Chen In-reply-to: <010801cc77a0$84b79c00$4001a8c0@gateway.2wire.net> X-Originating-IP: [10.110.98.47] To: "t.petch" , Carlos Pignataro Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt Thread-index: AQHMd5ELfYQMYgvHy0q/w86UMh9D8JVWY++3gAD/BHA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> <4E788726.3050008@cisco.com> <010801cc77a0$84b79c00$4001a8c0@gateway.2wire.net> Cc: "mpls@ietf.org" , "ppan@infinera.com" Subject: Re: [mpls] New Version Notification for draft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 06:49:35 -0000 Hi Tom, Please see my response inline... > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Tuesday, September 20, 2011 10:21 PM > To: Carlos Pignataro > Cc: Mach Chen; mpls@ietf.org; ppan@infinera.com > Subject: Re: [mpls] New Version Notification for > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > ----- Original Message ----- > From: "Carlos Pignataro" > To: "t.petch" > Cc: "Mach Chen" ; ; > > Sent: Tuesday, September 20, 2011 2:29 PM > > > Tom, > > > > Many thanks for the comments, please see inline. > > > > On 9/20/2011 1:58 PM, t.petch wrote: > > > ---- Original Message ----- > > > From: "Mach Chen" > > > To: > > > Cc: > > > Sent: Monday, September 19, 2011 3:28 AM > > >> Hi, > > >> > > >> We submitted a new draft that updates RFC4379 to explicitly constraint > the > > > existing PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire > LSP > Ping > > > (by defining two new LSP Ping sub-TLVs for IPv6 Pseudowire FECs) to the > IPv6 > > > scenario where an IPv6 LDP session is used to signal the Pseudowire (i.e., > where > > > the Sender's and Receiver's IP addresses are IPv6 addresses.) > > >> > > >> We'd appreciate that you could spend some time to read the draft > > > (http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-01 ) and give > your > > > comments! > > > > > > Mach > > > > > > It looks ok, but I sort of get worried when I have to spend too much time > > > working out the details. Specifically, the IANA registries that RFC4379 > created > > > have been given names by IANA, even though RFC4379 itself did not do so, > so > I > > > think that this I-D should use these names. The registry in question, > MPLS - > > > LSP Ping Parameters - TLVs and sub-TLVs, already has four I-Ds making early > > > allocations to it so it is quite a big and volatile registry. > > > > This is a good point, and frankly I'm not sure why we didn't -- I meant > > to. We can add "Multi-Protocol Label Switching (MPLS) Label Switched > > Paths (LSPs) Ping Parameters" "TLVs and sub-TLVs Registry", and a > > pointer to > > (although it would be changed to ). Thanks. > > > > > > > > Technically this is not a problem but it sort of worries me. This I-D is in > a > > > sense putting right a lack of foresight in RFC4379, nailing down what > RFC4379 > > > might have nailed down, so is there anything still missing that needs > nailing > > > down? I cannot see anything but think I am probably missing something:-( > > > > > > > Please note that this I-D is not a cleanup exercise for RFC4379; it's > > purposely narrowly focused to LSP Ping for IPv6 PW FECs. > > Yup, I understand that, and that is my concern, that we are getting to the point > where a cleanup may be needed. With the benefit of (wonderful) hindsight, > how > much better it would be to have a range of sub-TLVs, say 1-63, that are > common > across TLVs, and another, say 128-191 that are unique to a TLV. Reading > draft-ietf-mpls-return-path-specified-lsp-ping > makes the need for that clear, but, too late. At the moment, RFC4379 is > clear; > "The number spaces for the > sub-TLVs of various TLVs are independent." > which is a problem for > draft-ietf-mpls-return-path-specified-lsp-ping > and not for you; sigh. > > But I think that it does behove authors like yourself to keep an eye on, e.g., > draft-ietf-mpls-return-path-specified-lsp-ping > to see if it needs the same actions as you are proposing, and since > they have an Editor in common ( I was referring to M. Chen(Ed.) rather than > yourself), hopefully that will be the case. Yes, as replied in my previous email, an update to draft-ietf-mpls-return-path-specified-lsp-ping is needed. Best regards, Mach > > Tom Petch > > > > > > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which > you > > > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel > those > of > > > Type 1 which you are not updating (ok there is another I-D that should do so > but > > > have the authors of that I-D - namely you! - any thoughts on this?). > > > > I am not an author of this I-D, > > draft-ietf-mpls-return-path-specified-lsp-ping, but my sense is that > > this I-D draft-ietf-mpls-return-path-specified-lsp-ping should point to > > draft-chen-mpls-ipv6-pw-lsp-ping and figure out TLV 21. This is because > > TLV 21 is defined by draft-ietf-mpls-return-path-specified-lsp-ping, and > > compounded by the fact that these are temporary allocations. > > > > > Should the > > > registry be looked at more widely to see if it can better be rationalised? > > > > I think you just did, mostly -- note that a cleanup or rationalization > > of this registry is not a goal of this I-D. > > > > Thanks, > > > > -- Carlos. > > > > > > > > Tom Petch > > > > > >> > > >> Thanks, > > >> Mach > > >> > > >> ----Original Message----- > > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > >>> Sent: Wednesday, August 17, 2011 11:08 AM > > >>> To: Mach Chen > > >>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; > cpignata@cisco.com > > >>> Subject: New Version Notification for > > > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > >>> > > >>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > > >>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > > repository. > > >>> > > >>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping > > >>> Revision: 01 > > >>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > > >>> Creation date: 2011-08-16 > > >>> WG ID: Individual Submission > > >>> Number of pages: 9 > > >>> > > >>> Abstract: > > >>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > > >>> and Traceroute mechanisms are commonly used to detect and > isolate > > >>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > > >>> The PW LSP Ping and Traceroute elements, however, are not > specified > > >>> for IPv6 address usage. > > >>> > > >>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > > >>> the LSP Ping and Traceroute mechanism are implicitly defined only for > > >>> IPv4 Provider Edge (PEs) routers, and are not applicable for the case > > >>> where PEs use IPv6 addresses. There is, additionally, a degree of > > >>> potential ambiguity in the specification of these sub-TLVs since the > > >>> address family is not explicitly specified but it is to be inferred > > >>> from the sub-TLV length. > > >>> > > >>> This document updates RFC4379 to explicitly constraint these > existing > > >>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > > >>> Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > > >>> the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > > >>> are IPv6 addresses.) This is done by defining two new LSP Ping sub- > > >>> TLVs for IPv6 Pseudowire FECs. > > >>> From ietfc@btconnect.com Wed Sep 21 02:29:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB69921F8B7C for ; Wed, 21 Sep 2011 02:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LIl7I0DFlBr for ; Wed, 21 Sep 2011 02:29:19 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D421F8677 for ; Wed, 21 Sep 2011 02:29:17 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr10.btconnect.com with SMTP id EMU74753; Wed, 21 Sep 2011 10:31:31 +0100 (BST) Message-ID: <019301cc7838$45f53020$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mach Chen" , References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> Date: Wed, 21 Sep 2011 10:27:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E79AEF2.0086, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.21.83314:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, __C230066_P2, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E79AEF8.0139,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: ppan@infinera.com Subject: Re: [mpls] New Version Notification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 09:29:19 -0000 Mach Since you mention updating draft-ietf-mpls-return-path-specified-lsp-ping below, I offer two more revolutionary ideas. First is the relationship between the subTLVs of TLV Type1 and those of TLV Type21. Looking at the IANA page, I think that IANA have the same problem as I do. Are the subTLVs of TLV Type21 intended to approximate to those of Type1, be an exact match at this point in time (a fast moving target with three I-Ds with the IESG and RFC Editor), be an exact match for all time (with the implications on future editors being aware of that) r what? (I think that the IANA page is currently a 'what?' :-) Second, we are getting several RFC updating the registry that RFC4379 established, which makes it harder to find what is defined where and to make subsequent updates accurate, so the fewer RFC, the better. So were the chairs to poll for the adoption of draft-chen-mpls-ipv6-pw-lsp-ping-01 I would oppose, rather seeing its content, important but slight, rolled into draft-ietf-mpls-return-path-specified-lsp-ping which is the I-D, after all, that creates much of the complexity by introducing TLV Type 21. Tom Petch ----- Original Message ----- From: "Mach Chen" To: "t.petch" ; Cc: Sent: Wednesday, September 21, 2011 8:28 AM > Hi Tom, > > Many thanks for your comments. > > Please see my response inline... > > > > > Mach > > > > It looks ok, but I sort of get worried when I have to spend too much time > > working out the details. Specifically, the IANA registries that RFC4379 > > created > > have been given names by IANA, even though RFC4379 itself did not do so, so I > > think that this I-D should use these names. The registry in question, MPLS - > > LSP Ping Parameters - TLVs and sub-TLVs, > > Good suggestion, will do that in the later version. > > >already has four I-Ds making early > > allocations to it so it is quite a big and volatile registry. > > > > Technically this is not a problem but it sort of worries me. This I-D is in a > > sense putting right a lack of foresight in RFC4379, nailing down what RFC4379 > > might have nailed down, so is there anything still missing that needs nailing > > down? I cannot see anything but think I am probably missing something:-( > > I did a rough checking when I wrote this draft, and found that the PW FEC is the only one that needs nailing down, which impacts two documents, one is RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. > > > > > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which you > > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel those > > of > > Type 1 which you are not updating (ok there is another I-D that should do so but > > have the authors of that I-D - namely you! - any thoughts on this?). Should the > > registry be looked at more widely to see if it can better be rationalised? > > As the author of the two drafts, I have noticed that and have plan to update the return-path-specified-lsp-ping draft, and make a point to this new draft is the straightforward and simple solution. > > Since that draft is still working in progress and has the common author, it's easier to update. > > Best regards, > Mach > > > > > Tom Petch > > > > > > > > Thanks, > > > Mach > > > > > > ----Original Message----- > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > Sent: Wednesday, August 17, 2011 11:08 AM > > > > To: Mach Chen > > > > Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; > > cpignata@cisco.com > > > > Subject: New Version Notification for > > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > > > > > > > A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > repository. > > > > > > > > Filename: draft-chen-mpls-ipv6-pw-lsp-ping > > > > Revision: 01 > > > > Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > > > > Creation date: 2011-08-16 > > > > WG ID: Individual Submission > > > > Number of pages: 9 > > > > > > > > Abstract: > > > > Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping > > > > and Traceroute mechanisms are commonly used to detect and isolate > > > > data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > > > > The PW LSP Ping and Traceroute elements, however, are not specified > > > > for IPv6 address usage. > > > > > > > > Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > > > > the LSP Ping and Traceroute mechanism are implicitly defined only for > > > > IPv4 Provider Edge (PEs) routers, and are not applicable for the case > > > > where PEs use IPv6 addresses. There is, additionally, a degree of > > > > potential ambiguity in the specification of these sub-TLVs since the > > > > address family is not explicitly specified but it is to be inferred > > > > from the sub-TLV length. > > > > > > > > This document updates RFC4379 to explicitly constraint these existing > > > > PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > > > > Ping to the IPv6 scenario where an IPv6 LDP session is used to signal > > > > the Pseudowire (i.e., where the Sender's and Receiver's IP addresses > > > > are IPv6 addresses.) This is done by defining two new LSP Ping sub- > > > > TLVs for IPv6 Pseudowire FECs. > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From jcucchiara@mindspring.com Wed Sep 21 05:28:57 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47C21F8B66 for ; Wed, 21 Sep 2011 05:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0sG-BpHSRPh for ; Wed, 21 Sep 2011 05:28:56 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6896D21F8B4A for ; Wed, 21 Sep 2011 05:28:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XWi4p7wcl1gLp2HOqG22lRLZ1sCUdXNH4yJbXJtzGyiaV6ElARlqoaBQs0bP3j3e; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1R6LxP-0007eC-H4; Wed, 21 Sep 2011 08:31:19 -0400 Message-ID: <00db01cc785a$601488d0$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Ross Callon" , References: Date: Wed, 21 Sep 2011 08:31:23 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01CC7838.D8C28470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265458bb8d317f9090d912daf6b81c63a68adf4dea5d24d49372350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.31.146 Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 12:28:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01CC7838.D8C28470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am good with changing this MIB to be read-only. Thanks, -Joan ----- Original Message -----=20 From: Ross Callon=20 To: mpls@ietf.org=20 Sent: Tuesday, September 20, 2011 3:43 PM Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only = MIB There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only MIB (it currently contains relatively few writeable objects). = This is compatible with my understanding of how MIBs are often used. = However, this also varies from normal IETF convention where MIBs contain = both read and write objects.=20 We therefore are asking for comments from the WG regarding whether = people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be = read only.=20 Thanks, Ross (for the MPLS WG co-chairs)=20 -------------------------------------------------------------------------= ----- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------=_NextPart_000_00D8_01CC7838.D8C28470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I am good with changing this MIB = to be=20 read-only.
 
Thanks,
  -Joan
 
----- Original Message -----
From:=20 Ross Callon=20
Sent: Tuesday, September 20, = 2011 3:43=20 PM
Subject: [mpls] = draft-ietf-mpls-tp-te-mib=20 Consensus Call on Read-Only MIB

There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only=20 MIB (it currently contains relatively few writeable objects). This is=20 compatible with my understanding of how MIBs are often used. However, = this=20 also varies from normal IETF convention where MIBs contain both read = and write=20 objects.
 
We therefore are asking for comments from the WG regarding = whether people=20 are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read = only.=20
 
Thanks, Ross
(for the MPLS WG co-chairs)
 

_______________________________________________
mpls mailing = = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
------=_NextPart_000_00D8_01CC7838.D8C28470-- From huanglu@chinamobile.com Wed Sep 21 07:26:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C949E21F84B3 for ; Wed, 21 Sep 2011 07:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.276 X-Spam-Level: ** X-Spam-Status: No, score=2.276 tagged_above=-999 required=5 tests=[AWL=2.653, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqHzvsFfBRqd for ; Wed, 21 Sep 2011 07:26:10 -0700 (PDT) Received: from hqmta.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4057221F84B2 for ; Wed, 21 Sep 2011 07:26:10 -0700 (PDT) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id 834B32E2D6B; Wed, 21 Sep 2011 22:28:37 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id 7C2A12E27C3; Wed, 21 Sep 2011 22:28:37 +0800 (CST) Received: from PC-20110530UGBE ([10.2.0.85]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011092122283639-24798 ; Wed, 21 Sep 2011 22:28:36 +0800 Date: Wed, 21 Sep 2011 22:28:32 +0800 From: "Huang Lu" To: "mpls" Message-ID: <201109212228323287163@chinamobile.com> Organization: ChinaMobile X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-21 22:28:36, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-21 22:28:37, Serialize complete at 2011-09-21 22:28:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18398.007 X-TM-AS-Result: No--6.569-7.0-31-10 X-imss-scan-details: No--6.569-7.0-31-10;No--6.569-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: "quintin.zhao" , Li Lianyuan Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huanglu@chinamobile.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 14:26:10 -0000 Yes/support! 2011-09-21 Best Regards! Lu Huang Research Institute of China Mobile Floor 11, Door 2, Dacheng Plaza No.28 Xuanwumen West Ave, Xuanwu District Beijing 100053, China Phone: +86 10-15801696688-3287 Mobile: +86 13810820540 Email: huanglu@chinamobile.com -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, September 20, 2011 11:16 AM To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs From iesg-secretary@ietf.org Wed Sep 21 07:30:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F0811E8096; Wed, 21 Sep 2011 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ-8BXiHwNCs; Wed, 21 Sep 2011 07:30:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8111E809C; Wed, 21 Sep 2011 07:30:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110921143055.1286.57398.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2011 07:30:55 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Mechanism for performing LSP-Ping over MPLS tunnels' to Proposed Standard (draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 14:30:56 -0000 The IESG has approved the following document: - 'Mechanism for performing LSP-Ping over MPLS tunnels' (draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-enhanced-dsmap/ Technical Summary This documents describes methods for performing lsp-ping traceroute over mpls tunnels. The techniques specified in [RFC4379] outline a traceroute mechanism that includes FEC validation and ECMP path discovery. Those mechanisms are insufficient and do not provide details in case the FEC being traced traverses one or more mpls tunnels and in case where LSP stitching is in use. This document defines enhancements to the downstream-mapping TLV [RFC4379] to make it more extensible and to enable retrieval of detailed information. Using the enhanced TLV format along with the existing definitions of [RFC4379], this document describes procedures by which a traceroute request can correctly traverse mpls tunnels with proper FEC and label validations. Working Group Summary The document has been reviewed by the MPLS working and has been progressed in parallel with draft-ietf-mpls-ldp-p2mp through the working group last call process. Document Quality The document is well reviewed by the MPLS working groups. Personnel Ross Callon is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From rcallon@juniper.net Wed Sep 21 08:26:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0921F8BDC for ; Wed, 21 Sep 2011 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjaMArRJ3oZc for ; Wed, 21 Sep 2011 08:26:28 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 1177521F8BBB for ; Wed, 21 Sep 2011 08:26:27 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTnoCuGFeql7TURV6gKQSdcbcQbR4pwno@postini.com; Wed, 21 Sep 2011 08:28:57 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 21 Sep 2011 08:28:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 21 Sep 2011 11:28:19 -0400 From: Ross Callon To: "mpls@ietf.org" Date: Wed, 21 Sep 2011 11:28:16 -0400 Thread-Topic: WG last call on draft-ietf-mpls-ldp-iana-01 Thread-Index: AcxsvAO9OlUM0NimTJmOhPh+NTTJqQLtqoow Message-ID: References: In-Reply-To: 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 Cc: Ross Callon Subject: Re: [mpls] WG last call on draft-ietf-mpls-ldp-iana-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 15:26:29 -0000 This working group last call has now ended, and the document has passed wit= h no need for an update.=20 We will submit it to the IESG for publication.=20 thanks, Ross (for the WG co-chairs) -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Tuesday, September 06, 2011 1:40 PM To: mpls@ietf.org Subject: [mpls] WG last call on draft-ietf-mpls-ldp-iana-01 Working Group, This is to start a two week working group last call on draft-ietf-mpls-ldp-iana-01 ["Label Distribution Protocol (LDP)=20 Internet Assigned Numbers Authority (IANA) Considerations Update"]. Please send comments to the mpls@ietf.org mailing list. This working group last call ends on Tuesday September 20th.=20 George, Loa and Ross MPLS WG co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From quintin.zhao@huawei.com Wed Sep 21 09:26:56 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F421F8B05 for ; Wed, 21 Sep 2011 09:26:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0CyTWETmJ5d for ; Wed, 21 Sep 2011 09:26:56 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 72BEB21F8586 for ; Wed, 21 Sep 2011 09:26:56 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRV00HDGSH093@usaga04-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 11:29:25 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRV00MCXSH0VA@usaga04-in.huawei.com> for mpls@ietf.org; Wed, 21 Sep 2011 11:29:24 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 21 Sep 2011 09:29:19 -0700 Received: from QZHAO (10.212.246.232) by DFWEML401-HUB.china.huawei.com (10.193.5.101) with Microsoft SMTP Server id 14.1.270.1; Wed, 21 Sep 2011 09:29:18 -0700 Date: Wed, 21 Sep 2011 12:29:00 -0400 From: Quintin Zhao In-reply-to: X-Originating-IP: [10.212.246.232] To: loa.andersson@ericsson.com, mpls@ietf.org Message-id: <002b01cc787b$96948c90$c3bda5b0$%zhao@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acx4J+IkNNqOn/deRBietTnDyDy6sgAQD6YQ References: Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 16:26:57 -0000 Loa and all, Yes, I support, although I am an author of said document. Thanks, Quintin. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, September 20, 2011 11:16 AM To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ------------------------------ **** From skraza@cisco.com Wed Sep 21 11:54:51 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7411E80CB for ; Wed, 21 Sep 2011 11:54:51 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe6P+CekPkOX for ; Wed, 21 Sep 2011 11:54:51 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6C11E80AB for ; Wed, 21 Sep 2011 11:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=675; q=dns/txt; s=iport; t=1316631440; x=1317841040; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=xakY2KcJVtdIC0EM515GBPu9Jat2XP4epmcI37oZ5Gw=; b=P1gq4HMGrLQjt+vNcX0YyIveZXIS19UPcPtRhEs7OCFzzUVVwUdeEXwR OorW9nT7odjFRvHkZ40/cqMNv4VGKgCd10oeXrPHJIIy++pQPSrVcLY4o pp7nhb31nWu11r7lzO6xxe3Pq6eD07khd8vlPUrvOokHHGCxFjhfyEPHq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB0zek6tJV2Z/2dsb2JhbABCp2l4gVMBAQEBAgESAScCARgpDQEIgQwRAQEEARIih1WWSgGeIYZ9BJNNhSiMIw X-IronPort-AV: E=Sophos;i="4.68,418,1312156800"; d="scan'208";a="23092313" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 21 Sep 2011 18:57:02 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LIv2UG027860; Wed, 21 Sep 2011 18:57:02 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 13:57:01 -0500 Received: from 10.86.245.193 ([10.86.245.193]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Sep 2011 18:56:40 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 21 Sep 2011 14:56:39 -0400 From: Kamran Raza To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-Index: Acx4kDGehvTxxYF+r0K++TQxdepyPQ== In-Reply-To: <4E78D844.4090809@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Sep 2011 18:57:01.0762 (UTC) FILETIME=[3F2FC220:01CC7890] Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 18:54:52 -0000 Yes/Support. On 11-09-20 2:15 PM, "Loa Andersson" wrote: > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > -- Syed Kamran Raza Cisco Systems, Inc., http://www.cisco.com From anzarhasan@gmail.com Wed Sep 21 12:01:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859841F0CA0 for ; Wed, 21 Sep 2011 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdBkDbmCAbEj for ; Wed, 21 Sep 2011 12:01:29 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F21F0C52 for ; Wed, 21 Sep 2011 12:01:28 -0700 (PDT) Received: by gwj16 with SMTP id 16so853549gwj.15 for ; Wed, 21 Sep 2011 12:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zXdC4w9rl1WqRsB4apDjhpdpOTMzkUW0MjmLB6o1o34=; b=M6I7oKuiEduEvYwGMUA86hwL/ywJ2ThTPe26hyrRaqaTLGrX08rT4nhYsqN2qgJfrF k66ghErEHVRKUckrhhSMI9q5u3vEcLtuwZweWR4/JGVx6Xur2guU2kASYPpSmLhu+kMV jWREa9rkCS0oOBaZfTgKwUiKeJa45hArY2ABk= MIME-Version: 1.0 Received: by 10.68.10.4 with SMTP id e4mr1762233pbb.516.1316631837576; Wed, 21 Sep 2011 12:03:57 -0700 (PDT) Received: by 10.143.10.6 with HTTP; Wed, 21 Sep 2011 12:03:57 -0700 (PDT) In-Reply-To: References: <4E78D844.4090809@pi.nu> Date: Wed, 21 Sep 2011 14:03:57 -0500 Message-ID: From: Anzar Hasan To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5215c4bfa8edd04ad783c7e Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 19:01:29 -0000 --bcaec5215c4bfa8edd04ad783c7e Content-Type: text/plain; charset=ISO-8859-1 Yes/Support. Anzar Hasan Deloitte & Touche LLP www.Deloitte.com On Wed, Sep 21, 2011 at 1:56 PM, Kamran Raza wrote: > Yes/Support. > > > On 11-09-20 2:15 PM, "Loa Andersson" wrote: > > > Working Group, > > > > this is to start a two week poll to see if there is support to make > > > > LDP Extension for Multi Topology Support > > draft-zhao-mpls-ldp-multi-topology-02.txt > > > > an MPLS working group document. > > > > Send your opinions to mpls@ietf.org > > > > Please remember that it is particular important that you include a > > technical motivation if you don't want the ID to become a > > working group document. > > > > The poll ends Wednesday Oct 5, 2011. > > > > /Loa > > for the MPLS wg co-chairs > > > > -- > Syed Kamran Raza > Cisco Systems, Inc., > http://www.cisco.com > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --bcaec5215c4bfa8edd04ad783c7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes/Support.

Anzar Hasan
Deloitte & Touche LLP
www.Deloitte.com

On Wed, Sep 21, 2011 at 1:56 PM, Kamran Raza <skraza@cisco.com> wrote:
Yes/Support.


On 11-09-20 2:15 PM, "Loa Andersson" <loa@pi.nu> wrote:

> Working Group,
>
> this is to start a two week poll to see if there is support to make >
> =A0 =A0 =A0LDP Extension for Multi Topology Support
> =A0 =A0 =A0draft-zhao-mpls-ldp-multi-topology-02.txt
>
> an MPLS working group document.
>
> Send your opinions to mpls@ietf.org
>
> Please remember that it is particular important that you include a
> technical motivation if you don't want the ID to become a
> working group document.
>
> The poll ends Wednesday Oct 5, 2011.
>
> /Loa
> for the MPLS wg co-chairs
>

--
Syed Kamran Raza
Cisco Systems, Inc.,
http://www.cisco.com=



_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--bcaec5215c4bfa8edd04ad783c7e-- From wwwrun@rfc-editor.org Wed Sep 21 12:07:01 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32E721F86FF; Wed, 21 Sep 2011 12:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYP5Hiw2sdro; Wed, 21 Sep 2011 12:07:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0253F21F86F6; Wed, 21 Sep 2011 12:07:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9C93198C24B; Wed, 21 Sep 2011 12:09:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110921190930.9C93198C24B@rfc-editor.org> Date: Wed, 21 Sep 2011 12:09:30 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6371 on Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 19:07:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6371 Title: Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks Author: I. Busi, Ed., D. Allan, Ed. Status: Informational Stream: IETF Date: September 2011 Mailbox: Italo.Busi@alcatel-lucent.com, david.i.allan@ericsson.com Pages: 62 Characters: 142857 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-oam-framework-11.txt URL: http://www.rfc-editor.org/rfc/rfc6371.txt The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Sep 21 12:07:14 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9557B11E80F9; Wed, 21 Sep 2011 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxS7wy2EiSJC; Wed, 21 Sep 2011 12:07:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0A11E80F4; Wed, 21 Sep 2011 12:07:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7C9CE98C26E; Wed, 21 Sep 2011 12:09:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110921190943.7C9CE98C26E@rfc-editor.org> Date: Wed, 21 Sep 2011 12:09:43 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6372 on MPLS Transport Profile (MPLS-TP) Survivability Framework X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 19:07:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6372 Title: MPLS Transport Profile (MPLS-TP) Survivability Framework Author: N. Sprecher, Ed., A. Farrel, Ed. Status: Informational Stream: IETF Date: September 2011 Mailbox: nurit.sprecher@nsn.com, adrian@olddog.co.uk Pages: 56 Characters: 142437 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-survive-fwk-06.txt URL: http://www.rfc-editor.org/rfc/rfc6372.txt Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes. This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 Association Management Solutions, LLC From liu.guoman@zte.com.cn Wed Sep 21 20:05:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5E721F8ACC for ; Wed, 21 Sep 2011 20:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.535 X-Spam-Level: X-Spam-Status: No, score=-97.535 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43xoJvu13U4l for ; Wed, 21 Sep 2011 20:05:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C27F721F8ABC for ; Wed, 21 Sep 2011 20:05:27 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713806486374; Thu, 22 Sep 2011 11:06:55 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 34524.806486374; Thu, 22 Sep 2011 11:07:52 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id p8M37pNY039039 for ; Thu, 22 Sep 2011 11:07:51 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8M32eNE033585; Thu, 22 Sep 2011 11:02:40 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201109220307.p8M37pNY039039@mse02.zte.com.cn> In-Reply-To: <4E78D4B6.2000706@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Thu, 22 Sep 2011 11:02:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-22 11:02:41, Serialize complete at 2011-09-22 11:02:41 Content-Type: multipart/alternative; boundary="=_alternative 0010B61448257913_=" X-MAIL: mse02.zte.com.cn p8M37pNY039039 X-MSS: AUDITRELEASE@mse02.zte.com.cn Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-li-lb@tools.ietf.org, pwe3@ietf.org Subject: Re: [mpls] verification call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 03:05:29 -0000 This is a multipart message in MIME format. --=_alternative 0010B61448257913_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksIGNoYWlycyBhbmQgRWRpdG9ycw0KaSBoYXZlIGp1c3QgcmV2aWV3IGFuZCBjb21wYXJlIG1w bHMtdHAgb2FtIGZyYW1ld29yayBhbmQgdGhpcyBkcmFmdC4NCml0IGZlZWwgYXMgaWYgdGhlIExv Y2sgZnVuY3Rpb24gaXMgZGlmZmVyZW50IG1lY2hhbmlzbSBpbiB0aGUgdHdvIGRyYWZ0cy4NCg0K c28gaSB0aGluayBpdCBuZWVkIHRvIHJldmlzZSBjb250ZXh0IG9mIExvY2sgZnVuY3Rpb24gaW4g b25lIGRyYWZ0IHRvIA0Ka2VlcCBhY2NvcmRhbmNlIHRvIGFub3RoZXIgZHJhZnQuDQoNCmJlc3Qg cmVnYXJkcw0KbGl1DQoNCg0KDQoNCg0KDQoNCg0KTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PiAN CreivP7IyzogIG1wbHMtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wOS0yMSAwMjowMA0KDQrK1bz+ yMsNCiJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4sICJtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZyIgDQo8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCBkcmFmdC1pZXRmLW1wbHMt dHAtbGktbGJAdG9vbHMuaWV0Zi5vcmcsIA0KcHdlM0BpZXRmLm9yZywgTVBMUy1UUCBhZCBob2Mg dGVhbSA8YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQ+DQqzrcvNDQoNCtb3zOINClttcGxzXSB2ZXJp ZmljYXRpb24gY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGINCg0KDQoNCg0KDQoNCldv cmtpbmcgR3JvdXAsDQoNCnRoZSBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGIgaGFzIGNvbXBsZXRl ZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbA0KYW5kIHRoZSBhdXRob3JzIGhhcyB1cGRhdGVkIHRo ZSBkb2N1bWVudCBjb25zaWRlcmluZyB0aGUgY29tbWVudHMuDQpBIG5ldyB2ZXJzaW9uICgtMDUp IGhhcyBiZWVuIHB1Ymxpc2hlZCBhbmQgd2lsbCBiZSBmb3VuZCBoZXJlOg0KaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtbGktbGIvDQoNClRoaXMgaXMg dG8gc3RhcnQgYSBvbmUgd2VlayB2ZXJpZmljYXRpb24gY2FsbCwgdG8gbWFrZSBzdXJlIHRoYXQg YWxsDQpjb21tZW50cyBoYXMgYmVlbiBjb3JyZWN0bHkgYWRkcmVzc2VkLg0KDQpBIGxpc3Qgb2Yg YWxsIGNvbW1lbnRzIGFuZCBob3cgdGhleSBiZWVuIHJlc29sdmVkIHdpbGwgYmUgZm91bmQgYXQ6 DQoNCmh0dHA6Ly93d3cucGkubnUvfmxvYS9saS1sYi0wNS1Db21tZW50cy54bHMNCg0KVGhpcyB2 ZXJpZmljYXRpb24gY2FsbCBlbmRzIFR1ZXNkYXkgU2VwIDI3IDIwMTEuDQoNCi9Mb2ENCmZvciB0 aGUgTVBMUyB3ZyBjby1jaGFpcnMNCg0KDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgIGVtYWlsOiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3Ry YXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3Nv biBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5 MiAxMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5v dGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVk IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBh bmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkg dmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1 YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k IFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0010B61448257913_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLCBjaGFpcnMgYW5kIEVkaXRv cnM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmkgaGF2ZSBqdXN0 IHJldmlldyBhbmQgY29tcGFyZSBtcGxzLXRwDQpvYW0gZnJhbWV3b3JrIGFuZCB0aGlzIGRyYWZ0 LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aXQgZmVlbCBhcyBp ZiB0aGUgTG9jayBmdW5jdGlvbiBpcyBkaWZmZXJlbnQNCm1lY2hhbmlzbSBpbiB0aGUgdHdvIGRy YWZ0cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNv IGkgdGhpbmsgaXQgbmVlZCB0byByZXZpc2UgY29udGV4dA0Kb2YgTG9jayBmdW5jdGlvbiBpbiBv bmUgZHJhZnQgdG8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5r ZWVwIGFjY29yZGFuY2UgdG8gYW5vdGhlciBkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJlc3QgcmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFs aWduPWNlbnRlcj48L2Rpdj4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvYSBBbmRlcnNzb24gJmx0O2xvYUBwaS5udSZn dDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7bXBscy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTEtMDktMjEgMDI6MDA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90 OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDssDQomcXVvdDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZyZxdW90OyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7LA0KZHJhZnQtaWV0Zi1t cGxzLXRwLWxpLWxiQHRvb2xzLmlldGYub3JnLCBwd2UzQGlldGYub3JnLCBNUExTLVRQIGFkIGhv Yw0KdGVhbSAmbHQ7YWhtcGxzLXRwQGxpc3RzLml0dS5pbnQmZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbXBsc10gdmVyaWZpY2F0 aW9uIGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLWxpLWxiPC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5Xb3JraW5nIEdyb3VwLDxicj4N Cjxicj4NCnRoZSBkcmFmdC1pZXRmLW1wbHMtdHAtbGktbGIgaGFzIGNvbXBsZXRlZCB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbDxicj4NCmFuZCB0aGUgYXV0aG9ycyBoYXMgdXBkYXRlZCB0aGUgZG9j dW1lbnQgY29uc2lkZXJpbmcgdGhlIGNvbW1lbnRzLjxicj4NCkEgbmV3IHZlcnNpb24gKC0wNSkg aGFzIGJlZW4gcHVibGlzaGVkIGFuZCB3aWxsIGJlIGZvdW5kIGhlcmU6PGJyPg0KaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtbGktbGIvPGJyPg0KPGJy Pg0KVGhpcyBpcyB0byBzdGFydCBhIG9uZSB3ZWVrIHZlcmlmaWNhdGlvbiBjYWxsLCB0byBtYWtl IHN1cmUgdGhhdCBhbGw8YnI+DQpjb21tZW50cyBoYXMgYmVlbiBjb3JyZWN0bHkgYWRkcmVzc2Vk Ljxicj4NCjxicj4NCkEgbGlzdCBvZiBhbGwgY29tbWVudHMgYW5kIGhvdyB0aGV5IGJlZW4gcmVz b2x2ZWQgd2lsbCBiZSBmb3VuZCBhdDo8YnI+DQo8YnI+DQpodHRwOi8vd3d3LnBpLm51L35sb2Ev bGktbGItMDUtQ29tbWVudHMueGxzPGJyPg0KPGJyPg0KVGhpcyB2ZXJpZmljYXRpb24gY2FsbCBl bmRzIFR1ZXNkYXkgU2VwIDI3IDIwMTEuPGJyPg0KPGJyPg0KL0xvYTxicj4NCmZvciB0aGUgTVBM UyB3ZyBjby1jaGFpcnM8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2Eg QW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb208YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmlj c3NvbiBJbmMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAg NzE3IDUyIDEzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOys0NiA3NjcgNzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4N Cjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 0010B61448257913_=-- From mach.chen@huawei.com Wed Sep 21 20:29:10 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4903711E8095 for ; Wed, 21 Sep 2011 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.344 X-Spam-Level: X-Spam-Status: No, score=-5.344 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QwVaEUd1Gcy for ; Wed, 21 Sep 2011 20:29:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D943A11E8086 for ; Wed, 21 Sep 2011 20:29:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRW005MQN306P@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 11:30:37 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRW00HTGN30HK@szxga05-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 11:30:36 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC22060; Thu, 22 Sep 2011 11:30:35 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 11:30:28 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.219]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 11:30:30 +0800 Date: Thu, 22 Sep 2011 03:30:29 +0000 From: Mach Chen In-reply-to: <4E78D844.4090809@pi.nu> X-Originating-IP: [10.108.4.67] To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8FXpz0Ieta30Eu++iJ8chaUfJVYwEwQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 03:29:10 -0000 Yes/Support. Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Wednesday, September 21, 2011 2:16 AM > To: mpls-chairs@tools.ietf.org; mpls@ietf.org > Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an > mpls wg document > > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@rfc-editor.org Wed Sep 21 20:40:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA101F0C5E for ; Wed, 21 Sep 2011 20:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poFBgWwjPW5j for ; Wed, 21 Sep 2011 20:40:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 429471F0C5C for ; Wed, 21 Sep 2011 20:40:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B0FEB98C262; Wed, 21 Sep 2011 20:42:49 -0700 (PDT) To: kireeti@juniper.net, swallow@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, swallow@cisco.com, loa@pi.nu From: RFC Errata System Message-Id: <20110922034249.B0FEB98C262@rfc-editor.org> Date: Wed, 21 Sep 2011 20:42:49 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC4379 (2978) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 03:40:19 -0000 The following errata report has been submitted for RFC4379, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4379&eid=2978 -------------------------------------- Type: Editorial Reported by: Zhi Zheng Section: 4.4 Original Text ------------- on page 36 Else { Retrieve the associated label operation from the corresponding NLFE and proceed to step 4 (Label Operation check). Corrected Text -------------- Else { Retrieve the associated label operation from the corresponding NHLFE and proceed to step 4 (Label Operation check). Notes ----- NLFE -> NHLFE Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4379 (draft-ietf-mpls-lsp-ping-13) -------------------------------------- Title : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Publication Date : February 2006 Author(s) : K. Kompella, G. Swallow Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From curtis@occnc.com Wed Sep 21 21:50:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F010621F8CB5 for ; Wed, 21 Sep 2011 21:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUytIuspQEHb for ; Wed, 21 Sep 2011 21:50:48 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id EADFB21F8CBD for ; Wed, 21 Sep 2011 21:50:47 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2002:ad09:6a83::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id p8KKdEMf041207; Tue, 20 Sep 2011 13:39:15 -0700 (PDT) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v2.8.3 gateway.ipv6.occnc.com p8KKdEMf041207 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=occnc.com; s=occnc; t=1316551155; bh=X0wAH/Ije4x7oPmnNn+sgdZDInGB8pFD133tsOfBAo4=; h=To:cc:Reply-To:From:Subject:In-reply-to:Date; b=WiR2Nxqk0pysH38mrodglf6YAcCFB2JnvzBGkURlnHmgsnQwfSkH3EmWuK8uVL1tJ Y1E9KCjZp82D6EDQd3UMQCx2Zm7Y5tJheuF8Wj1PQBXIWorlzb6jyNVBgUo7iijPNq TROKngWE0fe8DiyezAgCVHBUUlHTmUQd3JzTxejI= Message-Id: <201109202039.p8KKdEMf041207@gateway.ipv6.occnc.com> To: Ross Callon From: Curtis Villamizar In-reply-to: Your message of "Tue, 20 Sep 2011 15:43:59 EDT." Date: Tue, 20 Sep 2011 13:39:14 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 04:50:49 -0000 In message Ross Callon writes: > There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a > read-only MIB (it currently contains relatively few writeable > objects). This is compatible with my understanding of how MIBs are > often used. However, this also varies from normal IETF convention > where MIBs contain both read and write objects. > > We therefore are asking for comments from the WG regarding whether > people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be > read only. > > Thanks, Ross > (for the MPLS WG co-chairs) No complaint here. It should have been read-only in the first place IMO. Most implementations provide a rich superset of configuration options when setting up the ingress of an RSVP-TE tunnel through CLI or netconf. Configuring using the MIB was never practical. The MIB is highly useful for monitoring MPLS RSVP-TE tunnels from the ingress but was never useful for configuration. Curtis From dhruv.dhody@huawei.com Wed Sep 21 22:09:23 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E985721F8CA0 for ; Wed, 21 Sep 2011 22:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqTVVIBu5Tne for ; Wed, 21 Sep 2011 22:09:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9E21F8C9E for ; Wed, 21 Sep 2011 22:09:23 -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 <0LRW00L6VRRSS4@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 13:11:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRW00KU5RRSUS@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 13:11:52 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV14595; Thu, 22 Sep 2011 13:11:52 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 13:11:26 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 13:11:32 +0800 Date: Thu, 22 Sep 2011 05:11:31 +0000 From: Dhruv Dhody In-reply-to: X-Originating-IP: [10.18.24.76] To: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: <23CE718903A838468A8B325B80962F9B132CBCE9@SZXEML520-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8FaWmdN7NdlIkqpGReQXjjOypVYOlSAgACiL/A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 05:09:24 -0000 Yes / Support. Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen Sent: Thursday, September 22, 2011 9:00 AM To: Loa Andersson; mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Yes/Support. Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa > Andersson > Sent: Wednesday, September 21, 2011 2:16 AM > To: mpls-chairs@tools.ietf.org; mpls@ietf.org > Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an > mpls wg document > > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Kannan.Sampath@aricent.com Wed Sep 21 23:18:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB721F8CCC for ; Wed, 21 Sep 2011 23:18:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS1xD0TgEMxN for ; Wed, 21 Sep 2011 23:17:59 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by ietfa.amsl.com (Postfix) with ESMTP id 33DC821F8C99 for ; Wed, 21 Sep 2011 23:17:59 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 400C636B6E; Thu, 22 Sep 2011 11:44:42 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 3390936B6B; Thu, 22 Sep 2011 11:44:42 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.132]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 22 Sep 2011 11:50:22 +0530 From: Kannan KV Sampath To: Ross Callon Date: Thu, 22 Sep 2011 11:50:20 +0530 Thread-Topic: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB Thread-Index: Acx44603x9sgB+scSnunKalu8nPNAQACtSvg Message-ID: <04EDFA4923CA7849A51A812953FF8736020650EC98@GUREXMB02.ASIAN.AD.ARICENT.COM> References: Your message of "Tue, 20 Sep 2011 15:43:59 EDT." <201109202039.p8KKdEMf041207@gateway.ipv6.occnc.com> In-Reply-To: <201109202039.p8KKdEMf041207@gateway.ipv6.occnc.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 Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 06:18:00 -0000 Hi, I have a different of opinion on this. To the best of my knowledge, there are still OEMs/Vendors who use SNMP as t= he base for configuration. There are tons of automated testing that happens= based on SNMP MIBs. Even few NMS systems use SNMP as the southbound interf= ace with the NEs. Having said this, I have few open questions. 1) What are the advantages that we get by making it as READ-ONLY, or, what = are the disadvantages in retaining it as READ-WRITE? Can anyone elaborate o= n the compulsion behind making this as read-only? 2) Is this rule applicable for all other MIBs including the MIBs that are u= sed for all other protocols? Or, is this applicable only for "draft-ietf-mp= ls-tp-te-mib-00.txt"? If someone can explain more on this, it would be useful before making a dec= ision. Thanks & Regards, Kannan -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Cur= tis Villamizar Sent: Wednesday, September 21, 2011 2:09 AM To: Ross Callon Cc: mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only M= IB In message Ross Callon writes: > There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a > read-only MIB (it currently contains relatively few writeable > objects). This is compatible with my understanding of how MIBs are > often used. However, this also varies from normal IETF convention > where MIBs contain both read and write objects. > > We therefore are asking for comments from the WG regarding whether > people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be > read only. > > Thanks, Ross > (for the MPLS WG co-chairs) No complaint here. It should have been read-only in the first place IMO. Most implementations provide a rich superset of configuration options when setting up the ingress of an RSVP-TE tunnel through CLI or netconf. Configuring using the MIB was never practical. The MIB is highly useful for monitoring MPLS RSVP-TE tunnels from the ingress but was never useful for configuration. Curtis _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D From mach.chen@huawei.com Thu Sep 22 02:39:42 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E574221F8B43 for ; Thu, 22 Sep 2011 02:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RhkhIqdho8N for ; Thu, 22 Sep 2011 02:39:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A010321F88B7 for ; Thu, 22 Sep 2011 02:39:41 -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 <0LRX009V74AC6B@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 17:42:12 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRX00C0G4ACTG@szxga04-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 17:42:12 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC46521; Thu, 22 Sep 2011 17:42:10 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 17:42:03 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.219]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 17:42:07 +0800 Date: Thu, 22 Sep 2011 09:42:06 +0000 From: Mach Chen In-reply-to: <019301cc7838$45f53020$4001a8c0@gateway.2wire.net> X-Originating-IP: [10.108.4.67] To: "t.petch" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [mpls] New Version Notification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt Thread-index: AQHMeEFqR6xtBDsr5UqVfwz/zqZurpVY5CuQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> <019301cc7838$45f53020$4001a8c0@gateway.2wire.net> Cc: "ppan@infinera.com" Subject: Re: [mpls] New Version Notification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 09:39:43 -0000 Hi Tom, Please see inline... > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > t.petch > Sent: Wednesday, September 21, 2011 4:27 PM > To: Mach Chen; mpls@ietf.org > Cc: ppan@infinera.com > Subject: Re: [mpls] New Version Notification > fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > Mach > > Since you mention updating > draft-ietf-mpls-return-path-specified-lsp-ping > below, I offer two more revolutionary ideas. > > First is the relationship between the subTLVs of TLV Type1 and those of TLV > Type21. Looking at the IANA page, I think that IANA have the same problem > as I > do. Are the subTLVs of TLV Type21 intended to approximate to those of > Type1, > be an exact match at this point in time (a fast moving target with three I-Ds > with the IESG and RFC Editor), be an exact match for all time (with the > implications on future editors being aware of that) r what? (I think that the > IANA page is currently a 'what?' :-) Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for Type21 TLV, and vice versa. Strictly speaking, Type21 is totally independent of Type1 TLV, it just "borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and their sub-TLVs registries should be created, updated and maintained independently. > > Second, we are getting several RFC updating the registry that RFC4379 > established, which makes it harder to find what is defined where and to make > subsequent updates accurate, so the fewer RFC, the better. I basically agree with you here, but the practice of the IETF normally like this, a spec and then subsequent extensions with time. >So were the > chairs > to poll for the adoption of > draft-chen-mpls-ipv6-pw-lsp-ping-01 > I would oppose, rather seeing its content, important but slight, rolled into > draft-ietf-mpls-return-path-specified-lsp-ping I personally prefer to let them separate, because the two drafts have different purposes and functions. If the WG has the consensus to do it, I will be OK with that. Best regards, Mach > which is the I-D, after all, that creates much of the complexity by introducing > TLV Type 21. > > Tom Petch > > ----- Original Message ----- > From: "Mach Chen" > To: "t.petch" ; > Cc: > Sent: Wednesday, September 21, 2011 8:28 AM > > > Hi Tom, > > > > Many thanks for your comments. > > > > Please see my response inline... > > > > > > > > Mach > > > > > > It looks ok, but I sort of get worried when I have to spend too much time > > > working out the details. Specifically, the IANA registries that RFC4379 > > > created > > > have been given names by IANA, even though RFC4379 itself did not do so, > so > I > > > think that this I-D should use these names. The registry in question, > MPLS - > > > LSP Ping Parameters - TLVs and sub-TLVs, > > > > Good suggestion, will do that in the later version. > > > > >already has four I-Ds making early > > > allocations to it so it is quite a big and volatile registry. > > > > > > Technically this is not a problem but it sort of worries me. This I-D is in > a > > > sense putting right a lack of foresight in RFC4379, nailing down what > RFC4379 > > > might have nailed down, so is there anything still missing that needs > nailing > > > down? I cannot see anything but think I am probably missing something:-( > > > > I did a rough checking when I wrote this draft, and found that the PW FEC is > the only one that needs nailing down, which impacts two documents, one is > RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. > > > > > > > > Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which > you > > > are updating three. TLV Type21 has 19 sub-TLVs which closely parallel > those > > > of > > > Type 1 which you are not updating (ok there is another I-D that should do so > but > > > have the authors of that I-D - namely you! - any thoughts on this?). Should > the > > > registry be looked at more widely to see if it can better be rationalised? > > > > As the author of the two drafts, I have noticed that and have plan to update > the return-path-specified-lsp-ping draft, and make a point to this new draft is > the straightforward and simple solution. > > > > Since that draft is still working in progress and has the common author, it's > easier to update. > > > > Best regards, > > Mach > > > > > > > > Tom Petch > > > > > > > > > > > Thanks, > > > > Mach > > > > > > > > ----Original Message----- > > > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > > > Sent: Wednesday, August 17, 2011 11:08 AM > > > > > To: Mach Chen > > > > > Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; > > > cpignata@cisco.com > > > > > Subject: New Version Notification for > > > draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > > > > > > > > > > A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > > > > > successfully submitted by Mach(Guoyi) Chen and posted to the IETF > > > repository. > > > > > > > > > > Filename: draft-chen-mpls-ipv6-pw-lsp-ping > > > > > Revision: 01 > > > > > Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > > > > > Creation date: 2011-08-16 > > > > > WG ID: Individual Submission > > > > > Number of pages: 9 > > > > > > > > > > Abstract: > > > > > Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) > Ping > > > > > and Traceroute mechanisms are commonly used to detect and > isolate > > > > > data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > > > > > The PW LSP Ping and Traceroute elements, however, are not > specified > > > > > for IPv6 address usage. > > > > > > > > > > Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > > > > > the LSP Ping and Traceroute mechanism are implicitly defined only > for > > > > > IPv4 Provider Edge (PEs) routers, and are not applicable for the case > > > > > where PEs use IPv6 addresses. There is, additionally, a degree of > > > > > potential ambiguity in the specification of these sub-TLVs since the > > > > > address family is not explicitly specified but it is to be inferred > > > > > from the sub-TLV length. > > > > > > > > > > This document updates RFC4379 to explicitly constraint these > existing > > > > > PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > > > > > Ping to the IPv6 scenario where an IPv6 LDP session is used to > signal > > > > > the Pseudowire (i.e., where the Sender's and Receiver's IP > addresses > > > > > are IPv6 addresses.) This is done by defining two new LSP Ping > sub- > > > > > TLVs for IPv6 Pseudowire FECs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From amundk@simula.no Thu Sep 22 05:57:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392AC21F8B73 for ; Thu, 22 Sep 2011 05:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsZt8egXziQS for ; Thu, 22 Sep 2011 05:57:16 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6921F8BCD for ; Thu, 22 Sep 2011 05:57:16 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2864516bka.31 for ; Thu, 22 Sep 2011 05:59:47 -0700 (PDT) Received: by 10.204.146.155 with SMTP id h27mr1518325bkv.353.1316696386874; Thu, 22 Sep 2011 05:59:46 -0700 (PDT) Received: from amundmac.simula.no (fortran.simula.no. [128.39.37.254]) by mx.google.com with ESMTPS id t16sm8263545bkv.11.2011.09.22.05.59.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 05:59:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Amund Kvalbein In-Reply-To: Date: Thu, 22 Sep 2011 14:59:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: mpls@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 12:57:17 -0000 Support! I believe that MT routing has significant potential in an MPLS = setting. Several of the constraints that makes it difficult to exploit = the full potential of MT routing in an IGP context (e.g, packet marking) = are trivially solved in MPLS. Amund > Date: Tue, 20 Sep 2011 20:15:32 +0200 > From: Loa Andersson > To: "mpls-chairs@tools.ietf.org" , > "mpls@ietf.org" > Subject: [mpls] poll on making > draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document > Message-ID: <4E78D844.4090809@pi.nu> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > =20 > Working Group, > =20 > this is to start a two week poll to see if there is support to make > =20 > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > =20 > an MPLS working group document. > =20 > Send your opinions to mpls@ietf.org > =20 > Please remember that it is particular important that you include a = technical motivation if you don't want the ID to become a working group = document. > =20 > The poll ends Wednesday Oct 5, 2011. > =20 > /Loa > for the MPLS wg co-chairs > =20 > =20 > -- > =20 > =20 > Loa Andersson email: = loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > =20 > =20 > ------------------------------ > =20 Amund Kvalbein, PhD Senior Research Scientist Simula Research Laboratory http://simula.no/people/amundk From ning.so@verizon.com Thu Sep 22 07:06:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C221F8CAD for ; Thu, 22 Sep 2011 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.076 X-Spam-Level: X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs31glrIqbzR for ; Thu, 22 Sep 2011 07:05:59 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id E548A21F8C9D for ; Thu, 22 Sep 2011 07:05:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 22 Sep 2011 14:08:24 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208,217";a="142708123" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi03.verizon.com with ESMTP; 22 Sep 2011 14:08:12 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.60]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Thu, 22 Sep 2011 10:08:12 -0400 To: "mpls@ietf.org" Date: Thu, 22 Sep 2011 10:08:11 -0400 Thread-Topic: Re: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt mpls wg document Thread-Index: Acx5MPWtbXYB9dcPQF+4/SVfdmnbbQ== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08E033DCF@FHDP1LUMXC7V41.us.one.verizon.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_6665BC1FEA04AB47B1F75FA641C43BC08E033DCFFHDP1LUMXC7V41u_" MIME-Version: 1.0 Subject: Re: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 14:06:00 -0000 --_000_6665BC1FEA04AB47B1F75FA641C43BC08E033DCFFHDP1LUMXC7V41u_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 > Date: Tue, 20 Sep 2011 20:15:32 +0200 > From: Loa Andersson > > To: "mpls-chairs@tools.ietf.org" >, > "mpls@ietf.org" > > Subject: [mpls] poll on making > draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document > Message-ID: <4E78D844.4090809@pi.nu> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a techni= cal motivation if you don't want the ID to become a working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > ------------------------------ > --_000_6665BC1FEA04AB47B1F75FA641C43BC08E033DCFFHDP1LUMXC7V41u_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support.

 

&= nbsp;

Best regards,

 

Ning So

=

Verizon Corporate Technology

(= office) 972-729-7905

(Cell) 972-955-0914<= /span>

 

 

> Date: Tue, 20 Se= p 2011 20:15:32 +0200

> From: Loa = Andersson <loa@pi.nu>

=

> To: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>,

>        &n= bsp; "mpls@ietf.org" <mpls@ietf.org>

> Subject: [mpls] poll on making

>          = draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document

> Message-ID: <4E78D844.4090809@pi.nu>

> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed=

> 

> Working Group,

&= gt; 

> this is to start a tw= o week poll to see if there is support to make

> 

>  = ;    LDP Extension for Multi Topology Support

=

>      draft-zhao-mpls-= ldp-multi-topology-02.txt

>  =

> an MPLS working group document.=

> 

> Send your opinions to mpls@ietf.org

> 

> Please remember that it is particular = important that you include a technical motivation if you don't want the ID = to become a working group document.

&= gt; 

> The poll ends Wednesd= ay Oct 5, 2011.

> 

> /Loa

> for the MPLS wg co-chairs

>=  

> 

> --

>&nbs= p;

> 

> Loa Andersson      &nbs= p;            &= nbsp;     email: loa.andersson@ericsson.com

> Sr Strategy and Standards Manager      = ;      loa@pi.nu<= o:p>

> Ericsson Inc   &n= bsp;            = ;          phone: +46 10 717 5= 2 13

>    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    +46 767 72 92 13

> 

> 

> ------------------------------=

> 

=  

 

= --_000_6665BC1FEA04AB47B1F75FA641C43BC08E033DCFFHDP1LUMXC7V41u_-- From audunh@simula.no Thu Sep 22 07:09:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB24921F8CB5 for ; Thu, 22 Sep 2011 07:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfViMBrSaguu for ; Thu, 22 Sep 2011 07:09:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 962BF21F8CAD for ; Thu, 22 Sep 2011 07:09:23 -0700 (PDT) Received: by eye4 with SMTP id 4so1722335eye.31 for ; Thu, 22 Sep 2011 07:11:53 -0700 (PDT) Received: by 10.204.148.72 with SMTP id o8mr1721793bkv.65.1316700712868; Thu, 22 Sep 2011 07:11:52 -0700 (PDT) Received: from [192.168.2.105] (80.121.202.84.customer.cdi.no. [84.202.121.80]) by mx.google.com with ESMTPS id ex8sm1679942bkc.2.2011.09.22.07.11.51 (version=SSLv3 cipher=OTHER); Thu, 22 Sep 2011 07:11:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 22 Sep 2011 16:11:49 +0200 From: Audun Fosselie Hansen To: "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt mpls wg document In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC08E033DCF@FHDP1LUMXC7V41.us.one.verizon.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3399552711_1322421" Subject: Re: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 14:09:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3399552711_1322421 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Support from me as well. MT will be important for MPLS LDP. Best wishes, Audun -- Audun Fosselie Hansen, PhD Director of Simula Innovation Simula Research Laboratory audunh@simula.no +47 91 52 64 84 From: "So, Ning" Date: Thu, 22 Sep 2011 10:08:11 -0400 To: "mpls@ietf.org" Subject: Re: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt mpls wg document Yes/support. Best regards, Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 > Date: Tue, 20 Sep 2011 20:15:32 +0200 > From: Loa Andersson > To: "mpls-chairs@tools.ietf.org" , > "mpls@ietf.org" > Subject: [mpls] poll on making > draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document > Message-ID: <4E78D844.4090809@pi.nu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > ------------------------------ > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --B_3399552711_1322421 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Support from me as= well.
MT will be important for MPLS LDP.

Best wishes,
Audun


-= -
Audun Fosselie Hansen, PhD
Director of Simula Innovat= ion
Simula Research Laboratory
audunh@simula.no
+47 91 52 64 84

From: "So, Ning" <ni= ng.so@verizon.com>
Date: Th= u, 22 Sep 2011 10:08:11 -0400
To: = "mpls@ietf.org" <mpls@ietf.org>
Subject: <= /span> Re: [mpls] poll on makin gdraft-zhao-mpls-ldp-multi-topology-02.txt m= pls wg document

Yes/support.

 

 =

Best regards,

&= nbsp;

Ning So

Verizon C= orporate Technology

(office) 972-729-7905

(Cell) 972-955-0914

 

 

<= p class=3D"MsoPlainText">> Date: Tue, 20 Sep 2011 20:15:32 +0200=

> From: Loa Andersson <loa@pi.nu>

> To: "mpls-chairs@tools.ietf.org" &l= t;mpls-chairs@tools.ietf.org= >,

>    &nbs= p;     "mpls@ietf.org= " <mpls@ietf.org>

> Subject: [mpls] poll on making

>         = ; draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document

> Message-ID: <4E78D844.4090809@pi.nu>

> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

> 

> Working Group,

> 

> this is to start a two week poll t= o see if there is support to make

>=  

>    &n= bsp; LDP Extension for Multi Topology Support

>      draft-zhao-mpls-ldp-multi-topolog= y-02.txt

> 

> an MPLS working group document.

> 

> S= end your opinions to mpls@ietf.org

> 

> Please remember that it is particular important that you include = a technical motivation if you don't want the ID to become a working group do= cument.

> 

> The poll ends Wednesday Oct 5, 2011.

=

> 

&g= t; /Loa

> for the MPLS wg co-chairs=

> 

> 

> --<= /o:p>

> 

> 

> Loa Andersson&= nbsp;            = ;            email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com

> Sr Strategy and Standards Manager&n= bsp;           loa@pi.nu

> Eri= csson Inc           &= nbsp;            = ;  phone: +46 10 717 52 13

>&n= bsp;            =             &nbs= p;            &n= bsp;        +46 767 72 92 13

> 

= > 

> ---------------------= ---------

> 

 

 

_______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/m= ailman/listinfo/mpls --B_3399552711_1322421-- From czhou@cisco.com Thu Sep 22 07:21:16 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B521F8CC5 for ; Thu, 22 Sep 2011 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.246 X-Spam-Level: ** X-Spam-Status: No, score=2.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYRQuvIziAC8 for ; Thu, 22 Sep 2011 07:21:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D509121F8C9F for ; Thu, 22 Sep 2011 07:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=czhou@cisco.com; l=1586; q=dns/txt; s=iport; t=1316701423; x=1317911023; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=KHbcs+Ce1lGDHwJvAiZ6bYQn24v+hqogWM5FOQRwMVk=; b=ccqWZBvmdTfmDWhyxrHKa48e8ZXn7jNH/41LHk7Kl3wnTyca9d+RZ8cz vnNaSTFbyybxCFfpdKkA/MpdRoypXTYxPceCEvZhQBAz6898Ojl2Xks8d 0BSNRnaavo8klxPPbNPTLcCWrAIbWwC/p1qExBDTP/xjxluRs3NAAcXPb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANdEe06tJV2a/2dsb2JhbABChFyjJHiBUwEBAQEDEgEdJTICAgEZAwECBQYGGAQCARorBgMIAQEEARIIGp4sAYw7CJFoAoEmhEA1YASHcZEHjCU X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="23305533" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 22 Sep 2011 14:23:42 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8MENgkR005172; Thu, 22 Sep 2011 14:23:42 GMT Received: from xmb-rcd-208.cisco.com ([72.163.62.215]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 09:23:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Sep 2011 09:23:40 -0500 Message-ID: <01A021EBB03D534AB5CE4B620B5F82D10439DE23@XMB-RCD-208.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?UmWjulttcGxzXSBwb2xsIG9uIG1ha2luZyBkcmFmdC16aGFvLW1wbA==?= =?gb2312?B?cy1sZHAtbXVsdGktdG9wb2xvZ3ktMDIudHh0IGFuIG1wbHMgd2cgZA==?= =?gb2312?B?b2N1bWVudA==?= Thread-Index: Acx3yEHrOtZIrpcXSIGPg6mckhYaqAAHHI7wACBT2kAAMyHbYAAAB4IQ References: From: "Chao Zhou (czhou)" To: , , X-OriginalArrivalTime: 22 Sep 2011 14:23:42.0219 (UTC) FILETIME=[3AB5D5B0:01CC7933] Subject: [mpls] =?gb2312?b?UmWjuiBwb2xsIG9uIG1ha2luZyBkcmFmdC16aGFvLW1w?= =?gb2312?b?bHMtbGRwLW11bHRpLXRvcG9sb2d5LTAyLnR4dCBhbiBtcGxzIHdn?= =?gb2312?b?IGRvY3VtZW50?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 14:21:16 -0000 Yes/support=A3=A1 Chao Zhou Cisco Systems, Inc., http://www.cisco.com =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=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 Message: 3 Date: Tue, 20 Sep 2011 20:15:32 +0200 From: Loa Andersson To: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Message-ID: <4E78D844.4090809@pi.nu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ------------------------------ From wnattras@telcordia.com Thu Sep 22 10:38:47 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7B5E8002 for ; Thu, 22 Sep 2011 10:38: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY2O9tK9eQmC for ; Thu, 22 Sep 2011 10:38:46 -0700 (PDT) Received: from dnsmx1mnh.telcordia.com (dnsmx1mnh.telcordia.com [192.4.156.21]) by ietfa.amsl.com (Postfix) with ESMTP id 19A565E8001 for ; Thu, 22 Sep 2011 10:38:46 -0700 (PDT) Received: from rrc-dte-bms01.telcordia.com (rrc-dte-bms01.cc.telcordia.com [128.96.150.38]) by dnsmx1mnh.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id p8MHf5YI007375 for ; Thu, 22 Sep 2011 13:41:16 -0400 (EDT) X-AuditID: 80609626-b7bf0ae000007c1d-84-4e7b733c23eb Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by rrc-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id 39.E7.31773.C337B7E4; Thu, 22 Sep 2011 13:41:16 -0400 (EDT) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Thu, 22 Sep 2011 13:41:16 -0400 From: "Nattrass, William W" To: "'mpls@ietf.org'" Date: Thu, 22 Sep 2011 13:41:15 -0400 Thread-Topic: Plan to make draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: Acx5TtOqf3smZgD+T0a1p1JA4QgCPw== Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8B@rrc-dte-exmb1.dte.telcordia.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_5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8Brrcdteexmb1dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:38:47 -0000 --_000_5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8Brrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: "There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-on= ly MIB (it currently contains relatively few writeable objects). This is co= mpatible with my understanding of how MIBs are often used. However, this al= so varies from normal IETF convention where MIBs contain both read and writ= e objects. We therefore are asking for comments from the WG regarding whether people a= re okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only." Question: Would making the MIB read-only, preclude the ability for networ= k operators to declare standardized names within the MIB for their tunnels?= I ask, because I believe network operators will want to assign "network = level" names that will fit/(and be used) by their existing operations suppo= rt systems. Bill Nattrass Telcordia --_000_5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8Brrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re:  “There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively few writeable objects). This is compatible with my understanding= of how MIBs are often used. However, this also varies from normal IETF convent= ion where MIBs contain both read and write objects.

 

We therefore are aski= ng for comments from the WG regarding whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only.” =

 

 

 

Question:  Would making the MIB read-only,&nbs= p; preclude the ability for network operators to declare standardized names within the MIB = for their tunnels?  I ask,  because I believe network operators will = want to assign "network level" names that will fit/(and be used) by their existi= ng operations support systems.

 

Bill Nattrass

Telcordia

 

 

 

--_000_5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8Brrcdteexmb1dt_-- From tnadeau@lucidvision.com Thu Sep 22 10:43:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83F51F0C50 for ; Thu, 22 Sep 2011 10:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYDTkgM-F1n7 for ; Thu, 22 Sep 2011 10:43:26 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 08CED1F0C3C for ; Thu, 22 Sep 2011 10:43:26 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 87CCA1E52B0B; Thu, 22 Sep 2011 13:45:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_0F66D2AF-D2BD-4431-8C35-6EF2EBDF6456" From: Thomas Nadeau In-Reply-To: <5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8B@rrc-dte-exmb1.dte.telcordia.com> Date: Thu, 22 Sep 2011 13:46:00 -0400 Message-Id: References: <5CFF94AC6128EA478EB1B82775E1B6A726EE0EAC8B@rrc-dte-exmb1.dte.telcordia.com> To: "Nattrass, William W" X-Mailer: Apple Mail (2.1244.3) Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 17:43:26 -0000 --Apple-Mail=_0F66D2AF-D2BD-4431-8C35-6EF2EBDF6456 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 22, 2011, at 1:41 PM, Nattrass, William W wrote: > Re: =93There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only MIB (it currently contains relatively few writeable objects). = This is compatible with my understanding of how MIBs are often used. = However, this also varies from normal IETF convention where MIBs contain = both read and write objects. > =20 > We therefore are asking for comments from the WG regarding whether = people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be = read only.=94 > =20 > =20 > =20 > Question: Would making the MIB read-only, preclude the ability for = network operators to declare standardized names within the MIB for their = tunnels? I ask, because I believe network operators will want to = assign "network level" names that will fit/(and be used) by their = existing operations support systems. No, not at all assuming that you configured the TE functions = using a different means such as Netconf/XML/web services/CLI/etc... The = MIB being read-only is only from the external observer's point of view. = The internal device has the freedom to change anything it likes. --Tom > =20 > Bill Nattrass > Telcordia > =20 > =20 > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_0F66D2AF-D2BD-4431-8C35-6EF2EBDF6456 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Sep 22, 2011, at 1:41 PM, = Nattrass, William W wrote:

  =93There is a plan to = make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently = contains relatively few writeable objects). This is compatible with my = understanding of how MIBs are often used. However, this also varies from = normal IETF convention where MIBs contain both read and write = objects.
 
We therefore are asking for comments from the WG regarding = whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt = to be read only.=94
 
Question:  Would making the MIB = read-only,  preclude the ability for network operators to declare = standardized names within the MIB for their tunnels?  I ask,  = because I believe network operators will want to assign "network level" = names that will fit/(and be used) by their existing operations support = systems.

No, not = at all assuming that you configured the TE functions using a different = means such as Netconf/XML/web services/CLI/etc...  The MIB being = read-only is only from the external observer's point of view. The = internal device has the freedom to change anything it = likes.

= --Tom




Bill Nattrass
 
 
<201109202039.p8KKdEMf041207@gateway.ipv6.occnc.com> <04EDFA4923CA7849A51A812953FF8736020650EC98@GUREXMB02.ASIAN.AD.ARICENT.COM> To: Kannan KV Sampath X-Mailer: Apple Mail (2.1244.3) Cc: Ross Callon , "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:03:05 -0000 On Sep 22, 2011, at 2:20 AM, Kannan KV Sampath wrote: > Hi, > I have a different of opinion on this. > To the best of my knowledge, there are still OEMs/Vendors who use SNMP = as the base for configuration. There are tons of automated testing that = happens based on SNMP MIBs. Even few NMS systems use SNMP as the = southbound interface with the NEs. They are truly in the minority. Having worked on building the = management for one of the "big 3" MPLS implementations in the past, I = can safely say that we had a *tiny* fraction of customers that actually = ever asked us for writable MIBs, and even in those cases we often = refused to implement writable SNMP. As someone who has worked at a large = tier-1 service provider, my experience there was that SNMP writes are = basically disallowed for all but a few very tightly constrained cases = because vendors do not implement a fully writable implementation (see = case #1). Finally, as someone who now works for a large NM software = vendor, I can tell you that the latter situation is the majority case we = encounter both in the enterprise and SP space. Provisioning is = definitely done using CLI or XML in a majority of cases these days, and = is moving towards web services as a third alternative.=20 > Having said this, I have few open questions. > 1) What are the advantages that we get by making it as READ-ONLY, or, = what are the disadvantages in retaining it as READ-WRITE? Can anyone = elaborate on the compulsion behind making this as read-only? The disadvantage is that you cannot provision the objects you = find in this MIB using the SNMP protocol. However, that is not that big = a deal if you ask me since most implementations will overlay %20-%40 = more capabilities on top of the ones you will find in this MIB. Most of = those implementations will not offer those objects as writable. Thus, = you've got a patchwork quilt of things that are and are not writable; = therefore you go use the vendor's interface that is %100 writable: = generally the CLI, XML/netconf or web services.=20 The advantages are simple: Ease of design and time to RFC. = Making a MIB configurable is a major drag on resources working on it = with little return for that effort given that like %1 of users might = want to use those capabilities. Making is read-only lets you avoid all = sorts of things like object state locking, synchronization, etc... which = are hard to get right (and are done better in things like Netconf = anyway). Making anything more than a very simple MIB truly configurable = is something that I would reckon from past experience, easily quadruples = the amount of time it takes to get a MIB done and in some cases has = resulted in a 'wheel wrapped around the axle' situation when the IESG = reviews the MIB. Given what I mentioned above regarding data points = about the demand of writable functions actually being used, the effort = required to make a MIB writable just isn't justified IMHO. > 2) Is this rule applicable for all other MIBs including the MIBs that = are used for all other protocols? Or, is this applicable only for = "draft-ietf-mpls-tp-te-mib-00.txt"? As I understand it, the request Ross just posed was for = draft-ietf-mpls-tp-te-mib only. If you want to open up the discussion to = include all future MIBs this WG produces that is fine; however, I would = like to conclude this call for consensus on this specific draft first so = we don't get too distracted. --Tom >=20 > If someone can explain more on this, it would be useful before making = a decision. >=20 > Thanks & Regards, > Kannan >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Curtis Villamizar > Sent: Wednesday, September 21, 2011 2:09 AM > To: Ross Callon > Cc: mpls@ietf.org > Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on = Read-Only MIB >=20 >=20 > In message = > Ross Callon writes: >=20 >> There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a >> read-only MIB (it currently contains relatively few writeable >> objects). This is compatible with my understanding of how MIBs are >> often used. However, this also varies from normal IETF convention >> where MIBs contain both read and write objects. >>=20 >> We therefore are asking for comments from the WG regarding whether >> people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be >> read only. >>=20 >> Thanks, Ross >> (for the MPLS WG co-chairs) >=20 >=20 > No complaint here. >=20 > It should have been read-only in the first place IMO. Most > implementations provide a rich superset of configuration options when > setting up the ingress of an RSVP-TE tunnel through CLI or netconf. > Configuring using the MIB was never practical. The MIB is highly > useful for monitoring MPLS RSVP-TE tunnels from the ingress but was > never useful for configuration. >=20 > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 > = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From renwei.li@huawei.com Thu Sep 22 11:14:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C449821F8B87 for ; Thu, 22 Sep 2011 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbcQ2Gl3GahS for ; Thu, 22 Sep 2011 11:14:17 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF7A21F8B86 for ; Thu, 22 Sep 2011 11:14:17 -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 <0LRX00D7BS40CE@usaga02-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 13:16:48 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRX002GFS40CV@usaga02-in.huawei.com> for mpls@ietf.org; Thu, 22 Sep 2011 13:16:48 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 11:16:49 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 11:16:43 -0700 Date: Thu, 22 Sep 2011 18:16:43 +0000 From: Renwei Li In-reply-to: <4E78D844.4090809@pi.nu> X-Originating-IP: [10.193.34.106] To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8FaxyxgIaLpQUu1sJEbf4M6z5VZt9pQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 18:14:17 -0000 Yes/Support! /Renwei -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, September 20, 2011 11:16 AM To: mpls-chairs@tools.ietf.org; mpls@ietf.org Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Working Group, this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technical motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rcallon@juniper.net Thu Sep 22 12:11:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C678021F8B22 for ; Thu, 22 Sep 2011 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPcL5ShlQbko for ; Thu, 22 Sep 2011 12:11:06 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D7F4721F8B20 for ; Thu, 22 Sep 2011 12:10:55 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTnuI0QT/vBjtfPDxmkeiztE42h6UNvn6@postini.com; Thu, 22 Sep 2011 12:13:38 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 22 Sep 2011 12:07:53 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 22 Sep 2011 15:07:52 -0400 From: Ross Callon To: "adrian@olddog.co.uk" Date: Thu, 22 Sep 2011 15:07:51 -0400 Thread-Topic: Publication request for draft-ietf-mpls-ldp-iana Thread-Index: Acx5Wuy7wcKmyJuGR8GgTl2/iArDAw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-ldp-iana@tools.ietf.org" , Ross Callon , "Stewart Bryant \(stbryant\)" Subject: [mpls] Publication request for draft-ietf-mpls-ldp-iana X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 19:11:07 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a request for publish draft-ietf-mpls-ldp-iana as a BCP. The PROTO = writeup is attached. Thanks, Ross --_000_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is a request for publish draft-ietf-mpls-ldp-iana as a BCP. The P= ROTO writeup is attached.
 
Thanks, Ross
 
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="PROTO writeup for draft-ietf-mpls-ldp-iana.docx" Content-Description: PROTO writeup for draft-ietf-mpls-ldp-iana.docx Content-Disposition: attachment; filename="PROTO writeup for draft-ietf-mpls-ldp-iana.docx"; size=13408; creation-date="Thu, 22 Sep 2011 14:49:42 GMT"; modification-date="Thu, 22 Sep 2011 15:01:58 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDd/JU3ZgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtuwjAQvFfqP0S+Vomhh6qqCBz6OLZIpR9g7A1Y9Uv28vr7bgJEVQtBKuUSKVnvzOzsxIPR2pps CTFp70rWL3osAye90m5Wso/JS37PsoTCKWG8g5JtILHR8PpqMNkESBl1u1SyOWJ44DzJOViRCh/A UaXy0Qqk1zjjQchPMQN+2+vdcekdgsMcaww2HDxBJRYGs+c1fd4qiWASyx63B2uukokQjJYCSSlf OvWDJd8xFNTZnElzHdINyWD8IENdOU6w63sja6JWkI1FxFdhSQZf+ai48nJhaYaiG+aATl9VWkLb X6OF6CWkRJ5bU7QVK7Tb6z+qI+HGQPp/FVvcLnrSOY4+JE57OZsf6s0rUDlZESCihnZ1x0cHRLLs EsPvkLvGb1KAlHfgzbN/tgcNzEnKin6JiZgaOJvvV/Ja6JMiVjB9v5j738C7hLT5kz7+wYz9dVF3 H0gdb+634RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYz sKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdh b9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687 HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKySzWrDMBCE74W+g9h7LTv9oYTIuZRArq37AIq9/qGyJLSbtn77CkNShwb34otgRmjmk7Sb7Xdv xCcG6pxVkCUpCLSlqzrbKHgvdnfPIIi1rbRxFhUMSLDNb282r2g0x0PUdp5ETLGkoGX2aympbLHX lDiPNu7ULvSaowyN9Lr80A3KVZo+yTDNgPwiU+wrBWFf3YMoBh+b/892dd2V+OLKY4+Wr1TILzy8 IXO8HMVYHRpkBRMzibQgr4OslgShPxQnZw4hWxSBBxM/8/wMNOq5+scl6zmOCP62j1KOazbH8LAk Q+0sF/pgJhxn6wQhLwY9/wEAAP//AwBQSwMEFAAGAAgAAAAhAHx+D6oXDAAAPkAAABEAAAB3b3Jk L2RvY3VtZW50LnhtbOxbbU/byBb+fqX7H0b5tEjkjYa3qIAClG6lXRalrLr7cWJPyCy2x3fGSZr7 6+9zxnbiScBOIBS4alWVEo/H5/U5zzmefDz7HgZsIrSRKjqptRutGhORp3wZ3Z3U/ry9qh/VmEl4 5PNAReKkNhOmdnb67399nHZ95Y1DESUMW0SmO8HVUZLE3WbTeCMRctNQsYhwcah0yBP8qu+aIdf3 47juqTDmiRzIQCaz5l6rdVDLtlEntbGOutkW9VB6Whk1TOiWrhoOpSeyH/kdep3npndeZiLbJza1 CCCDisxIxibfLXzqblBxlG8yKVNiEgb5umm8ztN8zafwRxikYk+V9mOtPGEMPr1ML853bLfKnp0Z kLaY37GOCO4zc0lCLqP5NhQdS/6fO68B5zXTZzdpq4UisMUpYmmg/Bn9jNm0i1j0+ye1VmvvcG// 6riWf3QphnwcJHTloNO62vtk79R0m43Brom5ByFiLYzQE1E7ven/cfsH+9jEglP6166F6dTwk9bY NpnFWG9iEQRfE66TWpM2S3c8nWqZiHG81t2fIr94L4XyqjQMebAsDEkx13f/onN5fj7X9waB3Wpl H1otTxEJyAQpkmE9jANTD/y4LnnEl4R8aNd0g3qr7ayFUWK64tg9s24u2qrdrZnKbklFr9wne8LN skvzJzvbWAUesSz7pd3gO+zbSDFpWDISLM909nUk4pHQvrV+MsLlHLfO2K/cLt7YIo5cubCrZtqe esz+WdUpBnCriAfBjGkxkWIqfGgPHTNEZ2porfFeNMxdw1BwdpmMWIyslN444HoXfhOGwbXIIoMf AxFIMRGpvhsr+PLeyl0Ab2jB/ZkNQEDAlGuqrixR1jVfPn39bC/F40EgPVuQzlyYeDBJl8CioI97 pZhcq3nrru2vtQslYhnq9pUx7AJBqaLybHSchj3zTHoU+JZuqEbykh0JRNfab4HtJbvV19qqWGRK NiNoX2u/Hy8aCs4bleyBMvhwfCyMVlJRGuxXwUYoD5S6Nk+L0JRjD1UPnjCJv8UkL2RyY/NMriou bsqWp/dSBa7a2l1e3NrmvBuy2eISIzIqy4OdvMzOCy8M6zPui/+MeSKywsUGKhmxoVYhuxcz9u0z C0U4QHlbw4Cu2P0frmVanVGyFvJHKqovdDgDHUHtepiXjDiKmJNUD+L9W1FyxjwVeUJHhvGBGidp cogY3kNhHlC+0H9T3pGSkixNNtaxUI1c7bcQmanPrO0HQoBoCE1tqvDP2BrOcHNwvbL5Y4pvz02r BrtWc4f9BCNvpzIT59FtoZ1Sdo78GwfwKyFRJIRvWKj0HFwtrvICm05zVQGENYU+WmAvkROxu0bs u6n4WmgrGneNXWaEN0abPttlGDVpy515gHgHgxLf7edGhQKDKzbkIWZNHBxTAp7eiyd7vR61QQng NlNO/tf+h/z31++/ve9G4XnQVKgOLhwXq8Mq6L52+IIS+dUoxKMZo6SUmHfO8Zuc/l4iVxozBuWx 2eZMXVLKTLjaFybG8FUOAsF64A3sUmrAkNIb61gIBde9NhSy6HgihZ2TuyasT2Lbht2M1Djw0Qcw jn4eM4nh1lMxE3s1gt1oryAfReVLqPrzUrGqzrkSF52yqp3rwKeUl6LKT2pZBFoWNWVGBdLPJxgg 82AGRkRmbOD2kQTbd+J66/7PDLFqIdeaFf7PdrHBX+L/z0r5CwUta1SDf4gUQOkn8MZCRrrivnlw Hqb9KgCYaEMyAjAlIsJclUeMx7EAvwAQoFkVeiqNQHX2aWqHBeJ7okX4hF6uYCw3+ouZ8iz48qVB 9EKPZOthmrn3mWFazNmSMAVMLVSBwWO86jHCf0KAbhOy3AgvJuTW3Qn2cLcYqJS+EMD8GezBvhDA jIoq1xusq/PeyoDWGoiLqUIQsC+XLJKJeSfBGnCT9EWEXkr4N/xOnAMz7m1CPPJe8m8BTL3hCF1j 9UxpUkQvryxrGqpx9NpB7YbuU+pwsfQ8qQ6PFpG+iJMYJwYwcaV56xAGxyjKUIekWGRPGaCJpZdH bzHWZZQehICI7ySwHwnfcxrVFsxPBHhu/V02HUlvRLwJ5VKrWEtUxwazN9FKuAq9uUnoHVj/6sKw X6jQpmdMNOYWiebePRp6lFt2fnGz88rg/gbyQC7yYBXxV2F+nitfete9zROhqjK6BinyuWdRFGLX EhCajjcw2CHqmUYKIgkZjYCyawzRmLyxxGtgnBzZXMmXp1zZBDx3xll18X2cRrhXiqxw27Tr9JY6 XIob1wO75AJHhcL7Wjq+0TrqfLo4qpVwNzhweYOy1URYrG+XDPkTDv5ZHw4yJ5r8fYzjgDf8minP GtBWcFeqGnQaC4lPZ0I4HZcI0YcFPLobg29hDjxGxcHbWoxEN8eCVwM8H5KfX18xPQ6E2WW/fzln vhhKMF/quneZSDzMuCccYwh6UeopTfMxnPWBETb2ZDniPY+r5TMyxseJwjlINB04AerdC711opMJ +kzcK6pbAkLXCsEXg3F6HEPKH4M8jyqYXXiQSecfvqST0Xre7zBbH+jIkiV3iE0UhgjtiofJB8qy jLxg7FMXtziBt3GovlJC9oqKfKPTn/U/Y/RpgeCY84DKTsBPMqj5P9HujPWFR34T3zm9MwPFwphr gNdl1IESzqAMvxf/1XqWM9aciDT2bF0arIClvLCg/6ZIngfxxjq+ZKblcFrIK5re4bB1eoZkqHC2 jk6E5yTNdNeoBy6JrGzo3eVFmr+Kva8NTTDYrfBGEXA6YF/HIb5ksE5P4KpYnNu5V4qEm6pFfJMe f+QDY4sHHwB/AYUntUAMkxp+iZU5qR23D9JD4ckjC9pHH/bKV+wddo7KV3w4OOiUr+jsH7XKV+x3 jiskPei0KyQ9/LBXIenRXqdCUhisQtJ2q3VYIWq7dXxcIWu7fdyqELa9B3HLrdb+cNipErdzsG/F BdVGENhooS8pUOpOu4Gkr0zsYZPslz544EmNOBQ9meg5BdqDNN0N0CyZlz4sQJR75Wc8/4znVbh6 6XjGwCDFTX2FYoajAV3wqqRnJD+p3coQ3ONaTFkf/QO+UzTtekDQC4XTPTihhAtpLlLHl6aG3StP kcIsIuWOWbwTOm/9ofRlolv7PZL/AQAA///MVmFP2zAQ/SunfAKJQelahhCtVNqCkBjKWiQ+O8kl 8ebEke2Qdb9+ZyfZknYFxjZplZraPud8fvfuXWVYZpgbYGVifzWYFOE2N6hyNDC7PKkuzNQ+1fSS HkBfzaOVrybeYDA4Hy3n556z+PWGa2mdVBfItJlpzibeA89Qwz1WsJIZyz0yhnrizWWpOCpr8E6s B8HyhAb2qNqXmWrNkxwjuC+zAJWGWWlSqbjZwMHt7H52+Hx04/locXX1z6KDr5m40AULceIVCjWq J/SmEMqcAELFDKcRxFI5SO9YgAIWXBvFg9LawFfSyFAKOLhb+IdHbmvRrsUcRWSzwSg3CmFVHxAB z2t/Cx/WBYY85qE7Csirc1GlPEztHnrLvplLsGABE0I2WwspeMhRH/cAJOQLm4iiTbJN8dlocD1c 2qR18r61uMCYlcLsbvc7S7+gT+PGWsweNP/7AIE+j1J94XkCN0qWBazLLGNqA78d+qtgdKXSy1BD 8zZDHS99y04ynsGdqJkQpbWlqYyJTFxD1EqFSemeiaMYPN5AxTToTEqTQsXpQXyjGghJQDQQ+WXw GUNXC8evgKQfciMz++nW39694S5OW15qBdta7IDXt3Rdv43JliiLFsJPJRNWxv4yRxo43h4gxfhy SH3QX8xR0yQafjogu3E6Fk4fegxDbVgguE5R98LpNCCrLB03+/TDKZ8qBXUgq8QktP0Lksc6gC3h /bNjj91BVDMVdQKxgQgLITcYHZF6h6KMrFjUa673kqRTY9xARiLK3z1hHlGo1H4r0hX9mqrpc3W1 y2JXDZrq0P/RwTvS3KRmTXa7uhydLsdj1zeLZP2NrNXEOx0ORwPbBlIaj89pXFdY8pFZl0YWtD6q tyiepOSpnQbSGJn9nAuMO9YUGXXLifdh6NzHJCSdaVIaN22Oo25p/1w0Xde+4qIgabpRPCKL4Dn6 3IQU5fszZ6WuVl/c/bUIZLRxg1bNpt8BAAD//wMAUEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAV AAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJ lthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+p q9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx 24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9 Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0 rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna3 1qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaL N6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico 7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqpt nITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl +JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9 cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQc MfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4 q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO 38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsO JY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5 XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZq ysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAl bY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZK ncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5 CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nb G8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGc rPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAn oBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtS pRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5Z Giat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRl wOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMC mJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIG ovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2 bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMA UEsDBBQABgAIAAAAIQDsIR2oDwMAADwHAAARAAAAd29yZC9zZXR0aW5ncy54bWycVdtymzAQfe9M /4HhuTbYBpwwIZnxhV4maTsl+QABsq2JbiPJJu7XdwUoJC3NdPqEdM7u0e5qtVzdPDHqnbDSRPDM n01D38O8EjXh+8x/uM8nF76nDeI1ooLjzD9j7d9cv3931aQaGwNm2gMJrlOR+UfFU10dMEN6wkil hBY7M6kES8VuRyrcf/zeQ2X+wRiZBkHvNBUSc1DbCcWQ0VOh9kHnuRHVkWFugnkYJoHCFBkIWB+I 1E6N/a8aHHVwIqe3kjgx6uyaWfiWZZ9uI1T97PEv4VkHqUSFtYbKMtqlyxDhTkbTf9Hp6nlLSoXU +YXINVzbTyGY16QSqwoKCncehn5gCThY7AqDDAZaS0xp2wQVxYh3FjXeoSM196gsjJBgdUIQznLe C1QHpFBlsCokqsB3LbhRgjq7WnwVZi2YVJBeJwitIZFpT4cOrLUNwy5+CGGcG1x4FObzbedh2YEJ L6Lt+mKMieNkvU1GmXW0Wa1GmW2Sx6M+SRhvFssxn7/HlsTzZDEa23IRLvJRtctlst1uxs5ZxdFq fjnGbKPZNo7HmDwOk/VoPnkOmS6sT9AVHCrPUvsQviu3yuH2PNZd8RqxUhHk3dmnAl4sLdXjinDH lxieLH7JFMfSkZNJR2iGKM2hQxwBr6RjaqLlBu9aYXqH1H5QbluLpWoUhX788qxmuxmrj0ocZafa KCQ/8xpgd+Asino9ws0tYQ7Xx7JwXhxezAvqyOtvJ2UFg6FATWpgyGFboVvE964fMZ88FNa0SSuq CjsI8R2SEp4CmJT7WeZTsj+YmQ9bA7saqcd2U+7nPTdvOdhZrt2gymYG1v3CGnRLsOoXA7Zw2GLA IodFAxY7LB6wxGGJxQ5nGBEwAh5h4LilxXeCUtHg+pMDM/8PqCuCPiCJ4V7tzIAGE2kL9ENEe6cU P8H8wTUx8I+RpGboKfMX4TKy7r01RWdxNK9sLWeN5SvUq5FBMM3aq3rl3Db5b7E0aY0rAg1ZnFk5 jKhpFzgl2hRYwjQzQkHK7Zj70CoPv73rXwAAAP//AwBQSwMEFAAGAAgAAAAhAAUjaiKkAQAAEwUA ABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzEk91Og0AQhe9NfAey98qWVlsbaVN/eumF0QeYwlA2YXfJ zrbo2zuwqGlqE7kwLgkJZ3YPw8eZ2+WbrqI9OlLWpGJ0KUWEJrO5MttUvL6sL2YiIg8mh8oaTMU7 klguzs9um3lhjaeIzxuau1SU3tfzOKasRA10aWs0XCus0+D50W1jWxQqwweb7TQaHydSXscOK/D8 bipVTaJ3a37j1liX185mSMTN6ir4aVBGLPruomZuQHPX91CpjVNdoQZjCUdc20OVCpnItbzie3tN 5Li9i7h1yEpwhP5rowxyAVpV758qNYooFGrls/JT34NTsKkwlEhtubCjjUzFSvJKHtciKKNUTFpB Tu96JeGm+tUr40Ml63zClpvOhxX2+TrF7cfh/xyReFEaKXrCJnq2GgKqYyKJvGYSV8yjJTMeRMR1 vh3BXxLhIMhkNZt+E5kdfv83EU5jx/E0kdF6IJF7u3MKXcvkRD6mTOCGOSQdjckgGtrm6MwPASnU G+bH6fhnFqB5TOAEhzYNIRVtOobNyfBU/DwnUk7+Zk76gaHFBwAAAP//AwBQSwMEFAAGAAgAAAAh AK21YLyqAQAA9ggAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbOxWXU+DMBR9N/E/kL4rnwO2yEym 2ZNPOn9AB91oQntJW4fz13sHOLaJRpK9uSfKuR+c3pPTcnf/Lgprw5TmIBPi3jrEYjKFjMt1Ql4X 85uYWNpQmdECJEvIlmlyP72+uqsmFVu+MGMwU1vYReqJSkhuTDmxbZ3mTFB9CyWTGFuBEtTgq1rb sFrxlD1C+iaYNLbnOKGtWEENMtA5LzVpu1V/6VaBykoFKdMaiYii6Scol2SKHDO+0e3TqiY8S0g8 8v0giKK4ji8h2z7yDcY2tMD9E3uXLah6YiuzR0fOHn/m67w3sICyL38GxoD4FkFes0ztvmW6OokT JpiqPxKCOuCipCnOvF6nUADOl74ZaMgUBwyHVS6POA2rVYf7H1Jq12LUm26Wx7K4YRjGoTuOnL/r 8oMqHXygSQceK9Li/1qPxiYPOS+yU1Gi0HfcII5qUU5s0Y30yBQdfBn/z/7tsUMD6VaHXpPEnue7 XhCHF5MMOSrPcWj9YpLQ8+PxyBtdTNJ/U51j/F926DdJi+5OLygNF/yDzUHNFFSaKbzSMX7wtzL9 BAAA//8DAFBLAwQUAAYACAAAACEARNqhOfcBAAD2AwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxg+r5aTBdkWKCqGFEM3 bG2AuO1Zk+lEqC0JEpM1+/pSduMq207L6fGReHohn/nlU9dmB/BBW7PMJ0WZZ2CUrbXZLvO76svF xzwLKE0tW2tgmR8h5Jfi7Ru+9taBRw0hIwkTlvkO0S0YC2oHnQwFtQ11Gus7iVT6LbNNoxVcWbXv wCCbluWcwROCqaG+cKNgPiguDvi/orVV0V+4r46ODAteQedaiSBuop22qC12nI0sryzKttIdiMmU +LHia7mFIIgbAH+wvg5iNp9xNkC+2kkvFdIKxXQ++8RZQvDPzrVaSaTtih9aeRtsg9ltv4csCnCW jnDazQbU3ms8ipKztOTftYlWyMuAyJuXWy/dLoh5NDhWfKNkCyvagGhkG4CzV4Jfg4zXXUtNjvkB FwdQaH0W9G+67zTPfsoAcW/L/CC9lgZpf3FsKHrcuoBeVBpb0qbeUPcwHUuxnolJP0DgfDAKDB6o ce6ufyHcNvTf8B9mJ6nZ3sNgNbGTwPGNP1RXtnPSHMW3vdEU6ewG8Jf1j+Fd9tWogu750o8HeAx3 rrJXMUkvmz0nkzQ8aNxtnFR0s/eT8kOai6TFNxQfqOnQJ8FXgl/TFXwbX6VMmS3Up5m/GzFp98Nn TBEuSvr10TpxlI/x+xLPAAAA//8DAFBLAwQUAAYACAAAACEAlZKAtHcBAADlAgAAEQAIAWRvY1By b3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJRT4MwEMff TfwOpO9QYMZsBFiiZk8uMXFG41ttb1sdlKbtxvj2HrCxEX3wrXf/u1/v/m06P5aFdwBjZaUyEgUh 8UDxSki1ycjbauFPiWcdU4IVlYKMNGDJPL+9SblOeGXgxVQajJNgPSQpm3Cdka1zOqHU8i2UzAZY oVBcV6ZkDkOzoZrxHdsAjcPwnpbgmGCO0Rbo64FITkjBB6Tem6IDCE6hgBKUszQKInqpdWBK+2dD p1xVltI1Gnc6jXvNFrwXh+qjlUNhXddBPenGwPkj+rF8fu1W9aVqveJA8lTwxElXQJ7SyxFPdv/1 Ddz16SFAgRtgrjK54axAr7u2c651ewdNXRlhsXMUYasAy43UDt+w544SWF0w65b4qGsJ4qG5XPFb am8ycJDtf8gn3VVDiDt1FvajgvDQlKS38Ky8Tx6fVguSx2EU+eHMj+NVNE3uZkkYfrYbjfpbk/pE eZrtn0TERWPiGdCbM/6Y+Q8AAAD//wMAUEsDBBQABgAIAAAAIQAnOtIohQgAALtAAAAPAAAAd29y ZC9zdHlsZXMueG1szFttU6NIEP5+VfcfKL7vmfeotdktX0+rXNc1WvcZYWIoCZMDsur++uvpAUIg MN3CVp1fIsNMPz398vREpz9/fVsF1k8Rxb4MZ3b/r55tidCVnh8+z+zHh8tPh7YVJ07oOYEMxcx+ F7H99cuff3x+PY6T90DEFggI4+NoZi+TZH18cBC7S7Fy4r/kWoTwbiGjlZPAY/R8IBcL3xXn0t2s RJgcDHq9yUEkAicB8Hjpr2M7lfZKkfYqI28dSVfEMWi7CrS8leOH9hdQz5PuuVg4myCJ1WN0F6WP 6RN+XMowia3XYyd2ff8BFIctrvxQRlcnYezb8EY4cXIS+87el0s1a+8bN04K0k59z7cPFGL8C2T+ dIKZPRhkI2dKg52xwAmfszERfnqcFzWZ2fnQE8id2U70aX6ihB3gNrPPwnbXO5uHJ1Rl7bhgOMAJ fOXawXSiYNTD/SaAAWeTyFQsLgHxRUHwWLIxeBL8OtdxAW/F4ka6L8KbJ/BiZkNs4eDj9V3ky8hP 3mf20VE6OBcr/8r3PKHCMJsYLn1P/LMU4WMsvO34j0sMqlSiKzdhAupPpuj3IPYu3lyxVkEFeKGj fHqrFgRKbFzAQYU2/lYbPVBCxcF/M8i+9tpelKVwVOJYqH8jEO560xpooHZU3ADKZek6bC9i1F7E uL0IDN52tpi21wLosq1HdGwUopLu1ES6OviKdhgeNYSsWlGJIuOKStAYV1RixLiiEhLGFZUIMK6o ONy4ouJf44qKOxtXuA4SVzmKhmgNUmI/+Ekg1PpGAuq3pLq0uFh3TuQ8R856aalSWla7iSznm6eE pirS6cfJcp5EMnw2WgTqsUrdD3PyxWq9dGIfzjAG0w9amv7BeQqE9Xfke0aosQ6+yp7wKLK3hN0F jiuWMvBEZD2IN+1Rxvpbac31ucKoXEu33vjPy8SaL7HkGsEmNUavt4SWf+PHaIPGZJrUbMUknOTD SU1c1gv/Jjx/s8pMQziNTDSfM9xcgkAVm000Ui6qZpdxF8oBlC3ocsHfAson6K+LC1++8jFFf12K PiifoL8uXB+Uj/HR7F8205w70YtFSq8pO3fPZCCjxSbIcsBID1N2BucQtC2wkziXTyKJKTuDd+jT OnFd+OZGiVO2L7Y8ykBhu0OjYLLR98J2Son2+owdsR1UwhowsNpxLQOITbr34qev/tTELQbI0vlZ 05jOwxoLQAkinaF/bGRiPkMPajiPinIdwp9LYmHR0IY1mUdFS+NJ1zuGj9sVPgZQuwrIAGpXChlA NfFRf+bJayIdpH1xZGCxaTmvYhh2ZGaespk5B+KVgI7qJuH8VZO99bFQrZsEFLaDqnWTgML2TqmW 5XWTgNVZ3SRg1VSNeh8VOZWzKXbdLALlJwHCjrohbwJQN+RNAOqGvAlA7cnbDNIdeROw2NyQc2qR vAlAOIXzVT8HKpI3AYjNDZrt0r8ZZXUPpTR/ue2AvAkobAdVyZuAwvZOHXkTsHAKJxJKWDnVEbC6 IW8CUDfkTQDqhrwJQN2QNwGoG/ImALUnbzNId+RNwGJzQ86pRfImALHpIQcqkjcBCKdwuGEveWPW /3byJqCwHVQlbwIK2zslQs0PqQQstoNKWDl5E7BwCicYUiwMbs6muiFvwo66IW8CUDfkTQDqhrwJ QO3J2wzSHXkTsNjckHNqkbwJQGx6yIGK5E0AYnPDXvLGZPzt5E1AYTuoSt4EFLZ3SoSa8xwBi+2g ElZO3gQsjJfW5E0AwikfBeLsqBvyJuyoG/ImAHVD3gSg9uRtBumOvAlYbG7IObVI3gQgNj3kQEXy JgCxuWEveWOO/HbyJqCwHVQlbwIK2zslQs3Jm4DFdlAJK6c6AlY35E0AwsBsTd4EIJzyASDMIo6b uiFvwo66IW8CUHvyNoN0R94ELDY35JxaJG8CEJsecqAieROA2Nyg7tnCfVHy9dR+TRBQ7xlktxrI gIMaJ1EB0w3ei4WIoHdJmG+HtATMdshArAkP6hZPpXyxaBe7hzUBQobynwJf4pXud7ylU2hEGE4b Ogkevp9ZV7oBprIOQ2r35g10DxXbhbAhSTUOgZ7J+xpadtbZzXIlDVqJVCdX2gKEnWfX0BCUtvWo xarPByZiG1U6jP+3TVHxd+hy87I5vd7FqH8xHqcNTiiyqoS7BC3cREQNSqRX4fPbSXgRvqxSzX15 VGvbrJEpl96b356u9Lyd25swBDas0TtRd8QbdMY75I3Ws3CK9ndVQWjbQpVMGub3rXB28hTo1jP4 5TpUroBGP/zfmna59+ZosfD+TATBNwcb1RK5rp8aiEWi3/Z7WCdLop5kkshV/foIr5GjJvsEgImL yuhHtYl624eb1ZOIoA+swf63UtUX7FfbDVx9I1a7O8880B7jmmr1et124jlPoytIuAj6/l4qCm3f oEpPDvThfVdtdajP3sg36L57MMPJu2k5GfUuBxc6DqBpUyWSq67zZqA9+Lm8VLbFDkuso9Aumm9B 42ezVWsoZAIMglFQXL1xdhhna5yHbzd3kdB9rInwqjaCCdbODFShZKsiJylTZwpelcSfAePozbfJ ul2Tjs9G56enWmra/AkEgW2x8JlpojJJmXUtY+jL7E/0/LoJ/cNh2sBaN2MwHR02yxhOJqPmGaPx Ya95xnh0ZNB0MuobNJ0OBwZNDwcjg6ZgMIOm/V4POmwxNupM1u8dHRl07fePgOeapQxAXcOU4XRk Unc0GaO6kDCgL0ZLXG4ZBiEQMfUtw2nOwcdOp/XMPpObyIceo1vxqiRkXdYz+8FfQVM5DFv3cuXg RWHssq4scSFKi1LQJIX26tQC8a9CezWOmYlghyXdTQwFZK7OJuXjx97cLVd+NWmHHqxtipc4op5P mxhDe5rMFvXUkLLt/9pVGXvHX/4DAAD//wMAUEsBAi0AFAAGAAgAAAAhAN38lTdmAQAAIAUAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MA AABOAgAACwAAAAAAAAAAAAAAAACfAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA1mSzUfoA AAAxAwAAHAAAAAAAAAAAAAAAAADDBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQIt ABQABgAIAAAAIQB8fg+qFwwAAD5AAAARAAAAAAAAAAAAAAAAAP8IAAB3b3JkL2RvY3VtZW50Lnht bFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAEUVAAB3b3JkL3RoZW1l L3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA7CEdqA8DAAA8BwAAEQAAAAAAAAAAAAAAAAAOHAAA d29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABSNqIqQBAAATBQAAEgAAAAAAAAAAAAAA AABMHwAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAK21YLyqAQAA9ggAABQAAAAA AAAAAAAAAAAAICEAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAETaoTn3AQAA 9gMAABAAAAAAAAAAAAAAAAAA/CIAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAlZKA tHcBAADlAgAAEQAAAAAAAAAAAAAAAAApJgAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAA ACEAJzrSKIUIAAC7QAAADwAAAAAAAAAAAAAAAADXKAAAd29yZC9zdHlsZXMueG1sUEsFBgAAAAAL AAsAwQIAAIkxAAAAAA== --_004_DF7F294AF4153D498141CBEFADB17704C5417D0CBFEMBX01WFjnprn_-- From rajiva@cisco.com Thu Sep 22 13:50:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5789321F8B90 for ; Thu, 22 Sep 2011 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJpuvmNws47g for ; Thu, 22 Sep 2011 13:50:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8281D21F8B8E for ; Thu, 22 Sep 2011 13:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1477; q=dns/txt; s=iport; t=1316724771; x=1317934371; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=oVOrGukCSSPU1Xcgi1ou4Qii9OC/0Nlr6SXQHVnvucQ=; b=ZHd5/f7pS4SesROCdGICBQOc0qNHsXIoKXWvzDnofGhGAEM01LljX8yL 1FzTESLl2PjVzFyIQzZXgskr7qCtL9MAoR/KjPfWqx5j5QrmrGEqi6vvu XnhNK1X6TVhLLKIC2wMj2klFzIxPeGpSRaGK7/Q6kImkYoU9ufAmqFBnw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4HACOfe06tJV2a/2dsb2JhbABCmU6ONHiBVQEBAxIBHQpRASoGGAdXAQQbEwedTYEmAZ4phh1gBIdxkQeMJQ X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="23405434" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 22 Sep 2011 20:52:49 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8MKqnwT006367 for ; Thu, 22 Sep 2011 20:52:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 15:52:49 -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: Thu, 22 Sep 2011 15:52:48 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C05F95305@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mpls-ldp-ipv6 : Issue needs WG input Thread-Index: Acx5aZZnrOyzpgT0TMaTSLiOSmUK6Q== From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 22 Sep 2011 20:52:49.0758 (UTC) FILETIME=[96ED8FE0:01CC7969] Subject: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 20:50:19 -0000 While this document passed the WGLC without any comments, we wanted to bring up an issue to seek your feedback. =09 The issue is that the current LDP spec rfc5036 allows an LDP peer to advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 in section 1.1.1 of ldp-ipv6 document.=20 While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 hello adj, in line with existing 'targeted adj check for PW binding advertisement'), we want to pose the following questions: (1) is this a reasonable issue to be fixed?=20 (2) is ldp-ipv6 document the right place to fix it? (3) is the solution highlighted in section 7 a reasonable solution, if you answered yes to both 1 and 2? You may answer simple yes/no to each Q, if you like. Cheers, Rajiv * Consequently, an LDP peer advertising IPv4 bindings to an LDP IPv6 only peer, which doesn't have IPv4 any more (out in the future, of course). ** 7. Label Distribution This document specifies that an LSR should advertise and receive both IPv4 and IPv6 label bindings from and to the peer, only if it has valid IPv4 and IPv6 Hello Adjacencies for that peer, as specified in section 6.2.=09 This means that the LSR must not advertise any IPv6 label bindings to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency existed for that peer (and vice versa). From Kannan.Sampath@aricent.com Thu Sep 22 14:07:55 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1C1F0C8D for ; Thu, 22 Sep 2011 14:07:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgYmypCS6qvG for ; Thu, 22 Sep 2011 14:07:54 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [180.151.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 375A01F0C53 for ; Thu, 22 Sep 2011 14:07:53 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 2761436B62; Fri, 23 Sep 2011 02:34:43 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 10E7736B5F; Fri, 23 Sep 2011 02:34:43 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.132]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Fri, 23 Sep 2011 02:40:23 +0530 From: Kannan KV Sampath To: "'tnadeau@lucidvision.com'" , "'wnattras@telcordia.com'" Date: Fri, 23 Sep 2011 02:40:22 +0530 Thread-Topic: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt Thread-Index: Acx5T4M2fMEL4OYpTqeM6eymAyS2MAAHIeDo Message-ID: <04EDFA4923CA7849A51A812953FF87360205694757@GUREXMB02.ASIAN.AD.ARICENT.COM> 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_04EDFA4923CA7849A51A812953FF87360205694757GUREXMB02ASIA_" MIME-Version: 1.0 Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:07:55 -0000 --_000_04EDFA4923CA7849A51A812953FF87360205694757GUREXMB02ASIA_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkgdG8gdGhpcyBlbWFpbCwgYW5kIHRvIG15 IG90aGVyIGVtYWlsLg0KSXMgaXQgcG9zc2libGUgdG8gZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1l YW4gYnkgIlRoZSBpbnRlcm5hbCBkZXZpY2UgaGFzIHRoZSBmcmVlZG9tIHRvIGNoYW5nZSBhbnl0 aGluZyBpdCBsaWtlcyI/DQoNCldoZW4gd2UgaGF2ZSB0aGUgc3RhbmRhcmQgSUVURiBNSUIgd2l0 aCByZWFkLXdyaXRlLCBpdCBnaXZlcyBhbiB1bmlmb3JtaXR5IGFuZCBzdGFuZGFyZGl6YXRpb24g aW4gY29uZmlndXJhdGlvbiBhbmQgaXQgZ2l2ZXMgYWRkaXRpb25hbCBzdXBwb3J0IHRvIHRoZSBw cm90b2NvbCBSRkNzIHRvIG1ha2UgaXQgY2xlYXIgb24gd2hhdCBhcmUgY29uZmlndXJhYmxlIHBh cmFtZXRlcnMgdG8gdHVuZSwgYW5kIHdoYXQgYXJlIG5vdCB0dW5lLWFibGUuIFRoaXMga2luZCBv ZiB1bmlmb3JtaXR5IChpZiBkaWZmZXJlbnQgdmVuZG9yIGVxdWlwbWVudHMgc3VwcG9ydCB0aGUg c2FtZSBzdGFuZGFyZCByZWFkLXdyaXRlIE1JQikgd2lsbCBoZWxwIChzZXJ2aWNlIHByb3ZpZGVy cykgaW4gZXZlbiB0aGlua2luZyBvZiBoYXZpbmcgYSBjb21tb24gTk1TIHN5c3RlbSB0byBjb25m aWd1cmUgZXF1aXBtZW50cyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzIGJ5IGhhdmluZyBzaW1wbGUg YWRhcHRlcnMuDQpJZiB3ZSBtYWtlIHRoZW0gYXMgcmVhZC1vbmx5LCB3aWxsIGl0IG5vdCByZXN1 bHQgaW4gZGlmZmVyZW50IHZlbmRvcnMgaW50ZXJwcmV0aW5nIGl0IGRpZmZlcmVudGx5Pw0KDQpU aGFua3MgYW5kIFJlZ2FyZHMsDQpLYW5uYW4NCg0KDQpGcm9tOiBUaG9tYXMgTmFkZWF1IFttYWls dG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDIy LCAyMDExIDExOjE2IFBNDQpUbzogTmF0dHJhc3MsIFdpbGxpYW0gVyA8d25hdHRyYXNAdGVsY29y ZGlhLmNvbT4NCkNjOiAnbXBsc0BpZXRmLm9yZycgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW21wbHNdIFBsYW4gdG8gbWFrZSBkcmFmdC1pZXRmLW1wbHMtdHAtdGUtbWliLTAwLnR4dA0K DQoNCk9uIFNlcCAyMiwgMjAxMSwgYXQgMTo0MSBQTSwgTmF0dHJhc3MsIFdpbGxpYW0gVyB3cm90 ZToNCg0KUmU6ICDigJxUaGVyZSBpcyBhIHBsYW4gdG8gbWFrZSBkcmFmdC1pZXRmLW1wbHMtdHAt dGUtbWliLTAwLnR4dCBiZSBhIHJlYWQtb25seSBNSUIgKGl0IGN1cnJlbnRseSBjb250YWlucyBy ZWxhdGl2ZWx5IGZldyB3cml0ZWFibGUgb2JqZWN0cykuIFRoaXMgaXMgY29tcGF0aWJsZSB3aXRo IG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IE1JQnMgYXJlIG9mdGVuIHVzZWQuIEhvd2V2ZXIsIHRo aXMgYWxzbyB2YXJpZXMgZnJvbSBub3JtYWwgSUVURiBjb252ZW50aW9uIHdoZXJlIE1JQnMgY29u dGFpbiBib3RoIHJlYWQgYW5kIHdyaXRlIG9iamVjdHMuDQoNCldlIHRoZXJlZm9yZSBhcmUgYXNr aW5nIGZvciBjb21tZW50cyBmcm9tIHRoZSBXRyByZWdhcmRpbmcgd2hldGhlciBwZW9wbGUgYXJl IG9rYXkgd2l0aCB1cGRhdGluZyBkcmFmdC1pZXRmLW1wbHMtdHAtdGUtbWliLTAwLnR4dCB0byBi ZSByZWFkIG9ubHku4oCdDQoNCg0KDQpRdWVzdGlvbjogIFdvdWxkIG1ha2luZyB0aGUgTUlCIHJl YWQtb25seSwgIHByZWNsdWRlIHRoZSBhYmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9ycyB0byBk ZWNsYXJlIHN0YW5kYXJkaXplZCBuYW1lcyB3aXRoaW4gdGhlIE1JQiBmb3IgdGhlaXIgdHVubmVs cz8gIEkgYXNrLCAgYmVjYXVzZSBJIGJlbGlldmUgbmV0d29yayBvcGVyYXRvcnMgd2lsbCB3YW50 IHRvIGFzc2lnbiAibmV0d29yayBsZXZlbCIgbmFtZXMgdGhhdCB3aWxsIGZpdC8oYW5kIGJlIHVz ZWQpIGJ5IHRoZWlyIGV4aXN0aW5nIG9wZXJhdGlvbnMgc3VwcG9ydCBzeXN0ZW1zLg0KDQpObywg bm90IGF0IGFsbCBhc3N1bWluZyB0aGF0IHlvdSBjb25maWd1cmVkIHRoZSBURSBmdW5jdGlvbnMg dXNpbmcgYSBkaWZmZXJlbnQgbWVhbnMgc3VjaCBhcyBOZXRjb25mL1hNTC93ZWIgc2VydmljZXMv Q0xJL2V0Yy4uLiAgVGhlIE1JQiBiZWluZyByZWFkLW9ubHkgaXMgb25seSBmcm9tIHRoZSBleHRl cm5hbCBvYnNlcnZlcidzIHBvaW50IG9mIHZpZXcuIFRoZSBpbnRlcm5hbCBkZXZpY2UgaGFzIHRo ZSBmcmVlZG9tIHRvIGNoYW5nZSBhbnl0aGluZyBpdCBsaWtlcy4NCg0KLS1Ub20NCg0KDQoNCg0K DQpCaWxsIE5hdHRyYXNzDQpUZWxjb3JkaWENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KDQoNCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClBsZWFzZSByZWZl ciB0byBodHRwOi8vd3d3LmFyaWNlbnQuY29tL2xlZ2FsL2VtYWlsX2Rpc2NsYWltZXIuaHRtbA0K Zm9yIGltcG9ydGFudCBkaXNjbG9zdXJlcyByZWdhcmRpbmcgdGhpcyBlbGVjdHJvbmljIGNvbW11 bmljYXRpb24uDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= --_000_04EDFA4923CA7849A51A812953FF87360205694757GUREXMB02ASIA_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxiYXNlIGhyZWY9IngtbXNnOi8vMjEzLyI+DQo8 L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQo8 Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgVG9tLDxicj4NCjxi cj4NClRoYW5rcyBmb3IgeW91ciByZXBseSB0byB0aGlzIGVtYWlsLCBhbmQgdG8gbXkgb3RoZXIg ZW1haWwuPGJyPg0KSXMgaXQgcG9zc2libGUgdG8gZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4g YnkgJnF1b3Q7VGhlIGludGVybmFsIGRldmljZSBoYXMgdGhlIGZyZWVkb20gdG8gY2hhbmdlIGFu eXRoaW5nIGl0IGxpa2VzJnF1b3Q7Pzxicj4NCjxicj4NCldoZW4gd2UgaGF2ZSB0aGUgc3RhbmRh cmQgSUVURiBNSUIgd2l0aCByZWFkLXdyaXRlLCBpdCBnaXZlcyBhbiB1bmlmb3JtaXR5IGFuZCBz dGFuZGFyZGl6YXRpb24gaW4gY29uZmlndXJhdGlvbiBhbmQgaXQgZ2l2ZXMgYWRkaXRpb25hbCBz dXBwb3J0IHRvIHRoZSBwcm90b2NvbCBSRkNzIHRvIG1ha2UgaXQgY2xlYXIgb24gd2hhdCBhcmUg Y29uZmlndXJhYmxlIHBhcmFtZXRlcnMgdG8gdHVuZSwgYW5kIHdoYXQgYXJlIG5vdCB0dW5lLWFi bGUuIFRoaXMNCiBraW5kIG9mIHVuaWZvcm1pdHkgKGlmIGRpZmZlcmVudCB2ZW5kb3IgZXF1aXBt ZW50cyBzdXBwb3J0IHRoZSBzYW1lIHN0YW5kYXJkIHJlYWQtd3JpdGUgTUlCKSB3aWxsIGhlbHAg KHNlcnZpY2UgcHJvdmlkZXJzKSBpbiBldmVuIHRoaW5raW5nIG9mIGhhdmluZyBhIGNvbW1vbiBO TVMgc3lzdGVtIHRvIGNvbmZpZ3VyZSBlcXVpcG1lbnRzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMg YnkgaGF2aW5nIHNpbXBsZSBhZGFwdGVycy48YnI+DQpJZiB3ZSBtYWtlIHRoZW0gYXMgcmVhZC1v bmx5LCB3aWxsIGl0IG5vdCByZXN1bHQgaW4gZGlmZmVyZW50IHZlbmRvcnMgaW50ZXJwcmV0aW5n IGl0IGRpZmZlcmVudGx5Pzxicj4NCjxicj4NClRoYW5rcyBhbmQgUmVnYXJkcyw8YnI+DQpLYW5u YW48YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+OiBUaG9tYXMgTmFkZWF1 IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVGh1 cnNkYXksIFNlcHRlbWJlciAyMiwgMjAxMSAxMToxNiBQTTxicj4NCjxiPlRvPC9iPjogTmF0dHJh c3MsIFdpbGxpYW0gVyAmbHQ7d25hdHRyYXNAdGVsY29yZGlhLmNvbSZndDsgPGJyPg0KPGI+Q2M8 L2I+OiAnbXBsc0BpZXRmLm9yZycgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPlN1Ympl Y3Q8L2I+OiBSZTogW21wbHNdIFBsYW4gdG8gbWFrZSBkcmFmdC1pZXRmLW1wbHMtdHAtdGUtbWli LTAwLnR4dCA8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGRp dj5PbiBTZXAgMjIsIDIwMTEsIGF0IDE6NDEgUE0sIE5hdHRyYXNzLCBXaWxsaWFtIFcgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3Jk ZXItY29sbGFwc2U6IHNlcGFyYXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0 LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVy dGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBu b25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZm9udC1zaXplOiBtZWRpdW07ICI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIiBzdHlsZT0icGFn ZTogU2VjdGlvbjE7ICI+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDE0cHQ7ICI+UmU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PiZuYnNwO+KAnFRoZXJlIGlzIGEgcGxhbiB0byBtYWtlIGRyYWZ0LWlldGYtbXBscy10cC10ZS1t aWItMDAudHh0IGJlIGEgcmVhZC1vbmx5IE1JQiAoaXQgY3VycmVudGx5IGNvbnRhaW5zIHJlbGF0 aXZlbHkgZmV3IHdyaXRlYWJsZSBvYmplY3RzKS4gVGhpcw0KIGlzIGNvbXBhdGlibGUgd2l0aCBt eSB1bmRlcnN0YW5kaW5nIG9mIGhvdyBNSUJzIGFyZSBvZnRlbiB1c2VkLiBIb3dldmVyLCB0aGlz IGFsc28gdmFyaWVzIGZyb20gbm9ybWFsIElFVEYgY29udmVudGlvbiB3aGVyZSBNSUJzIGNvbnRh aW4gYm90aCByZWFkIGFuZCB3cml0ZSBvYmplY3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyAiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyAiPldlIHRoZXJlZm9y ZSBhcmUgYXNraW5nIGZvciBjb21tZW50cyBmcm9tIHRoZSBXRyByZWdhcmRpbmcgd2hldGhlciBw ZW9wbGUgYXJlIG9rYXkgd2l0aCB1cGRhdGluZyBkcmFmdC1pZXRmLW1wbHMtdHAtdGUtbWliLTAw LnR4dCB0byBiZSByZWFkIG9ubHku4oCdPG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsgIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4N ClF1ZXN0aW9uOiZuYnNwOyBXb3VsZCBtYWtpbmcgdGhlIE1JQiByZWFkLW9ubHksJm5ic3A7IHBy ZWNsdWRlIHRoZSBhYmlsaXR5IGZvciBuZXR3b3JrIG9wZXJhdG9ycyB0byBkZWNsYXJlIHN0YW5k YXJkaXplZCBuYW1lcyB3aXRoaW4gdGhlIE1JQiBmb3IgdGhlaXIgdHVubmVscz8mbmJzcDsgSSBh c2ssJm5ic3A7IGJlY2F1c2UgSSBiZWxpZXZlIG5ldHdvcmsgb3BlcmF0b3JzIHdpbGwgd2FudCB0 byBhc3NpZ24gJnF1b3Q7bmV0d29yayBsZXZlbCZxdW90OyBuYW1lcyB0aGF0IHdpbGwgZml0Lyhh bmQNCiBiZSB1c2VkKSBieSB0aGVpciBleGlzdGluZyBvcGVyYXRpb25zIHN1cHBvcnQgc3lzdGVt cy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUt c3BhY2U6cHJlIj48L3NwYW4+Tm8sIG5vdCBhdCBhbGwgYXNzdW1pbmcgdGhhdCB5b3UgY29uZmln dXJlZCB0aGUgVEUgZnVuY3Rpb25zIHVzaW5nIGEgZGlmZmVyZW50IG1lYW5zIHN1Y2ggYXMgTmV0 Y29uZi9YTUwvd2ViIHNlcnZpY2VzL0NMSS9ldGMuLi4gJm5ic3A7VGhlIE1JQiBiZWluZyByZWFk LW9ubHkgaXMgb25seSBmcm9tIHRoZSBleHRlcm5hbCBvYnNlcnZlcidzIHBvaW50DQogb2Ygdmll dy4gVGhlIGludGVybmFsIGRldmljZSBoYXMgdGhlIGZyZWVkb20gdG8gY2hhbmdlIGFueXRoaW5n IGl0IGxpa2VzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LS1Ub208L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N Cjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRp b25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPg0KPGRpdiBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJTZWN0 aW9uMSIgc3R5bGU9InBhZ2U6IFNlY3Rpb24xOyAiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ DQo8bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+DQo8bzpwPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+DQpCaWxsIE5hdHRyYXNzPG86 cD48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPg0KVGVsY29yZGlhPG86cD48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHN0eWxlPSJjb2xv cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5 IiBzaXplPSIyIj48YnI+DQo8YnI+DQo8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K UGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cuYXJpY2VudC5jb20vbGVnYWwvZW1haWxfZGlzY2xh aW1lci5odG1sPGJyPg0KZm9yIGltcG9ydGFudCBkaXNjbG9zdXJlcyByZWdhcmRpbmcgdGhpcyBl bGVjdHJvbmljIGNvbW11bmljYXRpb24uPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_04EDFA4923CA7849A51A812953FF87360205694757GUREXMB02ASIA_-- From tnadeau@lucidvision.com Thu Sep 22 14:58:32 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23D011E80C5 for ; Thu, 22 Sep 2011 14:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsGc+LhWMC-y for ; Thu, 22 Sep 2011 14:58:31 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 897AC11E80AA for ; Thu, 22 Sep 2011 14:58:31 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A7C3C1E54759; Thu, 22 Sep 2011 18:01:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_92532C5C-8F8F-43B6-B322-5730A878954B" From: Thomas Nadeau In-Reply-To: <04EDFA4923CA7849A51A812953FF87360205694757@GUREXMB02.ASIAN.AD.ARICENT.COM> Date: Thu, 22 Sep 2011 18:01:03 -0400 Message-Id: <5C90520E-E3F5-4DBF-8A65-01B5B93048F5@lucidvision.com> References: <04EDFA4923CA7849A51A812953FF87360205694757@GUREXMB02.ASIAN.AD.ARICENT.COM> To: Kannan KV Sampath X-Mailer: Apple Mail (2.1244.3) Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 21:58:33 -0000 --Apple-Mail=_92532C5C-8F8F-43B6-B322-5730A878954B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 22, 2011, at 5:10 PM, Kannan KV Sampath wrote: > Hi Tom, >=20 > Thanks for your reply to this email, and to my other email. > Is it possible to elaborate on what you mean by "The internal device = has the freedom to change anything it likes"? >=20 > When we have the standard IETF MIB with read-write, it gives an = uniformity and standardization in configuration That is a myth because SNMP is a poor model for configuration = management. This is precisely why most real production networks do not = use it, and is precisely why Netconf was invented. > and it gives additional support to the protocol RFCs to make it clear = on what are configurable parameters to tune, and what are not tune-able. That is also a myth because in %100 of the cases, vendors = produce proprietary extensions and features related to the objects you = find in that MIB. This means that you are then back to square one with = regard to the "uniformity" claim because you have to do special things = for different devices - even from the same vendor! > This kind of uniformity (if different vendor equipments support the = same standard read-write MIB) will help (service providers) in even = thinking of having a common NMS system to configure equipments from = different vendors by having simple adapters. > If we make them as read-only, will it not result in different vendors = interpreting it differently? That is only true in terms of monitoring. SNMP is well suited = for high volume, high rate polling. It fails miserably in terms of = provisioning, and this is why both vendors have really not implemented = it in a writable way, nor have SPs or enterprises really used SNMP for = provisioning capabilities. I welcome comments from folks at operators on = this, but it was my experience when I worked at an operator that SNMP = provided no benefit in terms of provisioning in general; that is why we = used each vendors' CLI or Netconf/XML interface for provisioning. --Tom >=20 > Thanks and Regards, > Kannan >=20 > =20 > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Thursday, September 22, 2011 11:16 PM > To: Nattrass, William W =20 > Cc: 'mpls@ietf.org' =20 > Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt=20 > =20 >=20 > On Sep 22, 2011, at 1:41 PM, Nattrass, William W wrote: >=20 >> Re: =93There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only MIB (it currently contains relatively few writeable objects). = This is compatible with my understanding of how MIBs are often used. = However, this also varies from normal IETF convention where MIBs contain = both read and write objects. >> =20 >> We therefore are asking for comments from the WG regarding whether = people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be = read only.=94 >> =20 >> =20 >> =20 >> Question: Would making the MIB read-only, preclude the ability for = network operators to declare standardized names within the MIB for their = tunnels? I ask, because I believe network operators will want to = assign "network level" names that will fit/(and be used) by their = existing operations support systems. >=20 > No, not at all assuming that you configured the TE functions using a = different means such as Netconf/XML/web services/CLI/etc... The MIB = being read-only is only from the external observer's point of view. The = internal device has the freedom to change anything it likes. >=20 > --Tom >=20 >=20 >=20 >=20 >> =20 >> Bill Nattrass >> Telcordia >> =20 >> =20 >> =20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 >=20 > = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Please refer to http://www.aricent.com/legal/email_disclaimer.html > for important disclosures regarding this electronic communication. > = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --Apple-Mail=_92532C5C-8F8F-43B6-B322-5730A878954B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Tom,

Thanks for your reply to this email, and to my other email.
Is it possible to elaborate on what you mean by "The internal device has = the freedom to change anything it likes"?

When we have the standard IETF MIB with read-write, it gives an = uniformity and standardization in configuration =

That is a = myth because SNMP is a poor model for configuration management. This is = precisely why most real production networks do not use it, and is = precisely why Netconf was invented.

and it gives additional support to the protocol = RFCs to make it clear on what are configurable parameters to tune, and = what are not tune-able. =

That is = also a myth because in %100 of the cases, vendors produce proprietary = extensions and features related to the objects you find in that MIB. = This means that you are then back to square one with regard to the = "uniformity" claim because you have to do special things for different = devices - even from the same vendor!

This kind of uniformity (if different vendor equipments support the same = standard read-write MIB) will help (service providers) in even thinking = of having a common NMS system to configure equipments from different = vendors by having simple adapters.
If we make them as read-only, will it not result in different vendors = interpreting it = differently?

That is = only true in terms of monitoring.  SNMP is well suited for high = volume, high rate polling.  It fails miserably in terms of = provisioning, and this is why both vendors have really not implemented = it in a writable way, nor have SPs or enterprises really used SNMP for = provisioning capabilities. I welcome comments from folks at operators on = this, but it was my experience when I worked at an operator that SNMP = provided no benefit in terms of provisioning in general; that is why we = used each vendors' CLI or Netconf/XML interface for = provisioning.

= --Tom



Thanks and Regards,
Kannan

 
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Thursday, September 22, 2011 11:16 PM
To: Nattrass, William W <wnattras@telcordia.com> =
Cc: 'mpls@ietf.org' <mpls@ietf.org>
Subject: Re: [mpls] Plan to make draft-ietf-mpls-tp-te-mib-00.txt =
 

On Sep 22, 2011, at 1:41 PM, Nattrass, William W wrote:

Re:  =93There = is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB = (it currently contains relatively few writeable objects). This is compatible with my understanding of how MIBs are often used. = However, this also varies from normal IETF convention where MIBs contain = both read and write objects.
 
We therefore are asking for comments = from the WG regarding whether people are okay with updating = draft-ietf-mpls-tp-te-mib-00.txt to be read = only.=94
 
 
 
Question:  Would making the MIB read-only,  preclude the = ability for network operators to declare standardized names within the = MIB for their tunnels?  I ask,  because I believe network = operators will want to assign "network level" names that will fit/(and be used) by their existing operations support systems.

No, = not at all assuming that you configured the TE functions using a = different means such as Netconf/XML/web services/CLI/etc...  The = MIB being read-only is only from the external observer's point of view. The internal device has the freedom to change anything it = likes.

--Tom




 
Bill Nattrass
Telcordia
 
_______________________________________________
mpls mailing list
mpls@ietf.org



= =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Please refer to http://www.ari= cent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
= =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

= --Apple-Mail=_92532C5C-8F8F-43B6-B322-5730A878954B-- From lilianyuan1@gmail.com Thu Sep 22 18:45:40 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1921F8C5D for ; Thu, 22 Sep 2011 18:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OchyId73VfcQ for ; Thu, 22 Sep 2011 18:45:40 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id D664821F8C47 for ; Thu, 22 Sep 2011 18:45:39 -0700 (PDT) Received: by gwj16 with SMTP id 16so3018896gwj.15 for ; Thu, 22 Sep 2011 18:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+mFkEH/CEuWqPwKKLS/SnO9Kxl/V29tCq2OD9R375/w=; b=JZIY1K7ZYf1h9caUZB2f2lwmc9heToBUF5OaORQuOsAamLygAIvWr0CDtN51+bPs4w yeTzfD1LBliJ71SL91MGw9BYpBKTYpQQRwvWhPYI0HzhVplEGGss7X4dFXtTpGqI3i/7 /e7h5saBcbhyyuL3prcIP3V9nodXsik/CG3oQ= MIME-Version: 1.0 Received: by 10.150.69.18 with SMTP id r18mr3183397yba.438.1316742491532; Thu, 22 Sep 2011 18:48:11 -0700 (PDT) Received: by 10.150.138.6 with HTTP; Thu, 22 Sep 2011 18:48:11 -0700 (PDT) In-Reply-To: <4E78D844.4090809@pi.nu> References: <4E78D844.4090809@pi.nu> Date: Fri, 23 Sep 2011 09:48:11 +0800 Message-ID: From: LI Lianyuan To: Loa Andersson Content-Type: multipart/alternative; boundary=000e0cd5916a77efac04ad9200bb Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 01:45:40 -0000 --000e0cd5916a77efac04ad9200bb Content-Type: text/plain; charset=ISO-8859-1 Support. I am an author of the draft. MPLS MT will be great helpful for our network. 2011/9/21 Loa Andersson > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-**topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --000e0cd5916a77efac04ad9200bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.
I am an author of the draft.=A0MPLS MT=A0will be great helpful for our= network.


=A0
2011/9/21 Loa Andersson <loa@pi.nu>
Working Group,

this is to= start a two week poll to see if there is support to make

=A0 =A0LDP= Extension for Multi Topology Support
=A0 =A0draft-zhao-mpls-ldp-multi-topology-02.txt

an MPLS work= ing group document.

Send your opinions to mpls@ietf.org

Please remember that it i= s particular important that you include a
technical motivation if you don't want the ID to become a
working gr= oup document.

The poll ends Wednesday Oct 5, 2011.

/Loa
fo= r the MPLS wg co-chairs


--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 +46 767 72 92 13
__________________________= _____________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls
=

--000e0cd5916a77efac04ad9200bb-- From jie.dong@huawei.com Thu Sep 22 19:17:46 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F341F0C43 for ; Thu, 22 Sep 2011 19:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlpiLB2FzQrb for ; Thu, 22 Sep 2011 19:17:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CDA901F0C40 for ; Thu, 22 Sep 2011 19:17:45 -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 <0LRY00188EHUYI@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 23 Sep 2011 10:20:18 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY009O2EHUAO@szxga04-in.huawei.com> for mpls@ietf.org; Fri, 23 Sep 2011 10:20:18 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC71033; Fri, 23 Sep 2011 10:19:26 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 10:19:20 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.46]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 10:19:23 +0800 Date: Fri, 23 Sep 2011 02:19:22 +0000 From: Jie Dong In-reply-to: <4E78D844.4090809@pi.nu> X-Originating-IP: [10.108.4.55] To: Loa Andersson , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Message-id: <76CD132C3ADEF848BD84D028D243C9270B7AB550@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-index: AQHMd8FYQ7D5Um8mSUaVVeW0/wP3lZVaPqxg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E78D844.4090809@pi.nu> Subject: Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 02:17:46 -0000 Yes/support. Best regards, Jie > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Wednesday, September 21, 2011 2:16 AM > To: mpls-chairs@tools.ietf.org; mpls@ietf.org > Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt > an mpls wg document > > Working Group, > > this is to start a two week poll to see if there is support to make > > LDP Extension for Multi Topology Support > draft-zhao-mpls-ldp-multi-topology-02.txt > > an MPLS working group document. > > Send your opinions to mpls@ietf.org > > Please remember that it is particular important that you include a > technical motivation if you don't want the ID to become a > working group document. > > The poll ends Wednesday Oct 5, 2011. > > /Loa > for the MPLS wg co-chairs > > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Boris.Zhang@telus.com Thu Sep 22 21:44:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7811E808E for ; Thu, 22 Sep 2011 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38VondAe5+Fl for ; Thu, 22 Sep 2011 21:44:42 -0700 (PDT) Received: from donder.nssi.telus.com (donder.nssi.telus.com [208.38.59.82]) by ietfa.amsl.com (Postfix) with ESMTP id 52F6011E8088 for ; Thu, 22 Sep 2011 21:44:42 -0700 (PDT) DomainKey-Signature: s=donder.nssi; d=telus.com; c=nofws; q=dns; h=X-IronPort-Anti-Spam-Filtered: X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received: Received:From:To:Date:Subject:Thread-Topic:Thread-Index: Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:MIME-Version; b=nSFKcHfJhY5hZaHsRGGk14fdYvgTeerkLVimFiabghHQmnrBmuqER+bS 0xqF0HSIUuZo02gUysBCoL0HghJwQXo9rjollXA/U7uRqgSkACOonMVq5 EqipB7Oy2+fjfMpTqVWUBpZrmmu3RA8MCFb3jQBJVd0nETuqOgvUkYDH2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAYPfE6OP4Bp/2dsb2JhbABDlTySTXiBWi0mOAEMAQgyORQSAQQTCJ0ln02GHWAEmQ6MDQ X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208,217";a="264968233" Received: from unknown (HELO WP40057.corp.ads) ([142.63.128.105]) by donder-o.nssi.telus.com with ESMTP/TLS/AES128-SHA; 23 Sep 2011 04:47:07 +0000 Received: from wp40067.corp.ads ([::1]) by WP40057.corp.ads ([::1]) with mapi; Fri, 23 Sep 2011 00:47:06 -0400 From: Boris Zhang To: "mpls@ietf.org" Date: Fri, 23 Sep 2011 00:47:04 -0400 Thread-Topic: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document Thread-Index: Acx5q9eCTRPj95K1Tpu0KXk0jDwFog== Message-ID: <3CC752382EB88F48ADAC4AF9F478A15303D2432321@WP40067.corp.ads> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_3CC752382EB88F48ADAC4AF9F478A15303D2432321WP40067corpad_" MIME-Version: 1.0 Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 04:44:43 -0000 --_000_3CC752382EB88F48ADAC4AF9F478A15303D2432321WP40067corpad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/Support Boris Zhang TELUS >Working Group, >this is to start a two week poll to see if there is support to make LDP Extension for Multi Topology Support draft-zhao-mpls-ldp-multi-topology-02.txt an MPLS working group document. Send your opinions to mpls@ietf.org Please remember that it is particular important that you include a technica= l motivation if you don't want the ID to become a working group document. The poll ends Wednesday Oct 5, 2011. /Loa for the MPLS wg co-chairs --_000_3CC752382EB88F48ADAC4AF9F478A15303D2432321WP40067corpad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes/Support
 
Boris Zhang
TELUS
 
>Working Group,
 
>this is to start a two week poll to see if there is support to mak= e
 
     LDP Extension for Multi Topology Support
     draft-zhao-mpls-ldp-multi-topology-02.txt
 
an MPLS working group document.
 
Send your opinions to mpls@ietf.org
 
Please remember that it is particular important that you include a tec= hnical motivation if you don't want the ID to become a working group docume= nt.
 
The poll ends Wednesday Oct 5, 2011.
 
/Loa
for the MPLS wg co-chairs
 
 
 --_000_3CC752382EB88F48ADAC4AF9F478A15303D2432321WP40067corpad_-- From prvs=6248861cdc=edwin.mallette@bhnis.com Sat Sep 24 07:26:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813CF21F8A6F for ; Sat, 24 Sep 2011 07:26:12 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hm6CuoP-H3o for ; Sat, 24 Sep 2011 07:26:11 -0700 (PDT) Received: from mx2.mybrighthouse.com (MX3.mybrighthouse.com [209.16.122.105]) by ietfa.amsl.com (Postfix) with ESMTP id A296621F8A58 for ; Sat, 24 Sep 2011 07:26:11 -0700 (PDT) Received: from pps.filterd (mx3 [127.0.0.1]) by mx3.mybrighthouse.com (8.14.3/8.14.3) with SMTP id p8OEQQbT020558; Sat, 24 Sep 2011 10:28:46 -0400 Received: from tbstpcas01.corp.local ([10.226.201.190]) by mx3.mybrighthouse.com with ESMTP id 1011k8a5u7-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 24 Sep 2011 10:28:46 -0400 Received: from CNEMAIL.corp.local ([10.225.1.130]) by tbstpcas01.corp.local ([10.226.201.190]) with mapi; Sat, 24 Sep 2011 10:28:45 -0400 From: "Mallette, Edwin" To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" Date: Sat, 24 Sep 2011 10:28:48 -0400 Thread-Topic: [mpls] mpls-ldp-ipv6 : Issue needs WG input Thread-Index: Acx6xkOeE5GOLq7GQ62SVYnSAhzHsA== Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C05F95305@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109240131 Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 14:26:12 -0000 Rajiv, my response is in-line. On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: >While this document passed the WGLC without any comments, we wanted to >bring up an issue to seek your feedback. > >The issue is that the current LDP spec rfc5036 allows an LDP peer to >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 >in section 1.1.1 of ldp-ipv6 document. > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 >hello adj, in line with existing 'targeted adj check for PW binding >advertisement'), we want to pose the following questions: > >(1) is this a reasonable issue to be fixed? [EJM] Yes! > >(2) is ldp-ipv6 document the right place to fix it? [EJM] It's certainly the most expedient. It strikes me that the plan would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is incremented, create a new ID which includes the LDP-IPV6 additions, along with the fix, within the updated LDP Specification. My 2c yes. >(3) is the solution highlighted in section 7 a reasonable solution, if >you answered yes to both 1 and 2? [EJM] Yes. > >You may answer simple yes/no to each Q, if you like. > >Cheers, >Rajiv > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > an LDP IPv6 only peer, which doesn't have IPv4 any more > (out in the future, of course). > > >** >7. Label Distribution > > This document specifies that an LSR should advertise and receive > both IPv4 and IPv6 label bindings from and to the peer, only if it > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > specified in section 6.2. > > This means that the LSR must not advertise any IPv6 label bindings > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > existed for that peer (and vice versa). >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. If you are not th= e intended recipient of this e-mail, please notify the sender immediately b= y return e-mail, purge it and do not disseminate or copy it. From lizhong.jin@zte.com.cn Sun Sep 25 20:08:19 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB6E1F0C3D for ; Sun, 25 Sep 2011 20:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.69 X-Spam-Level: X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qJ8rxKQY2NU for ; Sun, 25 Sep 2011 20:08:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 092081F0C36 for ; Sun, 25 Sep 2011 20:08:17 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621806486374; Mon, 26 Sep 2011 11:08:36 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 75544.2738708033; Mon, 26 Sep 2011 11:10:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8Q3AhM7024889; Mon, 26 Sep 2011 11:10:43 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Edwin.Mallette@bhnis.com, rajiva@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Mon, 26 Sep 2011 11:10:42 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-26 11:10:43, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-26 11:10:43, Serialize complete at 2011-09-26 11:10:43, S/MIME Sign failed at 2011-09-26 11:10:43: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-26 11:10:45, Serialize complete at 2011-09-26 11:10:45 Content-Type: multipart/alternative; boundary="=_alternative 001175F048257917_=" X-MAIL: mse02.zte.com.cn p8Q3AhM7024889 Cc: mpls@ietf.org Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 03:08:19 -0000 This is a multipart message in MIME format. --=_alternative 001175F048257917_= Content-Type: text/plain; charset="US-ASCII" Hi Rajiv, I think it is reasonable, but would be preferred to add "why". If we don't have this restriction, the peer LSR which may not enable LDPv6 would receive IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if there is no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based IPv6 LSP work. I have additional comment for the text of section 6.1: - An LSR should prefer the LDP/TCP connection over IPv6 for a new LDP session with a remote LSR, if it has both IPv4 and IPv6 hello adjacencies for the same LDP Identifier (over a dual- stack interface, or two or more single-stack IPv4 and IPv6 interfaces). This applies to the section 2.5.2 of RFC5036. - An LSR should prefer the LDP/TCP connection over IPv6 for a new LDP session with a remote LSR, if they attempted two TCP connections using IPv4 and IPv6 transport addresses simultaneously. Such kind of preferrance would make operators a bit hard to predict the TCP connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and IPv4 TCP is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 TCP is till kept. Some day, LSR1 and LSR2 are rebooted, but the session would be changed to IPv6 which is different with the previous. That means the network results would be different after rebooting. Would be better to add a note here to let everyone know that. Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 24 Sep 2011 10:28:48 -0400 > From: "Mallette, Edwin" > To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Rajiv, my response is in-line. > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: > > >While this document passed the WGLC without any comments, we wanted to > >bring up an issue to seek your feedback. > > > >The issue is that the current LDP spec rfc5036 allows an LDP peer to > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 > >in section 1.1.1 of ldp-ipv6 document. > > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 > >hello adj, in line with existing 'targeted adj check for PW binding > >advertisement'), we want to pose the following questions: > > > >(1) is this a reasonable issue to be fixed? > [EJM] Yes! > > > >(2) is ldp-ipv6 document the right place to fix it? > [EJM] It's certainly the most expedient. It strikes me that the plan > would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is > incremented, create a new ID which includes the LDP-IPV6 additions, along > with the fix, within the updated LDP Specification. > My 2c yes. > >(3) is the solution highlighted in section 7 a reasonable solution, if > >you answered yes to both 1 and 2? > [EJM] Yes. > > > >You may answer simple yes/no to each Q, if you like. > > > >Cheers, > >Rajiv > > > > > > > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > > an LDP IPv6 only peer, which doesn't have IPv4 any more > > (out in the future, of course). > > > > > >** > >7. Label Distribution > > > > This document specifies that an LSR should advertise and receive > > both IPv4 and IPv6 label bindings from and to the peer, only if it > > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > > specified in section 6.2. > > > > This means that the LSR must not advertise any IPv6 label bindings > > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > > existed for that peer (and vice versa). > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > -------------------------------------------------------- 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 001175F048257917_= Content-Type: text/html; charset="US-ASCII"
Hi Rajiv,
I think it is reasonable, but would be preferred to add "why". If we don't have this restriction, the peer LSR which may not enable LDPv6 would receive IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if there is no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based IPv6 LSP work.

I have additional comment for the text of section 6.1:
     - An LSR should prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if it has both IPv4 and IPv6
        hello adjacencies for the same LDP Identifier (over a dual-
        stack interface, or two or more single-stack IPv4 and IPv6
        interfaces). This applies to the section 2.5.2 of RFC5036.
     - An LSR should prefer the LDP/TCP connection over IPv6 for a new
        LDP session with a remote LSR, if they attempted two TCP
        connections using IPv4 and IPv6 transport addresses
        simultaneously.
Such kind of preferrance would make operators a bit hard to predict the TCP connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and IPv4 TCP is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 TCP is till kept. Some day, LSR1 and LSR2 are rebooted, but the session would be changed to IPv6 which is different with the previous. That means the network results would be different after rebooting. Would be better to add a note here to let everyone know that.

Regards
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Sep 2011 10:28:48 -0400
> From: "Mallette, Edwin" <Edwin.Mallette@bhnis.com>
> To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "mpls@ietf.org"
>    <mpls@ietf.org>
> Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> Message-ID: <CAA35E90.176BD%edwin.mallette@bhnis.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Rajiv, my response is in-line.
>
> On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
>
> >While this document passed the WGLC without any comments, we wanted to
> >bring up an issue to seek your feedback.
> >
> >The issue is that the current LDP spec rfc5036 allows an LDP peer to
> >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may
> >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3
> >in section 1.1.1 of ldp-ipv6 document.
> >
> >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6
> >hello adj, in line with existing 'targeted adj check for PW binding
> >advertisement'), we want to pose the following questions:
> >
> >(1) is this a reasonable issue to be fixed?
> [EJM] Yes!
> >
> >(2) is ldp-ipv6 document the right place to fix it?
> [EJM] It's certainly the most expedient.  It strikes me that the plan
> would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is
> incremented, create a new ID which includes the LDP-IPV6 additions, along
> with the fix, within the updated LDP Specification.
> My 2c yes.
> >(3) is the solution highlighted in section 7 a reasonable solution, if
> >you answered yes to both 1 and 2?
> [EJM] Yes.
> >
> >You may answer simple yes/no to each Q, if you like.
> >
> >Cheers,
> >Rajiv
> >
> >
> >
> >
> >
> >*      Consequently, an LDP peer advertising IPv4 bindings to
> >       an LDP IPv6 only peer, which doesn't have IPv4 any more
> >       (out in the future, of course).
> >
> >
> >**
> >7. Label Distribution
> >
> >   This document specifies that an LSR should advertise and receive
> >   both IPv4 and IPv6 label bindings from and to the peer, only if it
> >   has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
> >   specified in section 6.2.
> >
> >   This means that the LSR must not advertise any IPv6 label bindings
> >   to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
> >   existed for that peer (and vice versa).
> >_______________________________________________
> >mpls mailing list
> >mpls@ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> 

--------------------------------------------------------
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 001175F048257917_=-- From jie.dong@huawei.com Sun Sep 25 22:07:26 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC1721F848B for ; Sun, 25 Sep 2011 22:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7wdOtnJM8TP for ; Sun, 25 Sep 2011 22:07:26 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DC43921F847F for ; Sun, 25 Sep 2011 22:07:25 -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 <0LS400KLM6CSZQ@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 13:10:04 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS400GET6CSLZ@szxga03-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 13:10:04 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE30465; Mon, 26 Sep 2011 13:10:03 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 26 Sep 2011 13:10:02 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.46]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Mon, 26 Sep 2011 13:09:53 +0800 Date: Mon, 26 Sep 2011 05:09:51 +0000 From: Jie Dong In-reply-to: X-Originating-IP: [10.108.4.55] To: 'Sami Boutros' Message-id: <76CD132C3ADEF848BD84D028D243C9270B7ABECF@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [mpls] draft-ietf-mpls-tp-li-lb-05.txt Thread-index: Acxpm26DifB9XDfnRqS3OneUgv063QKuUTEwAAKpT3AB6DHmwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "mpls@ietf.org" Subject: Re: [mpls] draft-ietf-mpls-tp-li-lb-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 05:07:26 -0000 Hi Sami, Here are some comments on li-lb-05. 1. In Section 1, "The Loopback is a function that enables a MEP to request a MEP or a MIP to enter a loopback state." This indicates loopback is a request from a MEP to a MEP/MIP, but in this document loopback is performed by management plane. Does this mean loopback may also be performed by some other ways, such as in-band OAM or control plane? 2. Section 4, "LI messages may be lost during looping or maintenance operations, thus locking both ends is required, before such operations occur." Does "locking both ends" here mean that both ends should be locked by NMS when loopback or maintenance will be performed? If so, in which case will the LI message be used for locking one end? Best regards, Jie From rajiva@cisco.com Mon Sep 26 07:47:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D61221F8D88 for ; Mon, 26 Sep 2011 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9rGaqq8xrT7 for ; Mon, 26 Sep 2011 07:47:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D871821F8D8B for ; Mon, 26 Sep 2011 07:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5646; q=dns/txt; s=iport; t=1317048617; x=1318258217; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=9yW1B2vYcSWD3F0Wco1h5KnGXfJ1Iz9QieEFt4HQ4SE=; b=BPjxdUj/DCwZL/S/LZ8UMO5WZK0ir1FXhIlRW//zY6fLvr2/jbNTjVnX 1mHdDLKUCzMdfCFz/Zv1TvvGcZFIYPN4Fbgs8QIHS70My/4mClG3G2Nf4 vA5l+IYCusK/hQ3T2nKBF8sqT19P+QizUPbgifdXGlYCPAMT6Dfcft29d o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAASQgE6tJXHB/2dsb2JhbABBmQqPB3iBUwEBAQEDAQEBDwEdCjQLDAQCAQgRAwEBAQEKBhcBBgEmHwkIAQEEARIIEweHXJteAZ4EhitgBIdykQuMJg X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208";a="24050190" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 26 Sep 2011 14:50:16 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p8QEoGeK031974; Mon, 26 Sep 2011 14:50:16 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 09:50:16 -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, 26 Sep 2011 09:50:15 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C06063363@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls-ldp-ipv6 : Issue needs WG input Thread-Index: Acx7+eYlTR+gUwoWRsyeQ6yjJud4GAAYVp1A References: From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 26 Sep 2011 14:50:16.0434 (UTC) FILETIME=[9A96BD20:01CC7C5B] Cc: mpls@ietf.org Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:47:41 -0000 Hi Lizhong, If I follow it right, then your response is=20 1. yes 2. yes 3. yes However, you would like to add some text for further clarity into the rationale. Did I sum up right? Cheers, Rajiv > -----Original Message----- > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > Sent: Sunday, September 25, 2011 11:11 PM > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input >=20 >=20 > Hi Rajiv, > I think it is reasonable, but would be preferred to add "why". If we don't > have this restriction, the peer LSR which may not enable LDPv6 would receive > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if there is > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based IPv6 > LSP work. >=20 > I have additional comment for the text of section 6.1: > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if it has both IPv4 and IPv6 > hello adjacencies for the same LDP Identifier (over a dual- > stack interface, or two or more single-stack IPv4 and IPv6 > interfaces). This applies to the section 2.5.2 of RFC5036. > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if they attempted two TCP > connections using IPv4 and IPv6 transport addresses > simultaneously. > Such kind of preferrance would make operators a bit hard to predict the TCP > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and IPv4 TCP > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 TCP is > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would be > changed to IPv6 which is different with the previous. That means the network > results would be different after rebooting. Would be better to add a note here > to let everyone know that. >=20 > Regards > Lizhong >=20 >=20 > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sat, 24 Sep 2011 10:28:48 -0400 > > From: "Mallette, Edwin" > > To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" > > > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Rajiv, my response is in-line. > > > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: > > > > >While this document passed the WGLC without any comments, we wanted to > > >bring up an issue to seek your feedback. > > > > > >The issue is that the current LDP spec rfc5036 allows an LDP peer to > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 > > >in section 1.1.1 of ldp-ipv6 document. > > > > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 > > >hello adj, in line with existing 'targeted adj check for PW binding > > >advertisement'), we want to pose the following questions: > > > > > >(1) is this a reasonable issue to be fixed? > > [EJM] Yes! > > > > > >(2) is ldp-ipv6 document the right place to fix it? > > [EJM] It's certainly the most expedient. It strikes me that the plan > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is > > incremented, create a new ID which includes the LDP-IPV6 additions, along > > with the fix, within the updated LDP Specification. > > My 2c yes. > > >(3) is the solution highlighted in section 7 a reasonable solution, if > > >you answered yes to both 1 and 2? > > [EJM] Yes. > > > > > >You may answer simple yes/no to each Q, if you like. > > > > > >Cheers, > > >Rajiv > > > > > > > > > > > > > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > > > an LDP IPv6 only peer, which doesn't have IPv4 any more > > > (out in the future, of course). > > > > > > > > >** > > >7. Label Distribution > > > > > > This document specifies that an LSR should advertise and receive > > > both IPv4 and IPv6 label bindings from and to the peer, only if it > > > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > > > specified in section 6.2. > > > > > > This means that the LSR must not advertise any IPv6 label bindings > > > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > > > existed for that peer (and vice versa). > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > -------------------------------------------------------- > 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 rajiva@cisco.com Mon Sep 26 08:00:50 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326E521F8DE7 for ; Mon, 26 Sep 2011 08:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2E-KExq4vpM for ; Mon, 26 Sep 2011 08:00:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3921F8DE8 for ; Mon, 26 Sep 2011 08:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6793; q=dns/txt; s=iport; t=1317049412; x=1318259012; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Wj92WdpnuzSXtopHPgUgtr2KHkklDm/AMucb9gzYNXM=; b=I2pQtYr8Mc+YtSFH4ITiZzREqD7xfXR6hL3v5WhoX/M8OTrQ3PhgH0a6 hFMsdFKNqVdpszP8cgyPRhRzdXT9ffyj9HLAvbY2yJWh/pc0jnCnQgtxa ufCSP5GPC87p4VgrJzj5QV9Wt69ltq0XDzCQtBhDoGx4YmH2EouScaTD2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AANSTgE6tJV2c/2dsb2JhbABBmQqPB3iBUwEBAQECAQEBAQ8BHQo0CwUHBAIBCBEDAQEBAQoGFwEGASYfCQgBAQQBEggTB4dWBptfAZ4MhitgBIdykQuMJg X-IronPort-AV: E=Sophos;i="4.68,444,1312156800"; d="scan'208";a="24059997" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2011 15:03:31 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p8QF3VTL017041; Mon, 26 Sep 2011 15:03:31 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 10:03:31 -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, 26 Sep 2011 10:03:30 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C06063374@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls-ldp-ipv6 : Issue needs WG input Thread-Index: Acx7+eYlTR+gUwoWRsyeQ6yjJud4GAAYbQ7A References: From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 26 Sep 2011 15:03:31.0621 (UTC) FILETIME=[748EA550:01CC7C5D] Cc: mpls@ietf.org, "Fred Baker \(fred\)" Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:00:50 -0000 Hi Lizhong, Pls see inline, > I have additional comment for the text of section 6.1: > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if it has both IPv4 and IPv6 > hello adjacencies for the same LDP Identifier (over a dual- > stack interface, or two or more single-stack IPv4 and IPv6 > interfaces). This applies to the section 2.5.2 of RFC5036. > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if they attempted two TCP > connections using IPv4 and IPv6 transport addresses > simultaneously. > > Such kind of preferrance would make operators a bit hard to predict the TCP > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and IPv4 TCP > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 TCP is > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would be > changed to IPv6 which is different with the previous. That means the network > results would be different after rebooting. Would be better to add a note here > to let everyone know that. Sure. And that is already covered in section 6.3 (Maintaining LDP Sessions) in sufficient details. Would you suggest any other add-ons? Cheers, Rajiv > -----Original Message----- > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > Sent: Sunday, September 25, 2011 11:11 PM > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input >=20 >=20 > Hi Rajiv, > I think it is reasonable, but would be preferred to add "why". If we don't > have this restriction, the peer LSR which may not enable LDPv6 would receive > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if there is > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based IPv6 > LSP work. >=20 > I have additional comment for the text of section 6.1: > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if it has both IPv4 and IPv6 > hello adjacencies for the same LDP Identifier (over a dual- > stack interface, or two or more single-stack IPv4 and IPv6 > interfaces). This applies to the section 2.5.2 of RFC5036. > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > LDP session with a remote LSR, if they attempted two TCP > connections using IPv4 and IPv6 transport addresses > simultaneously. > Such kind of preferrance would make operators a bit hard to predict the TCP > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and IPv4 TCP > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 TCP is > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would be > changed to IPv6 which is different with the previous. That means the network > results would be different after rebooting. Would be better to add a note here > to let everyone know that. >=20 > Regards > Lizhong >=20 >=20 > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Sat, 24 Sep 2011 10:28:48 -0400 > > From: "Mallette, Edwin" > > To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" > > > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Rajiv, my response is in-line. > > > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: > > > > >While this document passed the WGLC without any comments, we wanted to > > >bring up an issue to seek your feedback. > > > > > >The issue is that the current LDP spec rfc5036 allows an LDP peer to > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See figure 3 > > >in section 1.1.1 of ldp-ipv6 document. > > > > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking for v6 > > >hello adj, in line with existing 'targeted adj check for PW binding > > >advertisement'), we want to pose the following questions: > > > > > >(1) is this a reasonable issue to be fixed? > > [EJM] Yes! > > > > > >(2) is ldp-ipv6 document the right place to fix it? > > [EJM] It's certainly the most expedient. It strikes me that the plan > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036 is > > incremented, create a new ID which includes the LDP-IPV6 additions, along > > with the fix, within the updated LDP Specification. > > My 2c yes. > > >(3) is the solution highlighted in section 7 a reasonable solution, if > > >you answered yes to both 1 and 2? > > [EJM] Yes. > > > > > >You may answer simple yes/no to each Q, if you like. > > > > > >Cheers, > > >Rajiv > > > > > > > > > > > > > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > > > an LDP IPv6 only peer, which doesn't have IPv4 any more > > > (out in the future, of course). > > > > > > > > >** > > >7. Label Distribution > > > > > > This document specifies that an LSR should advertise and receive > > > both IPv4 and IPv6 label bindings from and to the peer, only if it > > > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > > > specified in section 6.2. > > > > > > This means that the LSR must not advertise any IPv6 label bindings > > > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > > > existed for that peer (and vice versa). > > >_______________________________________________ > > >mpls mailing list > > >mpls@ietf.org > > >https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > -------------------------------------------------------- > 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 iesg-secretary@ietf.org Mon Sep 26 10:24:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8ED21F8B18; Mon, 26 Sep 2011 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8Tt7ifZx4kc; Mon, 26 Sep 2011 10:24:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010C21F8D3E; Mon, 26 Sep 2011 10:24:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926172423.27110.70357.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 10:24:23 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS Fault Management OAM' to Proposed Standard (draft-ietf-mpls-tp-fault-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 17:24:24 -0000 The IESG has approved the following document: - 'MPLS Fault Management OAM' (draft-ietf-mpls-tp-fault-07.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-fault/ Technical Summary In traditional transport networks, circuits such as T1 lines are typically provisioned on multiple switches. When an event that causes disruption occurs on any link or node along the path of such a transport circuit, Operations, Administration, and Maintenance (OAM) indications are generated which may suppress alarms and/or activate a backup circuit. These OAM messages are called Fault Management (FM) messages. The MPLS-TP requirements demand mechanisms equivalent to traditional transport circuits. Therefore an FM capability is needed in MPLS. This capability must meet the MPLS-TP requirements set out in RFC 5654, and the MPLS-TP OAM requirements in RFC 5860. This document specifies OAM messages to indicate service disruptive conditions for MPLS transport Network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. These mechanisms are intended to be applicable to other aspects of MPLS (beyond MPLS-TP), however, this is beyond the scope of this document. Working Group Summary This document is a MPLS working group document, and part of the joint IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. There has been robust discussion about the technical solution and that has resulted in plenty of revisions to the text, but all changes were confirmed with the WG before the publication request was made. Changes as a result of AD review were plentiful, but editorial in nature. The IPR disclosure was notified to the mailing list and did not result in any suggestions to change the content of the document. Document Quality The document has been carefuly reviewed in the MPLS working group and the ITU-T. The last call was brought to the notice of SG15 in ITU-T who reviewed the document. It has also passed a working group call to verify that LC comments were correctly with minor comments. Several vendors are implementing this document. Personnel Ross Callon (rcallon@juniper.net) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Section 2.1 The primary purpose of the AIS message is to suppress alarms in the layer network above the level at which the fault occurs. When the Link Down Indication is set, the AIS message MAY be used to trigger recovery mechanisms. s/MAY/can/ --- Section 2.2 While the primary purpose of the LKR message is to suppress alarms, similar to AIS with the LDI (L-flag set), the receipt of an LKR message MAY be treated as the equivalent of loss of continuity at the client layer. s/MAY/can/ --- Section 8.1 Please remove the note from the end of this section before publication. --- Section 8.4 para 1 s/"Private Use"/"Experimental Use"/ IANA Note Please also note the Note in Section 8.1. IANA is requested to make the temporary allocation permanent. Please see RFC Editor Note for Section 8.4 From huaimo.chen@huawei.com Mon Sep 26 13:41:43 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8B11E8100 for ; Mon, 26 Sep 2011 13:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhkAEWFNsdzf for ; Mon, 26 Sep 2011 13:41:43 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id EEC3B11E80FC for ; Mon, 26 Sep 2011 13:41:42 -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 <0LS50062PDM0XD@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:44:24 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS500EVHDM06Q@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:44:24 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 26 Sep 2011 13:44:24 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Mon, 26 Sep 2011 13:44:17 -0700 Date: Mon, 26 Sep 2011 20:44:16 +0000 From: Huaimo Chen In-reply-to: X-Originating-IP: [10.212.246.26] To: "yshen@juniper.net" Message-id: <5316A0AB3C851246A7CA5758973207D41049A46B@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Answer to: "Does egress know where the penultimate hop in P2MP Egress Local Protection?" Thread-index: AQHMfI0OHKUt9ZCaBE60vL9bARiIdA== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" , "So, Ning" Subject: [mpls] Answer to: "Does egress know where the penultimate hop in P2MP Egress Local Protection?" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:41:43 -0000 Hi Yimin, The following is the answer with some more details to your question "In egress protection case: do you assume the egress router knows where the penultimate hop?" in IETF 81. Ingress router should know the path for LSP, and the penultimate hop of the egress router. When ingress router has the explicit path for the LSP, it knows the penultimate hop of the egress router. When there are loose hops in the path for the LSP, the loose hops will be expanded or computed to the explicit hops during the signaling of the LSP. Thus the penultimate hop of the egress router is known eventually. A path message for the LSP contains an EGRESS_BACKUP_SUB_LSP object comprising information about the egress router and the corresponding backup egress router. The explicit path from the penultimate hop of the egress router to the backup egress router may be included in the path message. The penultimate hop of the egress router creates a backup LSP to the backup egress router when it knows that it is the penultimate hop of the egress router and needs to set up the backup LSP for protecting the egress router through analyzing the EGRESS_BACKUP_SUB_LSP object. Best Regards, Huaimo From huaimo.chen@huawei.com Mon Sep 26 13:44:17 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55E21F8CDF for ; Mon, 26 Sep 2011 13:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWB4rOezFGiD for ; Mon, 26 Sep 2011 13:44:16 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 642D921F8CDB for ; Mon, 26 Sep 2011 13:44:09 -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 <0LS5006OXDQ4XN@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:46:53 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LS500EECDQ46Q@usaga02-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:46:52 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 26 Sep 2011 13:46:53 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Mon, 26 Sep 2011 13:46:43 -0700 Date: Mon, 26 Sep 2011 20:46:43 +0000 From: Huaimo Chen X-Originating-IP: [10.212.246.26] To: "yshen@juniper.net" Message-id: <5316A0AB3C851246A7CA5758973207D41049A47B@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ydF3h2R772YqtY5zn5nB3A)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Answer to: "For inter area/as so we need PCE support?" Thread-index: AQHMfI1m3gjEpx1B7UyKEb4gqTMl2w== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" , "So, Ning" Subject: [mpls] Answer to: "For inter area/as so we need PCE support?" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:44:17 -0000 --Boundary_(ID_ydF3h2R772YqtY5zn5nB3A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Yimin, The following is the answer with some more details to your question ""For inter area/as so we need PCE support?" in IETF 81. Yes, we need PCE support for inter area/AS case. When P2MP LSP is in one area or AS, and CEs connecting to the ingress and egress routers are in different areas or ASes, with support from PCE, backup ingress router and backup egress routers can be computed automatically. In addition, the backup path from the backup ingress to the next hops of the ingress router and the backup path from the penultimate hop of an egress router to the corresponding backup egress router can also be computed automatically. Best Regards, Huaimo --Boundary_(ID_ydF3h2R772YqtY5zn5nB3A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Yimin,

 

    The following is the answer with some more details to your question ""For inter area/as so we need PCE support?" in IETF 81.

    Yes, we need PCE support for inter area/AS case. When P2MP LSP is in one area or AS, and CEs connecting to the ingress and egress routers are in different areas or ASes, with support from PCE, backup ingress router and backup egress routers can be computed automatically.  In addition, the backup path from the backup ingress to the next hops of the ingress router and the backup path from the penultimate hop of an egress router to the corresponding backup egress router can also be computed automatically.

 

 

Best Regards,

Huaimo

--Boundary_(ID_ydF3h2R772YqtY5zn5nB3A)-- From huaimo.chen@huawei.com Mon Sep 26 13:49:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B41F0CF0 for ; Mon, 26 Sep 2011 13:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cb68TGyrtt0 for ; Mon, 26 Sep 2011 13:49:24 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 073421F0CEF for ; Mon, 26 Sep 2011 13:49:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS500ANWDYVM8@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:52:07 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS5000SPDYUZ4@usaga04-in.huawei.com> for mpls@ietf.org; Mon, 26 Sep 2011 15:52:07 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 26 Sep 2011 13:52:04 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.103]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Mon, 26 Sep 2011 13:51:56 -0700 Date: Mon, 26 Sep 2011 20:51:56 +0000 From: Huaimo Chen X-Originating-IP: [10.212.246.26] To: Greg Mirsky Message-id: <5316A0AB3C851246A7CA5758973207D41049A48A@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Answer to: "Is your protection more scalable than PW redundancy?" Thread-index: AQHMfI4g+msg4MXoOESjXcnG23Z09g== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "mpls@ietf.org" , "So, Ning" Subject: [mpls] Answer to: "Is your protection more scalable than PW redundancy?" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:49:24 -0000 Hi Greg, The following is the answer with some more details to your question "Is your protection (P2MP LSP Ingress and Egress Local Protection) more scalable than PW (egress) redundancy" in IETF 81. LSP and PW are at different levels. PW is above LSP. Our ingress and egress protection provides protection for LSP against ingress and egress failures. PW egress redundancy provides protection for PW against egress failure. An LSP can be used as a transport for a PW; it can also be used as a transport for other traffic. Thus our ingress and egress protection for LSP can provide protection for the traffic transported over the LSP, which include PW and other traffic against ingress and egress failures. The PW redundancy against egress failure may provide protection for the PW against egress failure. However, it can not provide protection for the other traffic transported over LSP. Best Regards, Huaimo From adrian@olddog.co.uk Mon Sep 26 14:55:15 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5552D11E80DE for ; Mon, 26 Sep 2011 14:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dumk4ULzN9TA for ; Mon, 26 Sep 2011 14:55:14 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6CC11E80A6 for ; Mon, 26 Sep 2011 14:55:14 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8QLvvxN026317 for ; Mon, 26 Sep 2011 22:57:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8QLvtWZ026309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Sep 2011 22:57:56 +0100 From: "Adrian Farrel" To: Date: Mon, 26 Sep 2011 22:57:54 +0100 Message-ID: <081e01cc7c97$588726e0$099574a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acx8l1YYj9HbI/Z0R5SPu67gvz0yyQ== Content-Language: en-gb Subject: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 21:55:15 -0000 MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the "two solutions" problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 26 September 2011 20:43 > To: IETF-Announce > Subject: Last Call: (The > Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' > 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 2011-10-24. 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. > > Abstract > > The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology > for use in transport network deployments. That is, MPLS-TP is a set > of functions and features selected from the wider MPLS toolset and > applied in a consistent way to meet the needs and requirements of > operators of packet transport networks. > > During the process of development of the profile, additions to the > MPLS toolset have been made to ensure that the tools available met > the requirements. These additions were motivated by MPLS-TP, but form > part of the wider MPLS toolset such that any of them could be used in > any MPLS deployment. > > One major set of additions provides enhanced support for Operations, > Administration, and Maintenance (OAM). This enables fault management > and performance monitoring to the level needed in a transport > network. Many solutions and protocol extensions have been proposed to > address these OAM requirements, and this document sets out the > reasons for selecting a single, coherent set of solutions for > standardization. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ > > > No IPR declarations have been submitted directly on this I-D. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From lizhong.jin@zte.com.cn Mon Sep 26 18:04:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866D411E80D1 for ; Mon, 26 Sep 2011 18:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.704 X-Spam-Level: X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ld71v+QiaFU for ; Mon, 26 Sep 2011 18:04:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39511E808A for ; Mon, 26 Sep 2011 18:04:10 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621806486374; Tue, 27 Sep 2011 09:04:21 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 75544.3311171018; Tue, 27 Sep 2011 09:06:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p8R16cgR037305; Tue, 27 Sep 2011 09:06:38 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C06063374@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Lizhong Jin Date: Tue, 27 Sep 2011 09:06:32 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-27 09:06:36, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-27 09:06:36, Serialize complete at 2011-09-27 09:06:36, S/MIME Sign failed at 2011-09-27 09:06:36: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-27 09:06:39, Serialize complete at 2011-09-27 09:06:39 Content-Type: multipart/alternative; boundary="=_alternative 000618F748257918_=" X-MAIL: mse01.zte.com.cn p8R16cgR037305 Cc: mpls@ietf.org, "Fred Baker \(fred\)" Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:04:12 -0000 This is a multipart message in MIME format. --=_alternative 000618F748257918_= Content-Type: text/plain; charset="US-ASCII" Hi Rajiv, Suggest to add additional note in section 6.3 behind the first paragraph, may like below: Note, if the previous LDP session is by IPv4, and IPv6 is added by enabling dual-stack or adding another IPv6 interface, when this LDP session is re-established by e.g, rebooting, the new LDP session would be changed to IPv6 which is different with the previous. Cheers Lizhong "Rajiv Asati (rajiva)" wrote on 2011-09-26 23:03:30: > Hi Lizhong, > > Pls see inline, > > > I have additional comment for the text of section 6.1: > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > hello adjacencies for the same LDP Identifier (over a dual- > > stack interface, or two or more single-stack IPv4 and IPv6 > > interfaces). This applies to the section 2.5.2 of RFC5036. > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if they attempted two TCP > > connections using IPv4 and IPv6 transport addresses > > simultaneously. > > > > Such kind of preferrance would make operators a bit hard to predict > the TCP > > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and > IPv4 TCP > > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 > TCP is > > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would > be > > changed to IPv6 which is different with the previous. That means the > network > > results would be different after rebooting. Would be better to add a > note here > > to let everyone know that. > > Sure. And that is already covered in section 6.3 (Maintaining LDP > Sessions) in sufficient details. > > Would you suggest any other add-ons? > > Cheers, > Rajiv > > > > -----Original Message----- > > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > > Sent: Sunday, September 25, 2011 11:11 PM > > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > > > > > Hi Rajiv, > > I think it is reasonable, but would be preferred to add "why". If we > don't > > have this restriction, the peer LSR which may not enable LDPv6 would > receive > > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if > there is > > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based > IPv6 > > LSP work. > > > > I have additional comment for the text of section 6.1: > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > hello adjacencies for the same LDP Identifier (over a dual- > > stack interface, or two or more single-stack IPv4 and IPv6 > > interfaces). This applies to the section 2.5.2 of RFC5036. > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if they attempted two TCP > > connections using IPv4 and IPv6 transport addresses > > simultaneously. > > Such kind of preferrance would make operators a bit hard to predict > the TCP > > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and > IPv4 TCP > > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 > TCP is > > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would > be > > changed to IPv6 which is different with the previous. That means the > network > > results would be different after rebooting. Would be better to add a > note here > > to let everyone know that. > > > > Regards > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Sat, 24 Sep 2011 10:28:48 -0400 > > > From: "Mallette, Edwin" > > > To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Rajiv, my response is in-line. > > > > > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: > > > > > > >While this document passed the WGLC without any comments, we wanted > to > > > >bring up an issue to seek your feedback. > > > > > > > >The issue is that the current LDP spec rfc5036 allows an LDP peer > to > > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer > may > > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See > figure 3 > > > >in section 1.1.1 of ldp-ipv6 document. > > > > > > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking > for v6 > > > >hello adj, in line with existing 'targeted adj check for PW binding > > > >advertisement'), we want to pose the following questions: > > > > > > > >(1) is this a reasonable issue to be fixed? > > > [EJM] Yes! > > > > > > > >(2) is ldp-ipv6 document the right place to fix it? > > > [EJM] It's certainly the most expedient. It strikes me that the > plan > > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036 > is > > > incremented, create a new ID which includes the LDP-IPV6 additions, > along > > > with the fix, within the updated LDP Specification. > > > My 2c yes. > > > >(3) is the solution highlighted in section 7 a reasonable solution, > if > > > >you answered yes to both 1 and 2? > > > [EJM] Yes. > > > > > > > >You may answer simple yes/no to each Q, if you like. > > > > > > > >Cheers, > > > >Rajiv > > > > > > > > > > > > > > > > > > > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > > > > an LDP IPv6 only peer, which doesn't have IPv4 any more > > > > (out in the future, of course). > > > > > > > > > > > >** > > > >7. Label Distribution > > > > > > > > This document specifies that an LSR should advertise and receive > > > > both IPv4 and IPv6 label bindings from and to the peer, only if > it > > > > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > > > > specified in section 6.2. > > > > > > > > This means that the LSR must not advertise any IPv6 label > bindings > > > > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > > > > existed for that peer (and vice versa). > > > >_______________________________________________ > > > >mpls mailing list > > > >mpls@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > -------------------------------------------------------- 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 000618F748257918_= Content-Type: text/html; charset="US-ASCII"
Hi Rajiv,
Suggest to add additional note in section 6.3 behind the first paragraph, may like below:
Note, if the previous LDP session is by IPv4, and IPv6 is added by enabling dual-stack or adding another IPv6 interface, when this LDP session is re-established by e.g, rebooting, the new LDP session would be changed to IPv6 which is different with the previous.
Cheers
Lizhong
 

"Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote on 2011-09-26 23:03:30:

> Hi Lizhong,
>
> Pls see inline,
>
> > I have additional comment for the text of section 6.1:
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if it has both IPv4 and IPv6
> >         hello adjacencies for the same LDP Identifier (over a dual-
> >         stack interface, or two or more single-stack IPv4 and IPv6
> >         interfaces). This applies to the section 2.5.2 of RFC5036.
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if they attempted two TCP
> >         connections using IPv4 and IPv6 transport addresses
> >         simultaneously.
> >
> > Such kind of preferrance would make operators a bit hard to predict
> the TCP
> > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and
> IPv4 TCP
> > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4
> TCP is
> > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would
> be
> > changed to IPv6 which is different with the previous. That means the
> network
> > results would be different after rebooting. Would be better to add a
> note here
> > to let everyone know that.
>
> Sure. And that is already covered in section 6.3 (Maintaining LDP
> Sessions) in sufficient details.
>
> Would you suggest any other add-ons?
>
> Cheers,
> Rajiv
>
>
> > -----Original Message-----
> > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
> > Sent: Sunday, September 25, 2011 11:11 PM
> > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva)
> > Cc: mpls@ietf.org
> > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> >
> >
> > Hi Rajiv,
> > I think it is reasonable, but would be preferred to add "why". If we
> don't
> > have this restriction, the peer LSR which may not enable LDPv6 would
> receive
> > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if
> there is
> > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based
> IPv6
> > LSP work.
> >
> > I have additional comment for the text of section 6.1:
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if it has both IPv4 and IPv6
> >         hello adjacencies for the same LDP Identifier (over a dual-
> >         stack interface, or two or more single-stack IPv4 and IPv6
> >         interfaces). This applies to the section 2.5.2 of RFC5036.
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if they attempted two TCP
> >         connections using IPv4 and IPv6 transport addresses
> >         simultaneously.
> > Such kind of preferrance would make operators a bit hard to predict
> the TCP
> > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and
> IPv4 TCP
> > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4
> TCP is
> > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would
> be
> > changed to IPv6 which is different with the previous. That means the
> network
> > results would be different after rebooting. Would be better to add a
> note here
> > to let everyone know that.
> >
> > Regards
> > Lizhong
> >
> >
> > >
> > >
> ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Sat, 24 Sep 2011 10:28:48 -0400
> > > From: "Mallette, Edwin" <Edwin.Mallette@bhnis.com>
> > > To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "mpls@ietf.org"
> > >    <mpls@ietf.org>
> > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> > > Message-ID: <CAA35E90.176BD%edwin.mallette@bhnis.com>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Rajiv, my response is in-line.
> > >
> > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
> > >
> > > >While this document passed the WGLC without any comments, we wanted
> to
> > > >bring up an issue to seek your feedback.
> > > >
> > > >The issue is that the current LDP spec rfc5036 allows an LDP peer
> to
> > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer
> may
> > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See
> figure 3
> > > >in section 1.1.1 of ldp-ipv6 document.
> > > >
> > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking
> for v6
> > > >hello adj, in line with existing 'targeted adj check for PW binding
> > > >advertisement'), we want to pose the following questions:
> > > >
> > > >(1) is this a reasonable issue to be fixed?
> > > [EJM] Yes!
> > > >
> > > >(2) is ldp-ipv6 document the right place to fix it?
> > > [EJM] It's certainly the most expedient.  It strikes me that the
> plan
> > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036
> is
> > > incremented, create a new ID which includes the LDP-IPV6 additions,
> along
> > > with the fix, within the updated LDP Specification.
> > > My 2c yes.
> > > >(3) is the solution highlighted in section 7 a reasonable solution,
> if
> > > >you answered yes to both 1 and 2?
> > > [EJM] Yes.
> > > >
> > > >You may answer simple yes/no to each Q, if you like.
> > > >
> > > >Cheers,
> > > >Rajiv
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >*      Consequently, an LDP peer advertising IPv4 bindings to
> > > >       an LDP IPv6 only peer, which doesn't have IPv4 any more
> > > >       (out in the future, of course).
> > > >
> > > >
> > > >**
> > > >7. Label Distribution
> > > >
> > > >   This document specifies that an LSR should advertise and receive
> > > >   both IPv4 and IPv6 label bindings from and to the peer, only if
> it
> > > >   has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
> > > >   specified in section 6.2.
> > > >
> > > >   This means that the LSR must not advertise any IPv6 label
> bindings
> > > >   to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
> > > >   existed for that peer (and vice versa).
> > > >_______________________________________________
> > > >mpls mailing list
> > > >mpls@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/mpls
> > >
> >
> >
> > 
--------------------------------------------------------
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 000618F748257918_=-- From lizhong.jin@zte.com.cn Mon Sep 26 18:06:37 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA5211E80FF for ; Mon, 26 Sep 2011 18:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.715 X-Spam-Level: X-Spam-Status: No, score=-101.715 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7AnyMbymv6g for ; Mon, 26 Sep 2011 18:06:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B2DF011E80D1 for ; Mon, 26 Sep 2011 18:06:35 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621806486374; Tue, 27 Sep 2011 09:06:52 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 75544.2738708033; Tue, 27 Sep 2011 09:09:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8R199nK067509; Tue, 27 Sep 2011 09:09:10 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C06063363@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Lizhong Jin Date: Tue, 27 Sep 2011 09:09:04 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-27 09:09:08, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-09-27 09:09:08, Serialize complete at 2011-09-27 09:09:08, S/MIME Sign failed at 2011-09-27 09:09:08: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-27 09:09:11, Serialize complete at 2011-09-27 09:09:11 Content-Type: multipart/alternative; boundary="=_alternative 0006545148257918_=" X-MAIL: mse02.zte.com.cn p8R199nK067509 Cc: mpls@ietf.org Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 01:06:37 -0000 This is a multipart message in MIME format. --=_alternative 0006545148257918_= Content-Type: text/plain; charset="US-ASCII" Rajiv, Correct, add some text to be rational. Thanks. Lizhong "Rajiv Asati (rajiva)" wrote on 2011-09-26 22:50:15: > Hi Lizhong, > > If I follow it right, then your response is > > 1. yes > 2. yes > 3. yes > > However, you would like to add some text for further clarity into the > rationale. Did I sum up right? > > Cheers, > Rajiv > > > > -----Original Message----- > > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn] > > Sent: Sunday, September 25, 2011 11:11 PM > > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > > > > > Hi Rajiv, > > I think it is reasonable, but would be preferred to add "why". If we > don't > > have this restriction, the peer LSR which may not enable LDPv6 would > receive > > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if > there is > > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based > IPv6 > > LSP work. > > > > I have additional comment for the text of section 6.1: > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > hello adjacencies for the same LDP Identifier (over a dual- > > stack interface, or two or more single-stack IPv4 and IPv6 > > interfaces). This applies to the section 2.5.2 of RFC5036. > > - An LSR should prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if they attempted two TCP > > connections using IPv4 and IPv6 transport addresses > > simultaneously. > > Such kind of preferrance would make operators a bit hard to predict > the TCP > > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and > IPv4 TCP > > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4 > TCP is > > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would > be > > changed to IPv6 which is different with the previous. That means the > network > > results would be different after rebooting. Would be better to add a > note here > > to let everyone know that. > > > > Regards > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Sat, 24 Sep 2011 10:28:48 -0400 > > > From: "Mallette, Edwin" > > > To: "Rajiv Asati (rajiva)" , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input > > > Message-ID: > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Rajiv, my response is in-line. > > > > > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" wrote: > > > > > > >While this document passed the WGLC without any comments, we wanted > to > > > >bring up an issue to seek your feedback. > > > > > > > >The issue is that the current LDP spec rfc5036 allows an LDP peer > to > > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer > may > > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See > figure 3 > > > >in section 1.1.1 of ldp-ipv6 document. > > > > > > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking > for v6 > > > >hello adj, in line with existing 'targeted adj check for PW binding > > > >advertisement'), we want to pose the following questions: > > > > > > > >(1) is this a reasonable issue to be fixed? > > > [EJM] Yes! > > > > > > > >(2) is ldp-ipv6 document the right place to fix it? > > > [EJM] It's certainly the most expedient. It strikes me that the > plan > > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036 > is > > > incremented, create a new ID which includes the LDP-IPV6 additions, > along > > > with the fix, within the updated LDP Specification. > > > My 2c yes. > > > >(3) is the solution highlighted in section 7 a reasonable solution, > if > > > >you answered yes to both 1 and 2? > > > [EJM] Yes. > > > > > > > >You may answer simple yes/no to each Q, if you like. > > > > > > > >Cheers, > > > >Rajiv > > > > > > > > > > > > > > > > > > > > > > > >* Consequently, an LDP peer advertising IPv4 bindings to > > > > an LDP IPv6 only peer, which doesn't have IPv4 any more > > > > (out in the future, of course). > > > > > > > > > > > >** > > > >7. Label Distribution > > > > > > > > This document specifies that an LSR should advertise and receive > > > > both IPv4 and IPv6 label bindings from and to the peer, only if > it > > > > has valid IPv4 and IPv6 Hello Adjacencies for that peer, as > > > > specified in section 6.2. > > > > > > > > This means that the LSR must not advertise any IPv6 label > bindings > > > > to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency > > > > existed for that peer (and vice versa). > > > >_______________________________________________ > > > >mpls mailing list > > > >mpls@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > -------------------------------------------------------- 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 0006545148257918_= Content-Type: text/html; charset="US-ASCII"
Rajiv,
Correct, add some text to be rational. Thanks.

Lizhong
 

"Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote on 2011-09-26 22:50:15:

> Hi Lizhong,
>
> If I follow it right, then your response is
>
> 1. yes
> 2. yes
> 3. yes
>
> However, you would like to add some text for further clarity into the
> rationale. Did I sum up right?
>
> Cheers,
> Rajiv
>
>
> > -----Original Message-----
> > From: lizhong.jin@zte.com.cn [mailto:lizhong.jin@zte.com.cn]
> > Sent: Sunday, September 25, 2011 11:11 PM
> > To: Edwin.Mallette@bhnis.com; Rajiv Asati (rajiva)
> > Cc: mpls@ietf.org
> > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> >
> >
> > Hi Rajiv,
> > I think it is reasonable, but would be preferred to add "why". If we
> don't
> > have this restriction, the peer LSR which may not enable LDPv6 would
> receive
> > IPv6 FEC that it may not process. Even both LSRs are IPv6 enabled, if
> there is
> > no IPv6 hello adjacency, IPv6 FEC advertising would not make LDP-based
> IPv6
> > LSP work.
> >
> > I have additional comment for the text of section 6.1:
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if it has both IPv4 and IPv6
> >         hello adjacencies for the same LDP Identifier (over a dual-
> >         stack interface, or two or more single-stack IPv4 and IPv6
> >         interfaces). This applies to the section 2.5.2 of RFC5036.
> >      - An LSR should prefer the LDP/TCP connection over IPv6 for a new
> >         LDP session with a remote LSR, if they attempted two TCP
> >         connections using IPv4 and IPv6 transport addresses
> >         simultaneously.
> > Such kind of preferrance would make operators a bit hard to predict
> the TCP
> > connection version. E.g, LDPv4 is enabled between LSR1 and LSR2, and
> IPv4 TCP
> > is established. Then LDPv6 is enabled between LSR1 and LSR2, and IPv4
> TCP is
> > till kept. Some day, LSR1 and LSR2 are rebooted, but the session would
> be
> > changed to IPv6 which is different with the previous. That means the
> network
> > results would be different after rebooting. Would be better to add a
> note here
> > to let everyone know that.
> >
> > Regards
> > Lizhong
> >
> >
> > >
> > >
> ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Sat, 24 Sep 2011 10:28:48 -0400
> > > From: "Mallette, Edwin" <Edwin.Mallette@bhnis.com>
> > > To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "mpls@ietf.org"
> > >    <mpls@ietf.org>
> > > Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
> > > Message-ID: <CAA35E90.176BD%edwin.mallette@bhnis.com>
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > Rajiv, my response is in-line.
> > >
> > > On 9/22/11 4:52 PM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
> > >
> > > >While this document passed the WGLC without any comments, we wanted
> to
> > > >bring up an issue to seek your feedback.
> > > >
> > > >The issue is that the current LDP spec rfc5036 allows an LDP peer
> to
> > > >advertise IPv6 bindings to an LDP IPv4 peer, even though the peer
> may
> > > >not have any IPv6 enabled (or IPv6 LDP), and vice versa*. See
> figure 3
> > > >in section 1.1.1 of ldp-ipv6 document.
> > > >
> > > >While mpls-ldp-ipv6 section 7** addresses this issue (by checking
> for v6
> > > >hello adj, in line with existing 'targeted adj check for PW binding
> > > >advertisement'), we want to pose the following questions:
> > > >
> > > >(1) is this a reasonable issue to be fixed?
> > > [EJM] Yes!
> > > >
> > > >(2) is ldp-ipv6 document the right place to fix it?
> > > [EJM] It's certainly the most expedient.  It strikes me that the
> plan
> > > would be to "fix" this issue within LDP-IPv6 and then when RFC5036
> is
> > > incremented, create a new ID which includes the LDP-IPV6 additions,
> along
> > > with the fix, within the updated LDP Specification.
> > > My 2c yes.
> > > >(3) is the solution highlighted in section 7 a reasonable solution,
> if
> > > >you answered yes to both 1 and 2?
> > > [EJM] Yes.
> > > >
> > > >You may answer simple yes/no to each Q, if you like.
> > > >
> > > >Cheers,
> > > >Rajiv
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >*      Consequently, an LDP peer advertising IPv4 bindings to
> > > >       an LDP IPv6 only peer, which doesn't have IPv4 any more
> > > >       (out in the future, of course).
> > > >
> > > >
> > > >**
> > > >7. Label Distribution
> > > >
> > > >   This document specifies that an LSR should advertise and receive
> > > >   both IPv4 and IPv6 label bindings from and to the peer, only if
> it
> > > >   has valid IPv4 and IPv6 Hello Adjacencies for that peer, as
> > > >   specified in section 6.2.
> > > >
> > > >   This means that the LSR must not advertise any IPv6 label
> bindings
> > > >   to a peer over an IPv4 LDP session, if no IPv6 Hello Adjacency
> > > >   existed for that peer (and vice versa).
> > > >_______________________________________________
> > > >mpls mailing list
> > > >mpls@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/mpls
> > >
> >
> >
> > 
--------------------------------------------------------
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 0006545148257918_=-- From internet-drafts@ietf.org Mon Sep 26 22:11:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2E421F8D60; Mon, 26 Sep 2011 22:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVGIgg2xxV8t; Mon, 26 Sep 2011 22:11:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A967321F8DD9; Mon, 26 Sep 2011 22:11:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110927051119.1853.36337.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 22:11:19 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 05:11:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : An Overview of the OAM Tool Set for MPLS based Transport= Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-05.txt Pages : 21 Date : 2011-09-26 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in [MPLS-TP OAM Reqs] and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-05.txt From ietfc@btconnect.com Tue Sep 27 10:00:00 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D56821F8E71 for ; Tue, 27 Sep 2011 10:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+lmHDKzRP6o for ; Tue, 27 Sep 2011 10:00:00 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB521F8E28 for ; Tue, 27 Sep 2011 09:59:58 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr09.btconnect.com with SMTP id EPM26046; Tue, 27 Sep 2011 18:02:41 +0100 (BST) Message-ID: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ross Callon" , References: Date: Tue, 27 Sep 2011 17:57:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4E8201B1.0011, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.27.153614:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4E8201B1.0138,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 17:00:00 -0000 It seems to me that the work on a read-write MIB module has been done, and that taking out the write capability is therefore more work and not less. The work that has been done could be used in future, for example as input to an SMI-Yang converter to create a suitable module for use with Netconf. >From an SMI perspective, Conformance clauses allow a read-only version to be specified within the MIB module which most, if not all, implementers could then select, as they wish. So while I don't have a user view, as to whether or not read-write access is useful - I take Tom's point that SNMP with a Standards Track MIB module is rarely used for provisioning - I am unclear what the benefit is of making this read-only. Tom Petch ----- Original Message ----- From: "Ross Callon" To: Sent: Tuesday, September 20, 2011 9:43 PM Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it currently contains relatively few writeable objects). This is compatible with my understanding of how MIBs are often used. However, this also varies from normal IETF convention where MIBs contain both read and write objects. We therefore are asking for comments from the WG regarding whether people are okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only. Thanks, Ross (for the MPLS WG co-chairs) -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From tnadeau@lucidvision.com Tue Sep 27 10:31:20 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37BC21F8F08 for ; Tue, 27 Sep 2011 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEWuu0U7zE+J for ; Tue, 27 Sep 2011 10:31:20 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1C81D21F8F07 for ; Tue, 27 Sep 2011 10:31:19 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 7A1E61E71201; Tue, 27 Sep 2011 13:34:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau X-Priority: 3 In-Reply-To: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> Date: Tue, 27 Sep 2011 13:34:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1244.3) Cc: Ross Callon , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 17:31:20 -0000 On Sep 27, 2011, at 11:57 AM, t.petch wrote: > It seems to me that the work on a read-write MIB module has been done, = and that > taking out the write capability is therefore more work and not less. = The work > that has been done could be used in future, for example as input to an = SMI-Yang > converter to create a suitable module for use with Netconf. Speaking as one of the authors, I can safely say that what is = there is incomplete. =20 We have taken a short break until we can get consensus on the read-write = situation. Furthermore, you are not considering future items/tables that are added, = their interrelation=20 to existing ones, as well as other TP-related MIB modules that are not = yet created.=20 > =46rom an SMI perspective, Conformance clauses allow a read-only = version to be > specified within the MIB module which most, if not all, implementers = could then > select, as they wish. >=20 > So while I don't have a user view, as to whether or not read-write = access is > useful - I take Tom's point that SNMP with a Standards Track MIB = module is > rarely used for provisioning - I am unclear what the benefit is of = making this > read-only. The benefits are: The co-authors do not have to waste time on making sure the = module is read-write The MIB Doctors and IESG do not have to waste time determining = if the co-authors have done their job The WG gets an RFC version of this MIB about a year earlier.=20 --Tom >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Ross Callon" > To: > Sent: Tuesday, September 20, 2011 9:43 PM > Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only = MIB >=20 >=20 > There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a = read-only MIB (it > currently contains relatively few writeable objects). This is = compatible with my > understanding of how MIBs are often used. However, this also varies = from normal > IETF convention where MIBs contain both read and write objects. >=20 > We therefore are asking for comments from the WG regarding whether = people are > okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only. >=20 > Thanks, Ross > (for the MPLS WG co-chairs) >=20 >=20 >=20 >=20 > = --------------------------------------------------------------------------= ------ >=20 >=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Tue Sep 27 11:14:24 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6E621F8F01; Tue, 27 Sep 2011 11:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT6DueqX-Tc8; Tue, 27 Sep 2011 11:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E07D21F8C09; Tue, 27 Sep 2011 11:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110927181424.350.22116.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2011 11:14:24 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-on-demand-cv-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 18:14:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS On-demand Connectivity Verification and Route Traci= ng Author(s) : Eric Gray Nitin Bahadur Sami Boutros Rahul Aggarwal Filename : draft-ietf-mpls-tp-on-demand-cv-07.txt Pages : 22 Date : 2011-09-27 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-on-demand-cv-07.txt From loa@pi.nu Tue Sep 27 19:24:34 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0C21F8C37; Tue, 27 Sep 2011 19:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.667 X-Spam-Level: X-Spam-Status: No, score=-102.667 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hajt-K1Swt3w; Tue, 27 Sep 2011 19:24:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 186E721F8C34; Tue, 27 Sep 2011 19:24:33 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 465FA2A8002; Wed, 28 Sep 2011 04:27:16 +0200 (CEST) Message-ID: <4E828602.4080104@pi.nu> Date: Wed, 28 Sep 2011 04:27:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-li-lb@tools.ietf.org, pwe3@ietf.org, MPLS-TP ad hoc team References: <4E78D4B6.2000706@pi.nu> In-Reply-To: <4E78D4B6.2000706@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] [PWE3] verification call on draft-ietf-mpls-tp-li-lb X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 02:24:35 -0000 Working Group, this verification call has ended. We have one comment that effectively says that this document updates RFC6371 that needs to addressed. We are also some comments editorial comments that should be included in an updated version. Could the the authors please update the document and publish a new version. /Loa for the wg chairs On 2011-09-20 20:00, Loa Andersson wrote: > Working Group, > > the draft-ietf-mpls-tp-li-lb has completed working group last call > and the authors has updated the document considering the comments. > A new version (-05) has been published and will be found here: > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-li-lb/ > > This is to start a one week verification call, to make sure that all > comments has been correctly addressed. > > A list of all comments and how they been resolved will be found at: > > http://www.pi.nu/~loa/li-lb-05-Comments.xls > > This verification call ends Tuesday Sep 27 2011. > > /Loa > for the MPLS wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From adrian@olddog.co.uk Wed Sep 28 05:49:49 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958821F8D88 for ; Wed, 28 Sep 2011 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd4FL-CQKWiC for ; Wed, 28 Sep 2011 05:49:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id C36A321F8D7C for ; Wed, 28 Sep 2011 05:49:48 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8SCqUdk026804; Wed, 28 Sep 2011 13:52:31 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8SCqTmB026771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Sep 2011 13:52:30 +0100 From: "Adrian Farrel" To: "'Thomas Nadeau'" , "'t.petch'" References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> In-Reply-To: <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> Date: Wed, 28 Sep 2011 13:52:26 +0100 Message-ID: <0bdd01cc7ddd$7a522530$6ef66f90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMY/EzJ4RQY8YVbfSPybVPYi0Bx4gG/pPh8AfruKSmSq+yCQA== Content-Language: en-gb Cc: 'Ross Callon' , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:49:49 -0000 Tom (N) wrote... > The benefits are: > > The WG gets an RFC version of this MIB about a year earlier. Which begs the question (speaking purely as an individual contributor) of why we are bothering with a MIB module at all. Adrian From ietfc@btconnect.com Wed Sep 28 06:10:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB8421F8D29 for ; Wed, 28 Sep 2011 06:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 737Hpm0d5Nrd for ; Wed, 28 Sep 2011 06:10:35 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C221F8D23 for ; Wed, 28 Sep 2011 06:10:33 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr06.btconnect.com with SMTP id ETE71872; Wed, 28 Sep 2011 14:12:48 +0100 (BST) Message-ID: <000a01cc7dd7$52d170c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Thomas Nadeau" References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> Date: Wed, 28 Sep 2011 14:08:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E831D4F.00C5, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.28.114815:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E831D51.0127,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Ross Callon , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 13:10:36 -0000 ----- Original Message ----- From: "Thomas Nadeau" To: "t.petch" Cc: "Ross Callon" ; Sent: Tuesday, September 27, 2011 7:34 PM On Sep 27, 2011, at 11:57 AM, t.petch wrote: > It seems to me that the work on a read-write MIB module has been done, and that > taking out the write capability is therefore more work and not less. The work > that has been done could be used in future, for example as input to an SMI-Yang > converter to create a suitable module for use with Netconf. Speaking as one of the authors, I can safely say that what is there is incomplete. We have taken a short break until we can get consensus on the read-write situation. Furthermore, you are not considering future items/tables that are added, their interrelation to existing ones, as well as other TP-related MIB modules that are not yet created. OK, I misunderstood the situation. Tom Petch > From an SMI perspective, Conformance clauses allow a read-only version to be > specified within the MIB module which most, if not all, implementers could then > select, as they wish. > > So while I don't have a user view, as to whether or not read-write access is > useful - I take Tom's point that SNMP with a Standards Track MIB module is > rarely used for provisioning - I am unclear what the benefit is of making this > read-only. The benefits are: The co-authors do not have to waste time on making sure the module is read-write The MIB Doctors and IESG do not have to waste time determining if the co-authors have done their job The WG gets an RFC version of this MIB about a year earlier. --Tom > > Tom Petch > > > ----- Original Message ----- > From: "Ross Callon" > To: > Sent: Tuesday, September 20, 2011 9:43 PM > Subject: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB > > > There is a plan to make draft-ietf-mpls-tp-te-mib-00.txt be a read-only MIB (it > currently contains relatively few writeable objects). This is compatible with my > understanding of how MIBs are often used. However, this also varies from normal > IETF convention where MIBs contain both read and write objects. > > We therefore are asking for comments from the WG regarding whether people are > okay with updating draft-ietf-mpls-tp-te-mib-00.txt to be read only. > > Thanks, Ross > (for the MPLS WG co-chairs) > > > > > ------------------------------------------------------------------------------ -- > > >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From tnadeau@lucidvision.com Wed Sep 28 06:46:36 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1D321F8D10 for ; Wed, 28 Sep 2011 06:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g20tlidKT30 for ; Wed, 28 Sep 2011 06:46:35 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7138521F8CEB for ; Wed, 28 Sep 2011 06:46:35 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 529561E76561; Wed, 28 Sep 2011 09:49:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <0bdd01cc7ddd$7a522530$6ef66f90$@olddog.co.uk> Date: Wed, 28 Sep 2011 09:49:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> <0bdd01cc7ddd$7a522530$6ef66f90$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1244.3) Cc: 'Ross Callon' , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 13:46:36 -0000 On Sep 28, 2011, at 8:52 AM, Adrian Farrel wrote: > Tom (N) wrote...=20 >=20 >=20 >> The benefits are: >>=20 >> The WG gets an RFC version of this MIB about a year earlier. >=20 > Which begs the question (speaking purely as an individual contributor) = of why we > are bothering with a MIB module at all. I am not sure how you made the leap from the current thread to = that. Can you elaborate? --Tom From adrian@olddog.co.uk Wed Sep 28 07:53:06 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15C321F8C51 for ; Wed, 28 Sep 2011 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAikx6LukmZj for ; Wed, 28 Sep 2011 07:53:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 32EC421F8C30 for ; Wed, 28 Sep 2011 07:53:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8SEtqfK029810; Wed, 28 Sep 2011 15:55:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8SEtho6029747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Sep 2011 15:55:49 +0100 From: "Adrian Farrel" To: "'Thomas Nadeau'" References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> <0bdd01cc7ddd$7a522530$6ef66f90$@olddog.co.uk> In-Reply-To: Date: Wed, 28 Sep 2011 15:55:40 +0100 Message-ID: <0c2201cc7dee$b5bc5990$21350cb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMY/EzJ4RQY8YVbfSPybVPYi0Bx4gG/pPh8AfruKSkCi5OeDQITKI5FkocZRfA= Content-Language: en-gb Cc: 'Ross Callon' , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 14:53:06 -0000 > >> The benefits are: > >> > >> The WG gets an RFC version of this MIB about a year earlier. > > > > Which begs the question (speaking purely as an individual contributor) of why > we > > are bothering with a MIB module at all. > > I am not sure how you made the leap from the current thread to that. > Can you elaborate? Sure. You said something that implies the WG would like the MIB [module] about a year earlier. So I wondered (aloud) whether the WG wants the MIB module at all. If there is a rush to have a MIB module, that is fine. I don't really hear much demand for a rapid, read-only MPLS-TP TE module. So, rather than have folk say "we have no interest in a writeable MIB module" we should ask people to comment on whether they "want a rapid-to-RFC read-only MIB module". A From tnadeau@lucidvision.com Wed Sep 28 08:01:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A759021F8ABE for ; Wed, 28 Sep 2011 08:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ne8Zd1tMQuE for ; Wed, 28 Sep 2011 08:01:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7221F8ABD for ; Wed, 28 Sep 2011 08:01:58 -0700 (PDT) Received: from [192.168.1.144] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5C1781E76CC7; Wed, 28 Sep 2011 11:04:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <0c2201cc7dee$b5bc5990$21350cb0$@olddog.co.uk> Date: Wed, 28 Sep 2011 11:04:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06ac01cc7d2e$4675e1c0$4001a8c0@gateway.2wire.net> <73211DFB-2D1F-4C2A-9D6B-ED5173F30421@lucidvision.com> <0bdd01cc7ddd$7a522530$6ef66f90$@olddog.co.uk> <0c2201cc7dee$b5bc5990$21350cb0$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1244.3) Cc: 'Ross Callon' , mpls@ietf.org Subject: Re: [mpls] draft-ietf-mpls-tp-te-mib Consensus Call on Read-Only MIB X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 15:01:58 -0000 On Sep 28, 2011, at 10:55 AM, Adrian Farrel wrote: >>>> The benefits are: >>>>=20 >>>> The WG gets an RFC version of this MIB about a year earlier. >>>=20 >>> Which begs the question (speaking purely as an individual = contributor) of > why >> we >>> are bothering with a MIB module at all. >>=20 >> I am not sure how you made the leap from the current thread to = that. >> Can you elaborate? >=20 > Sure. > You said something that implies the WG would like the MIB [module] = about a year > earlier. > So I wondered (aloud) whether the WG wants the MIB module at all. > If there is a rush to have a MIB module, that is fine. I don't really = hear much > demand for a rapid, read-only MPLS-TP TE module. >=20 > So, rather than have folk say "we have no interest in a writeable MIB = module" we > should ask people to comment on whether they "want a rapid-to-RFC = read-only MIB > module". I suppose that is a fair enough question to ask, but one that I = think was asked when we asked the WG to adopt the draft as a WG document, no? --Tom >=20 > A >=20 >=20 From cpignata@cisco.com Wed Sep 28 08:04:53 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9B1F0C46 for ; Wed, 28 Sep 2011 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.669 X-Spam-Level: X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXO82wN+DiCs for ; Wed, 28 Sep 2011 08:04:52 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9A78B1F0C44 for ; Wed, 28 Sep 2011 08:04:52 -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 p8SF7dDQ011210 for ; Wed, 28 Sep 2011 11:07:39 -0400 (EDT) Received: from [10.117.115.52] (rtp-cpignata-8913.cisco.com [10.117.115.52]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8SF7cnu008747 for ; Wed, 28 Sep 2011 11:07:39 -0400 (EDT) Message-ID: <4E83383A.3030508@cisco.com> Date: Wed, 28 Sep 2011 11:07:38 -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.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: mpls@ietf.org References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com> <00e701cc7770$02401b60$4001a8c0@gateway.2wire.net> <019301cc7838$45f53020$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.3.2 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 Subject: Re: [mpls] New Version Notification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 15:04:53 -0000 Tom, Please find one or two additional comments inline. Note also we posted addressing your IANA comment, diffs at . On 9/22/2011 5:42 AM, Mach Chen wrote: > Hi Tom, > > Please see inline... > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> t.petch >> Sent: Wednesday, September 21, 2011 4:27 PM >> To: Mach Chen; mpls@ietf.org >> Cc: ppan@infinera.com >> Subject: Re: [mpls] New Version Notification >> fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt >> >> Mach >> >> Since you mention updating >> draft-ietf-mpls-return-path-specified-lsp-ping >> below, I offer two more revolutionary ideas. >> >> First is the relationship between the subTLVs of TLV Type1 and those of TLV >> Type21. Looking at the IANA page, I think that IANA have the same problem >> as I >> do. Are the subTLVs of TLV Type21 intended to approximate to those of >> Type1, >> be an exact match at this point in time (a fast moving target with three I-Ds >> with the IESG and RFC Editor), be an exact match for all time (with the >> implications on future editors being aware of that) r what? (I think that the >> IANA page is currently a 'what?' :-) > > Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for Type21 TLV, and vice versa. > > Strictly speaking, Type21 is totally independent of Type1 TLV, it just "borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and their sub-TLVs registries should be created, updated and maintained independently. > >> >> Second, we are getting several RFC updating the registry that RFC4379 >> established, which makes it harder to find what is defined where and to make >> subsequent updates accurate, so the fewer RFC, the better. > > I basically agree with you here, but the practice of the IETF normally like this, a spec and then subsequent extensions with time. > I disagree. Nothing wrong with multiple RFCs updating a specific registry -- that's actually potentially a good thing if it speaks to protocol growth and adoption! I also do not think there is confusion since registries have a "Reference" column with a pointer to the document (not even necessarily an RFC in general) that is authoritative for a given entry. Lastly, minimizing RFC.count by potentially agglutinating different issues together is actually not something I'd recomment; in fact, Truth #5 of comes to mind. >> So were the >> chairs >> to poll for the adoption of >> draft-chen-mpls-ipv6-pw-lsp-ping-01 >> I would oppose, rather seeing its content, important but slight, rolled into >> draft-ietf-mpls-return-path-specified-lsp-ping IMHO, this is putting the cart before the horse. These are not documents created to update IANA registries. These are protocol documents with completely different goals, solving totally different problems. Both update the same registry, as a consequence, as a means and not an end. Thanks, -- Carlos. > > I personally prefer to let them separate, because the two drafts have different purposes and functions. If the WG has the consensus to do it, I will be OK with that. > > Best regards, > Mach > >> which is the I-D, after all, that creates much of the complexity by introducing >> TLV Type 21. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Mach Chen" >> To: "t.petch" ; >> Cc: >> Sent: Wednesday, September 21, 2011 8:28 AM >> >>> Hi Tom, >>> >>> Many thanks for your comments. >>> >>> Please see my response inline... >>> >>>> >>>> Mach >>>> >>>> It looks ok, but I sort of get worried when I have to spend too much time >>>> working out the details. Specifically, the IANA registries that RFC4379 >>>> created >>>> have been given names by IANA, even though RFC4379 itself did not do so, >> so >> I >>>> think that this I-D should use these names. The registry in question, >> MPLS - >>>> LSP Ping Parameters - TLVs and sub-TLVs, >>> >>> Good suggestion, will do that in the later version. >>> >>>> already has four I-Ds making early >>>> allocations to it so it is quite a big and volatile registry. >>>> >>>> Technically this is not a problem but it sort of worries me. This I-D is in >> a >>>> sense putting right a lack of foresight in RFC4379, nailing down what >> RFC4379 >>>> might have nailed down, so is there anything still missing that needs >> nailing >>>> down? I cannot see anything but think I am probably missing something:-( >>> >>> I did a rough checking when I wrote this draft, and found that the PW FEC is >> the only one that needs nailing down, which impacts two documents, one is >> RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. >>> >>>> >>>> Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which >> you >>>> are updating three. TLV Type21 has 19 sub-TLVs which closely parallel >> those >>>> of >>>> Type 1 which you are not updating (ok there is another I-D that should do so >> but >>>> have the authors of that I-D - namely you! - any thoughts on this?). Should >> the >>>> registry be looked at more widely to see if it can better be rationalised? >>> >>> As the author of the two drafts, I have noticed that and have plan to update >> the return-path-specified-lsp-ping draft, and make a point to this new draft is >> the straightforward and simple solution. >>> >>> Since that draft is still working in progress and has the common author, it's >> easier to update. >>> >>> Best regards, >>> Mach >>> >>>> >>>> Tom Petch >>>> >>>>> >>>>> Thanks, >>>>> Mach >>>>> >>>>> ----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Wednesday, August 17, 2011 11:08 AM >>>>>> To: Mach Chen >>>>>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; >>>> cpignata@cisco.com >>>>>> Subject: New Version Notification for >>>> draft-chen-mpls-ipv6-pw-lsp-ping-01.txt >>>>>> >>>>>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been >>>>>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF >>>> repository. >>>>>> >>>>>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping >>>>>> Revision: 01 >>>>>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs >>>>>> Creation date: 2011-08-16 >>>>>> WG ID: Individual Submission >>>>>> Number of pages: 9 >>>>>> >>>>>> Abstract: >>>>>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) >> Ping >>>>>> and Traceroute mechanisms are commonly used to detect and >> isolate >>>>>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. >>>>>> The PW LSP Ping and Traceroute elements, however, are not >> specified >>>>>> for IPv6 address usage. >>>>>> >>>>>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in >>>>>> the LSP Ping and Traceroute mechanism are implicitly defined only >> for >>>>>> IPv4 Provider Edge (PEs) routers, and are not applicable for the case >>>>>> where PEs use IPv6 addresses. There is, additionally, a degree of >>>>>> potential ambiguity in the specification of these sub-TLVs since the >>>>>> address family is not explicitly specified but it is to be inferred >>>>>> from the sub-TLV length. >>>>>> >>>>>> This document updates RFC4379 to explicitly constraint these >> existing >>>>>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP >>>>>> Ping to the IPv6 scenario where an IPv6 LDP session is used to >> signal >>>>>> the Pseudowire (i.e., where the Sender's and Receiver's IP >> addresses >>>>>> are IPv6 addresses.) This is done by defining two new LSP Ping >> sub- >>>>>> TLVs for IPv6 Pseudowire FECs. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From huanglu@chinamobile.com Thu Sep 15 19:53:18 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4665E11E80B8 for ; Thu, 15 Sep 2011 19:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.108 X-Spam-Level: *** X-Spam-Status: No, score=3.108 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjH7REheaEKi for ; Thu, 15 Sep 2011 19:53:17 -0700 (PDT) Received: from hqmta.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6876F11E80B9 for ; Thu, 15 Sep 2011 19:53:16 -0700 (PDT) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id DE6B0C05EE; Fri, 16 Sep 2011 10:55:27 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id D47DFC062A; Fri, 16 Sep 2011 10:55:27 +0800 (CST) Received: from PC-20110530UGBE ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011091610552164-4620 ; Fri, 16 Sep 2011 10:55:21 +0800 Date: Fri, 16 Sep 2011 10:55:14 +0800 From: "Huang Lu" To: "daniel" , "mpls" Message-ID: <201109161055055175096@chinamobile.com> Organization: ChinaMobile X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-16 10:55:25, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-09-16 10:55:27, Serialize complete at 2011-09-16 10:55:27 Content-Type: multipart/alternative; boundary="=====003_Dragon408366838860_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18388.004 X-TM-AS-Result: No--9.480-7.0-31-10 X-imss-scan-details: No--9.480-7.0-31-10;No--9.480-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Thu, 29 Sep 2011 09:29:01 -0700 Cc: lichenyj , "quintin.zhao" , Li Lianyuan Subject: Re: [mpls] draft-li-mpls-mt-applicability-requirement-02 Comments X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huanglu@chinamobile.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 02:53:18 -0000 This is a multi-part message in MIME format. --=====003_Dragon408366838860_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Dan, Thanks for your review and comments. We will need a few days to review your suggestions then we will respond to specific points as needed. 2011-09-16 Best Regards! Lu Huang Research Institute of China Mobile Floor 11, Door 2, Dacheng Plaza No.28 Xuanwumen West Ave, Xuanwu District Beijing 100053, China Phone: +86 10-15801696688-3287 Mobile: +86 13810820540 Email: huanglu@chinamobile.com --=====003_Dragon408366838860_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
Hi Dan, 
 
Thanks for your review and comments. 
 
We will need a few days to review your suggestions then we will respond to specific points as needed.
 
2011-09-16
 
Best Regards!
 
Lu Huang
Research Institute of China Mobile
Floor 11, Door 2, Dacheng Plaza
No.28 Xuanwumen West Ave, Xuanwu District
Beijing 100053, China
Phone:  +86 10-15801696688-3287
Mobile: +86 13810820540
Email:  huanglu@chinamobile.com
 --=====003_Dragon408366838860_=====-- From internet-drafts@ietf.org Thu Sep 29 11:01:35 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251AC21F8BF8; Thu, 29 Sep 2011 11:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH8TJ5d-gwEl; Thu, 29 Sep 2011 11:01:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9821F8BEE; Thu, 29 Sep 2011 11:01:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110929180134.8813.63980.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2011 11:01:34 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 18:01:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS Transport Profile lock Instruct and Loopback Functi= ons Author(s) : Sami Boutros Siva Sivabalan Rahul Aggarwal Martin Vigoureux Xuehui Dai Filename : draft-ietf-mpls-tp-li-lb-06.txt Pages : 13 Date : 2011-09-29 This document specifies one function and describes a second function which are applicable to MPLS transport networks. The first function enables an operator to lock a transport path while the second enables an operator to set, in loopback, a given node along a transport path. This document also defines the extension to MPLS operation, administration, and maintenance (OAM) to perform the lock function. This document updates RFC 6371 section 7.1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-06.txt From iesg-secretary@ietf.org Thu Sep 29 11:22:41 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC621F8CD2; Thu, 29 Sep 2011 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNgRcmEaUn0q; Thu, 29 Sep 2011 11:22:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6920A21F8CD6; Thu, 29 Sep 2011 11:22:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110929182240.16910.64775.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2011 11:22:40 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'MPLS On-demand Connectivity Verification and Route Tracing' to Proposed Standard (draft-ietf-mpls-tp-on-demand-cv-07.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 18:22:41 -0000 The IESG has approved the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' (draft-ietf-mpls-tp-on-demand-cv-07.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ Technical Summary Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. Working Group Summary This document is a MPLS working group document, and part of the joint IETF and ITU.T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. There is a good consensus around this draft, it has passed the call to verify that LC comments were correctly addressed with only minor comments. Document Quality The document is well reviewed in the MPLS working group and ITU-T SG15. Multiple vendors have indicated their intention to implement. Personnel Loa Andersson (loa@li.nu) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From ietfc@btconnect.com Fri Sep 30 04:06:58 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C9921F84AA for ; Fri, 30 Sep 2011 04:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NfYt+Bz189w for ; Fri, 30 Sep 2011 04:06:57 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id B235F21F8491 for ; Fri, 30 Sep 2011 04:06:55 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr09.btconnect.com with SMTP id EPE35300; Fri, 30 Sep 2011 12:09:45 +0100 (BST) Message-ID: <001001cc7f58$75712260$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Carlos Pignataro" , References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com><00e701cc7770$02401b60$4001a8c0@gateway.2wire.net><019301cc7838$45f53020$4001a8c0@gateway.2wire.net> <4E83383A.3030508@cisco.com> Date: Fri, 30 Sep 2011 12:05:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E85A379.006E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.30.94815:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __STOCK_PHRASE_24, __CP_NAME_BODY, __CP_URI_IN_BODY, __C230066_P2, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E85A37A.00A5,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [mpls] New VersionNotification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 11:06:58 -0000 ----- Original Message ----- From: "Carlos Pignataro" To: Sent: Wednesday, September 28, 2011 5:07 PM > Tom, > > Please find one or two additional comments inline. > > Note also we posted > > addressing your IANA comment, diffs at > . > > On 9/22/2011 5:42 AM, Mach Chen wrote: > > Hi Tom, > > > > Please see inline... > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > >> t.petch > >> Sent: Wednesday, September 21, 2011 4:27 PM > >> To: Mach Chen; mpls@ietf.org > >> Cc: ppan@infinera.com > >> > >> Mach > >> > >> Since you mention updating > >> draft-ietf-mpls-return-path-specified-lsp-ping > >> below, I offer two more revolutionary ideas. > >> > >> First is the relationship between the subTLVs of TLV Type1 and those of TLV > >> Type21. Looking at the IANA page, I think that IANA have the same problem > >> as I > >> do. Are the subTLVs of TLV Type21 intended to approximate to those of > >> Type1, > >> be an exact match at this point in time (a fast moving target with three I-Ds > >> with the IESG and RFC Editor), be an exact match for all time (with the > >> implications on future editors being aware of that) r what? (I think that the > >> IANA page is currently a 'what?' :-) > > > > Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for Type21 TLV, and vice versa. > > > > Strictly speaking, Type21 is totally independent of Type1 TLV, it just "borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and their sub-TLVs registries should be created, updated and maintained independently. > > > >> > >> Second, we are getting several RFC updating the registry that RFC4379 > >> established, which makes it harder to find what is defined where and to make > >> subsequent updates accurate, so the fewer RFC, the better. > > > > I basically agree with you here, but the practice of the IETF normally like this, a spec and then subsequent extensions with time. > > > > I disagree. Nothing wrong with multiple RFCs updating a specific > registry -- that's actually potentially a good thing if it speaks to > protocol growth and adoption! It is a characteristic of the IETF, perhaps truth 13, to produce small incremental steps, and neglect the larger picture. It is certainly easier to produce an I-D and RFC which is short and only covers a small part of the solution. But a year or two down the line, with 10 or 20 or 50 RFC to go through to assemble the big picture, it is much more work, more mistake-prone, for all involved to track back what a value in a field means (in this instance how the length of a field is defined differently in different TLV or what the current meaning of subtype 10 is); TCP might be the poster child for this. To produce fewer, larger RFC is, in the long run, more productive for all but the writers of short RFC. The fact that both these RFC impact the same registry does link them, willy nilly, they are both about LSP Ping and they are both saying things about subTypes to Type one and that, for me, needs more clarification that is currently in the I-Ds, if only to say that Type 1 and Type 21 are completely independent and any updates to Type 1 after RFC4379 should be ignored (all much easier with just the one RFC). Tom Petch > > I also do not think there is confusion since registries have a > "Reference" column with a pointer to the document (not even necessarily > an RFC in general) that is authoritative for a given entry. Lastly, > minimizing RFC.count by potentially agglutinating different issues > together is actually not something I'd recomment; in fact, Truth #5 of > comes to mind. > > >> So were the > >> chairs > >> to poll for the adoption of > >> draft-chen-mpls-ipv6-pw-lsp-ping-01 > >> I would oppose, rather seeing its content, important but slight, rolled into > >> draft-ietf-mpls-return-path-specified-lsp-ping > > IMHO, this is putting the cart before the horse. These are not documents > created to update IANA registries. These are protocol documents with > completely different goals, solving totally different problems. Both > update the same registry, as a consequence, as a means and not an end. > > Thanks, > > -- Carlos. > > > > > I personally prefer to let them separate, because the two drafts have different purposes and functions. If the WG has the consensus to do it, I will be OK with that. > > > > Best regards, > > Mach > > > >> which is the I-D, after all, that creates much of the complexity by introducing > >> TLV Type 21. > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Mach Chen" > >> To: "t.petch" ; > >> Cc: > >> Sent: Wednesday, September 21, 2011 8:28 AM > >> > >>> Hi Tom, > >>> > >>> Many thanks for your comments. > >>> > >>> Please see my response inline... > >>> > >>>> > >>>> Mach > >>>> > >>>> It looks ok, but I sort of get worried when I have to spend too much time > >>>> working out the details. Specifically, the IANA registries that RFC4379 > >>>> created > >>>> have been given names by IANA, even though RFC4379 itself did not do so, > >> so > >> I > >>>> think that this I-D should use these names. The registry in question, > >> MPLS - > >>>> LSP Ping Parameters - TLVs and sub-TLVs, > >>> > >>> Good suggestion, will do that in the later version. > >>> > >>>> already has four I-Ds making early > >>>> allocations to it so it is quite a big and volatile registry. > >>>> > >>>> Technically this is not a problem but it sort of worries me. This I-D is in > >> a > >>>> sense putting right a lack of foresight in RFC4379, nailing down what > >> RFC4379 > >>>> might have nailed down, so is there anything still missing that needs > >> nailing > >>>> down? I cannot see anything but think I am probably missing something:-( > >>> > >>> I did a rough checking when I wrote this draft, and found that the PW FEC is > >> the only one that needs nailing down, which impacts two documents, one is > >> RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. > >>> > >>>> > >>>> Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which > >> you > >>>> are updating three. TLV Type21 has 19 sub-TLVs which closely parallel > >> those > >>>> of > >>>> Type 1 which you are not updating (ok there is another I-D that should do so > >> but > >>>> have the authors of that I-D - namely you! - any thoughts on this?). Should > >> the > >>>> registry be looked at more widely to see if it can better be rationalised? > >>> > >>> As the author of the two drafts, I have noticed that and have plan to update > >> the return-path-specified-lsp-ping draft, and make a point to this new draft is > >> the straightforward and simple solution. > >>> > >>> Since that draft is still working in progress and has the common author, it's > >> easier to update. > >>> > >>> Best regards, > >>> Mach > >>> > >>>> > >>>> Tom Petch > >>>> > >>>>> > >>>>> Thanks, > >>>>> Mach > >>>>> > >>>>> ----Original Message----- > >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>>>>> Sent: Wednesday, August 17, 2011 11:08 AM > >>>>>> To: Mach Chen > >>>>>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; > >>>> cpignata@cisco.com > >>>>>> Subject: New Version Notification for > >>>> draft-chen-mpls-ipv6-pw-lsp-ping-01.txt > >>>>>> > >>>>>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been > >>>>>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF > >>>> repository. > >>>>>> > >>>>>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping > >>>>>> Revision: 01 > >>>>>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs > >>>>>> Creation date: 2011-08-16 > >>>>>> WG ID: Individual Submission > >>>>>> Number of pages: 9 > >>>>>> > >>>>>> Abstract: > >>>>>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) > >> Ping > >>>>>> and Traceroute mechanisms are commonly used to detect and > >> isolate > >>>>>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. > >>>>>> The PW LSP Ping and Traceroute elements, however, are not > >> specified > >>>>>> for IPv6 address usage. > >>>>>> > >>>>>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack in > >>>>>> the LSP Ping and Traceroute mechanism are implicitly defined only > >> for > >>>>>> IPv4 Provider Edge (PEs) routers, and are not applicable for the case > >>>>>> where PEs use IPv6 addresses. There is, additionally, a degree of > >>>>>> potential ambiguity in the specification of these sub-TLVs since the > >>>>>> address family is not explicitly specified but it is to be inferred > >>>>>> from the sub-TLV length. > >>>>>> > >>>>>> This document updates RFC4379 to explicitly constraint these > >> existing > >>>>>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP > >>>>>> Ping to the IPv6 scenario where an IPv6 LDP session is used to > >> signal > >>>>>> the Pseudowire (i.e., where the Sender's and Receiver's IP > >> addresses > >>>>>> are IPv6 addresses.) This is done by defining two new LSP Ping > >> sub- > >>>>>> TLVs for IPv6 Pseudowire FECs. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The IETF Secretariat > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Fri Sep 30 05:43:29 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDDF21F8B76 for ; Fri, 30 Sep 2011 05:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.59 X-Spam-Level: X-Spam-Status: No, score=-109.59 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlehgOcB5Sag for ; Fri, 30 Sep 2011 05:43:28 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E221F8B70 for ; Fri, 30 Sep 2011 05:43:28 -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 p8UCkIXV024574; Fri, 30 Sep 2011 08:46:18 -0400 (EDT) Received: from [10.82.241.40] (rtp-vpn2-296.cisco.com [10.82.241.40]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p8UCkIof021836; Fri, 30 Sep 2011 08:46:18 -0400 (EDT) Message-ID: <4E85BA19.10709@cisco.com> Date: Fri, 30 Sep 2011 08:46:17 -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.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "t.petch" References: <20110817030758.30204.29021.idtracker@ietfa.amsl.com><00e701cc7770$02401b60$4001a8c0@gateway.2wire.net><019301cc7838$45f53020$4001a8c0@gateway.2wire.net> <4E83383A.3030508@cisco.com> <001001cc7f58$75712260$4001a8c0@gateway.2wire.net> In-Reply-To: <001001cc7f58$75712260$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.3.2 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: mpls@ietf.org Subject: Re: [mpls] New VersionNotification fordraft-chen-mpls-ipv6-pw-lsp-ping-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 12:43:30 -0000 On 9/30/2011 6:05 AM, t.petch wrote: > > ----- Original Message ----- > From: "Carlos Pignataro" > To: > Sent: Wednesday, September 28, 2011 5:07 PM >> Tom, >> >> Please find one or two additional comments inline. >> >> Note also we posted >> >> addressing your IANA comment, diffs at >> . >> >> On 9/22/2011 5:42 AM, Mach Chen wrote: >>> Hi Tom, >>> >>> Please see inline... >>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>>> t.petch >>>> Sent: Wednesday, September 21, 2011 4:27 PM >>>> To: Mach Chen; mpls@ietf.org >>>> Cc: ppan@infinera.com >>>> >>>> Mach >>>> >>>> Since you mention updating >>>> draft-ietf-mpls-return-path-specified-lsp-ping >>>> below, I offer two more revolutionary ideas. >>>> >>>> First is the relationship between the subTLVs of TLV Type1 and those of TLV >>>> Type21. Looking at the IANA page, I think that IANA have the same problem >>>> as I >>>> do. Are the subTLVs of TLV Type21 intended to approximate to those of >>>> Type1, >>>> be an exact match at this point in time (a fast moving target with three > I-Ds >>>> with the IESG and RFC Editor), be an exact match for all time (with the >>>> implications on future editors being aware of that) r what? (I think that > the >>>> IANA page is currently a 'what?' :-) >>> >>> Type 21 TLV is intended to reuse(void redefining) the sub-TLVs(some of but > not all of them) of Type1 TLV as it needs, the sub-TLVs of the two TLVs are not > necessarily identical. Some sub-TLVs defined for Type1 TLV are not needed for > Type21 TLV, and vice versa. >>> >>> Strictly speaking, Type21 is totally independent of Type1 TLV, it just > "borrows" some sub-TLVs definition from Type1 TLV. So the relevant TLVs and > their sub-TLVs registries should be created, updated and maintained > independently. >>> >>>> >>>> Second, we are getting several RFC updating the registry that RFC4379 >>>> established, which makes it harder to find what is defined where and to > make >>>> subsequent updates accurate, so the fewer RFC, the better. >>> >>> I basically agree with you here, but the practice of the IETF normally like > this, a spec and then subsequent extensions with time. >>> >> >> I disagree. Nothing wrong with multiple RFCs updating a specific >> registry -- that's actually potentially a good thing if it speaks to >> protocol growth and adoption! > > It is a characteristic of the IETF, perhaps truth 13, to produce small > incremental steps, and neglect the larger picture. It is certainly easier > to produce an I-D and RFC which is short and only covers a small > part of the solution. But a year or two down the line, with 10 or > 20 or 50 RFC to go through to assemble the big picture, it is much > more work, more mistake-prone, for all involved to track back what > a value in a field means (in this instance how the length of a field is > defined differently in different TLV or what the current meaning of > subtype 10 is); TCP might be the poster child for this. > Keeping the focus of the comment on the particular case at hand, you are assuming there is a common big picture between these two I-Ds (or between all I-Ds adding sub-TLVs to TLV 1). Instead they are (all) rather independent. You are also assuming in this comment that the big picture will stay unchanged without any need for pruning. I do very much agree with you that there is a need to be quite precise on the definition of a TLV (21) that mimics/follows another TLV (1). However, amalgamating and blending documents is, IMHO, the wrong conclusion. This is a comment that should be targeted to draft-ietf-mpls-return-path-specified-lsp-ping, and I think you wrote before the level of precision needed with three alternatives. If you look at , does draft-ietf-mpls-return-path-specified-lsp-ping need to be combined with all I-Ds that deal with TLV Type 1, namely {RFC-ietf-mpls-p2mp-lsp-ping + draft-ietf-mpls-tp-on-demand-cv + draft-chen-mpls-ipv6-pw-lsp-ping + ...}? I expect not. > To produce fewer, larger RFC is, in the long run, more productive for > all but the writers of short RFC. Now, onto the generalities front, sure: as few as possible, but not fewer. I think it is more important to have appropriate definitions, pointers and relationships. > > The fact that both these RFC impact the same registry does link them, > willy nilly, they are both about LSP Ping and they are both saying > things about subTypes to Type one and that, for me, > needs more clarification that is currently in the I-Ds, if > only to say that Type 1 and Type 21 are completely independent and any > updates to Type 1 after RFC4379 should be ignored (all much easier with > just the one RFC). I know, there are a lot of intersection points between a lot of documents, all from the same WG, all written in English, updating the same sub-registry, and the same TLV within that sub-registry. At least four or five I-Ds match these as per above, willy nilly. But, IMHO, key is what is the intended goal (i.e., problem being solved) in each doc, and *all* those are quite independent. Thanks, -- Carlos. > > Tom Petch >> >> I also do not think there is confusion since registries have a >> "Reference" column with a pointer to the document (not even necessarily >> an RFC in general) that is authoritative for a given entry. Lastly, >> minimizing RFC.count by potentially agglutinating different issues >> together is actually not something I'd recomment; in fact, Truth #5 of >> comes to mind. >> >>>> So were the >>>> chairs >>>> to poll for the adoption of >>>> draft-chen-mpls-ipv6-pw-lsp-ping-01 >>>> I would oppose, rather seeing its content, important but slight, rolled > into >>>> draft-ietf-mpls-return-path-specified-lsp-ping >> >> IMHO, this is putting the cart before the horse. These are not documents >> created to update IANA registries. These are protocol documents with >> completely different goals, solving totally different problems. Both >> update the same registry, as a consequence, as a means and not an end. >> >> Thanks, >> >> -- Carlos. >> >>> >>> I personally prefer to let them separate, because the two drafts have > different purposes and functions. If the WG has the consensus to do it, I will > be OK with that. >>> >>> Best regards, >>> Mach >>> >>>> which is the I-D, after all, that creates much of the complexity by > introducing >>>> TLV Type 21. >>>> >>>> Tom Petch >>>> >>>> ----- Original Message ----- >>>> From: "Mach Chen" >>>> To: "t.petch" ; >>>> Cc: >>>> Sent: Wednesday, September 21, 2011 8:28 AM >>>> >>>>> Hi Tom, >>>>> >>>>> Many thanks for your comments. >>>>> >>>>> Please see my response inline... >>>>> >>>>>> >>>>>> Mach >>>>>> >>>>>> It looks ok, but I sort of get worried when I have to spend too much time >>>>>> working out the details. Specifically, the IANA registries that RFC4379 >>>>>> created >>>>>> have been given names by IANA, even though RFC4379 itself did not do so, >>>> so >>>> I >>>>>> think that this I-D should use these names. The registry in question, >>>> MPLS - >>>>>> LSP Ping Parameters - TLVs and sub-TLVs, >>>>> >>>>> Good suggestion, will do that in the later version. >>>>> >>>>>> already has four I-Ds making early >>>>>> allocations to it so it is quite a big and volatile registry. >>>>>> >>>>>> Technically this is not a problem but it sort of worries me. This I-D is > in >>>> a >>>>>> sense putting right a lack of foresight in RFC4379, nailing down what >>>> RFC4379 >>>>>> might have nailed down, so is there anything still missing that needs >>>> nailing >>>>>> down? I cannot see anything but think I am probably missing something:-( >>>>> >>>>> I did a rough checking when I wrote this draft, and found that the PW FEC > is >>>> the only one that needs nailing down, which impacts two documents, one is >>>> RFC4379, the other is draft-ietf-mpls-return-path-specified-lsp-ping. >>>>> >>>>>> >>>>>> Well, I can see something small, that TLV Type 1 has 23 sub-TLVs of which >>>> you >>>>>> are updating three. TLV Type21 has 19 sub-TLVs which closely parallel >>>> those >>>>>> of >>>>>> Type 1 which you are not updating (ok there is another I-D that should do > so >>>> but >>>>>> have the authors of that I-D - namely you! - any thoughts on this?). > Should >>>> the >>>>>> registry be looked at more widely to see if it can better be > rationalised? >>>>> >>>>> As the author of the two drafts, I have noticed that and have plan to > update >>>> the return-path-specified-lsp-ping draft, and make a point to this new > draft is >>>> the straightforward and simple solution. >>>>> >>>>> Since that draft is still working in progress and has the common author, > it's >>>> easier to update. >>>>> >>>>> Best regards, >>>>> Mach >>>>> >>>>>> >>>>>> Tom Petch >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Mach >>>>>>> >>>>>>> ----Original Message----- >>>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>>> Sent: Wednesday, August 17, 2011 11:08 AM >>>>>>>> To: Mach Chen >>>>>>>> Cc: ppan@infinera.com; rajiva@cisco.com; Mach Chen; >>>>>> cpignata@cisco.com >>>>>>>> Subject: New Version Notification for >>>>>> draft-chen-mpls-ipv6-pw-lsp-ping-01.txt >>>>>>>> >>>>>>>> A new version of I-D, draft-chen-mpls-ipv6-pw-lsp-ping-01.txt has been >>>>>>>> successfully submitted by Mach(Guoyi) Chen and posted to the IETF >>>>>> repository. >>>>>>>> >>>>>>>> Filename: draft-chen-mpls-ipv6-pw-lsp-ping >>>>>>>> Revision: 01 >>>>>>>> Title: Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs >>>>>>>> Creation date: 2011-08-16 >>>>>>>> WG ID: Individual Submission >>>>>>>> Number of pages: 9 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) >>>> Ping >>>>>>>> and Traceroute mechanisms are commonly used to detect and >>>> isolate >>>>>>>> data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. >>>>>>>> The PW LSP Ping and Traceroute elements, however, are not >>>> specified >>>>>>>> for IPv6 address usage. >>>>>>>> >>>>>>>> Specifically, the Pseudowire FEC sub-TLVs for the Target FEC Stack > in >>>>>>>> the LSP Ping and Traceroute mechanism are implicitly defined only >>>> for >>>>>>>> IPv4 Provider Edge (PEs) routers, and are not applicable for the > case >>>>>>>> where PEs use IPv6 addresses. There is, additionally, a degree of >>>>>>>> potential ambiguity in the specification of these sub-TLVs since the >>>>>>>> address family is not explicitly specified but it is to be inferred >>>>>>>> from the sub-TLV length. >>>>>>>> >>>>>>>> This document updates RFC4379 to explicitly constraint these >>>> existing >>>>>>>> PW FEC sub-TLVs for IPv4 LDP sessions, and extends Pseudowire LSP >>>>>>>> Ping to the IPv6 scenario where an IPv6 LDP session is used to >>>> signal >>>>>>>> the Pseudowire (i.e., where the Sender's and Receiver's IP >>>> addresses >>>>>>>> are IPv6 addresses.) This is done by defining two new LSP Ping >>>> sub- >>>>>>>> TLVs for IPv6 Pseudowire FECs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Fri Sep 30 06:47:12 2011 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770421F8678; Fri, 30 Sep 2011 06:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhywisqcPRVU; Fri, 30 Sep 2011 06:47:12 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5101321F8610; Fri, 30 Sep 2011 06:47:11 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id A5F1A2A8002; Fri, 30 Sep 2011 15:50:02 +0200 (CEST) Message-ID: <4E85C90A.5090705@pi.nu> Date: Fri, 30 Sep 2011 15:50:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , pwe3@ietf.org, "rtg-ads@tools.ietf.org" Subject: [mpls] first set of mpls-tp documents completed X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 13:47:12 -0000 Working Group(s), late yesterday we passed an important Milestone; I did not realize it until some time after it happened, maybe since the milstone is not even documented in the WG charter. The working group chairs and our responsible AD have for some time worked with what we have called "the first set of MPLS-TP documents". That set includes includes 20 documents and we have had more than 40 editors/authors active. The set has two defining criteria: - it should be implementable - it should cover what ITU-T needs to reference in their MPLS-TP Recommendations What happened last night was that , more less as part of a normal business day, we requested publication of the last document on that set! This completes the working groups effort with these documents; chairs, document shepherds and authors may have to assist the IESG and the RFC Editor in their job, but the working group job is done! We also have further MPLS-TP documents to progress, so while recognizing the mile stone, it is easy to find new documents to review and comment on; please do so! I'd like to take take this opportunity, and I'm sure that my co-chairs and ADs join me, to congratulate and thank the working groups, the 40+ authors, everyone that reviewed and commented on the documents. We have done a good job and made progress! /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13