From diego.caviglia@ericsson.com Thu Apr 1 04:45:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7129B3A6846 for ; Thu, 1 Apr 2010 04:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5-Xf3Drteoy for ; Thu, 1 Apr 2010 04:45:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0BD593A62C1 for ; Thu, 1 Apr 2010 04:45:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-7d-4bb4876889dc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BA.25.23532.86784BB4; Thu, 1 Apr 2010 13:45:44 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 13:45:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAD190.C8EAA44C" Date: Thu, 1 Apr 2010 13:45:09 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: GMPLS Operation Logger pool for interest Thread-Index: AcrRkMf7gNsyzBxnTy6pZUAgKd+Uuw== From: "Diego Caviglia" To: X-OriginalArrivalTime: 01 Apr 2010 11:45:10.0783 (UTC) FILETIME=[C8CCA0F0:01CAD190] X-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 11:45:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD190.C8EAA44C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD190.C8EAA44C" ------_=_NextPart_002_01CAD190.C8EAA44C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMPers I'd like to hear the feeling of the WG about starting a work on GMPLS logging. =20 The very basic idea is to have something to synchronize all the time on the NEs and to have a compressed and optimized client server protocol to upload GMPLS information to a centralized server. Time synchronization is essential to rebuild the sequence of events and actions that happens to a certain LSP. =20 GMPLS is becoming too complex and too business critical to relay on SNMCP for logging. =20 On the other hand is impossible to store on the NE itself all the GMPLS logging. =20 BR Diego =20 =20 =20 DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 =20 This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer =20 =20 ------_=_NextPart_002_01CAD190.C8EAA44C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = CCAMPers

            I’d like to hear the feeling of the WG about starting a work on = GMPLS logging.

 

The very basic idea = is to have something to synchronize all the time on the NEs and to have a = compressed and optimized client server protocol to upload GMPLS information to a centralized server.  Time synchronization is essential to rebuild = the sequence of events and actions that happens to a certain = LSP.

 

GMPLS is becoming = too complex and too business critical to relay on SNMCP for = logging.

 

On the other hand = is impossible to store on the NE itself all the GMPLS = logging.

 

BR


Diego

 

 

3Dline

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, = Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com



3DEricsson





This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_discla= imer

 

------_=_NextPart_002_01CAD190.C8EAA44C-- ------_=_NextPart_001_01CAD190.C8EAA44C Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== ------_=_NextPart_001_01CAD190.C8EAA44C Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== ------_=_NextPart_001_01CAD190.C8EAA44C-- From diego.caviglia@ericsson.com Thu Apr 1 06:28:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC3A3A684F for ; Thu, 1 Apr 2010 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rThduj7qtE1w for ; Thu, 1 Apr 2010 06:28:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6DECA3A6784 for ; Thu, 1 Apr 2010 06:28:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-99-4bb49f8758e8 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E8.81.23532.78F94BB4; Thu, 1 Apr 2010 15:28:39 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 15:28:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAD19F.3D378154" Date: Thu, 1 Apr 2010 15:28:35 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] GMPLS Operation Logger pool for interest Thread-Index: AcrRkMf7gNsyzBxnTy6pZUAgKd+UuwAAfbQGAAMXpEA= References: From: "Diego Caviglia" To: "Thomas D. Nadeau" , X-OriginalArrivalTime: 01 Apr 2010 13:28:38.0939 (UTC) FILETIME=[3D260EB0:01CAD19F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:28:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD19F.3D378154 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD19F.3D378154" ------_=_NextPart_002_01CAD19F.3D378154 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the feedback my thought was that at least = requirements and framework should be in the scope of CCAMP, by the way = do you think is worth to have this work done? =20 BR =20 Diego =20 =20 =20 DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 =20 This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 ________________________________ From: Thomas D. Nadeau [mailto:tom.nadeau@bt.com]=20 Sent: gioved=EC 1 aprile 2010 13.59 To: Diego Caviglia; ccamp@ietf.org Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest =20 This seems like something better done in one of the Ops/NM area WGs. --Tom On 4/1/10 7:45 AM, "Diego Caviglia" wrote: Hi CCAMPers I'd like to hear the feeling of the WG about starting a work = on GMPLS logging. =20 The very basic idea is to have something to synchronize all the time on = the NEs and to have a compressed and optimized client server protocol to = upload GMPLS information to a centralized server. Time synchronization = is essential to rebuild the sequence of events and actions that happens = to a certain LSP. =20 GMPLS is becoming too complex and too business critical to relay on = SNMCP for logging. =20 On the other hand is impossible to store on the NE itself all the GMPLS = logging. =20 BR Diego =20 DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer = =20 ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 ------_=_NextPart_002_01CAD19F.3D378154 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [CCAMP] GMPLS Operation Logger pool for interest

Hi = Tom,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Thanks for the feedback my thought was that at least requirements and framework should be in the = scope of CCAMP, by the way do you think is worth to have this work = done?

 

BR

 

Diego

 

 

=

3Dline

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, = Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com



3DEricsson





This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email= _disclaimer

From: = Thomas D. Nadeau [mailto:tom.nadeau@bt.com]
Sent: gioved=EC 1 aprile = 2010 13.59
To: Diego Caviglia; = ccamp@ietf.org
Subject: Re: [CCAMP] = GMPLS Operation Logger pool for interest

 


    This seems like something better done in one of = the Ops/NM area WGs.

    --Tom



On 4/1/10 7:45 AM, "Diego Caviglia" <diego.caviglia@ericsson.com> = wrote:

Hi CCAMPers
           I’= ;d like to hear the feeling of the WG about starting a work on GMPLS = logging.
 
The very basic idea is to have something to synchronize all the time on = the NEs and to have a compressed and optimized client server protocol to upload = GMPLS information to a centralized server.  Time synchronization is = essential to rebuild the sequence of events and actions that happens to a certain = LSP.
 
GMPLS is becoming too complex and too business critical to relay on = SNMCP for logging.
 
On the other hand is impossible to store on the NE itself all the GMPLS logging.
 
BR

Diego
 


DIEGO CAVIGLIA
Strategic Product Manager

Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, = Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com








This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_discla= imer <http://www.ericsson.com= /email_disclaimer>

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

 

------_=_NextPart_002_01CAD19F.3D378154-- ------_=_NextPart_001_01CAD19F.3D378154 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== ------_=_NextPart_001_01CAD19F.3D378154 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== ------_=_NextPart_001_01CAD19F.3D378154-- From kam.lam@alcatel-lucent.com Thu Apr 1 07:18:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFB33A6959 for ; Thu, 1 Apr 2010 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.342 X-Spam-Level: * X-Spam-Status: No, score=1.342 tagged_above=-999 required=5 tests=[AWL=-2.210, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlXWSgY4f0sY for ; Thu, 1 Apr 2010 07:18:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6FA3A3A69D3 for ; Thu, 1 Apr 2010 07:18:10 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o31EIe50008047; Thu, 1 Apr 2010 09:18:40 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o31EIdEM029054; Thu, 1 Apr 2010 09:18:39 -0500 (CDT) Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 1 Apr 2010 09:18:39 -0500 From: "Lam, Hing-Kam (Kam)" To: Diego Caviglia , "ccamp@ietf.org" Date: Thu, 1 Apr 2010 09:18:38 -0500 Thread-Topic: GMPLS Operation Logger pool for interest Thread-Index: AcrRkMf7gNsyzBxnTy6pZUAgKd+UuwAFK91A Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD54126C134@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 14:18:44 -0000 --_005_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_ Content-Type: multipart/alternative; boundary="_000_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_" --_000_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Diego, I have couple quick questions for clarification. You said "Time synchronization is ...". Do you mean "Timely synchronization= ..." instead? To me, time synchronization might mean synchronization of th= e real-time wall clock or the bit frequency for transport network. You said "... on SNMCP for logging". Do you mean "SNMP" instead? Regards, Kam ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= iego Caviglia Sent: Thursday, April 01, 2010 7:45 AM To: ccamp@ietf.org Subject: [CCAMP] GMPLS Operation Logger pool for interest Hi CCAMPers I'd like to hear the feeling of the WG about starting a work on= GMPLS logging. The very basic idea is to have something to synchronize all the time on the= NEs and to have a compressed and optimized client server protocol to uploa= d GMPLS information to a centralized server. Time synchronization is essen= tial to rebuild the sequence of events and actions that happens to a certai= n LSP. GMPLS is becoming too complex and too business critical to relay on SNMCP f= or logging. On the other hand is impossible to store on the NE itself all the GMPLS log= ging. BR Diego DIEGO CAVIGLIA Strategic Product Manager Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com [cid:image002.gif@01CAD184.5D3BD150] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Diego,

 

I have couple quick questions for clarification.

 

You said “Time synchronization is …”. Do you mea= n “Timely synchronization …” instead? To me, time synchronization might m= ean synchronization of the real-time wall clock or the bit frequency for transp= ort network.

 

You said “… on SNMCP for logging= ”. Do you mea= n “SNMP” instead?

 

Regards,

Kam

<= span style=3D'font-size:12.0pt;color:navy'> 

<= span style=3D'font-size:12.0pt;color:navy'> 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Beha= lf Of Diego Caviglia
Sent: Thursday, April 01, 20= 10 7:45 AM
To: ccamp@ietf.org
Subject: [CCAMP] GMPLS Opera= tion Logger pool for interest

 

Hi CCAMPers=

   &nbs= p;        I’d like to hear the feeling of the WG about starting a work on GMPLS logging.

 

The very basic idea is= to have something to synchronize all the time on the NEs and to have a compres= sed and optimized client server protocol to upload GMPLS information to a centralized server.  Time synchronization is essential to rebuild the sequence of events and actions that happens to a certain LSP.

 

GMPLS is becoming too complex and too business critical to relay on SNMCP for logging.=

 

On the other hand is impossible to store on the NE itself all the GMPLS logging.

 

BR


Diego

 

 

3Dline

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com



3DEricsson

 =



This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaim= er

 

--_000_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_-- --_005_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=4024; creation-date="Thu, 01 Apr 2010 09:18:38 GMT"; modification-date="Thu, 01 Apr 2010 09:18:38 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== --_005_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1417; creation-date="Thu, 01 Apr 2010 09:18:38 GMT"; modification-date="Thu, 01 Apr 2010 09:18:38 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_005_7F76AEFB05C38145BABA0D545E3CFFD54126C134USNAVSXCHMBSA2n_-- From diego.caviglia@ericsson.com Thu Apr 1 07:32:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF0C3A6912 for ; Thu, 1 Apr 2010 07:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U210xM5yBVsX for ; Thu, 1 Apr 2010 07:32:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1D7D73A688C for ; Thu, 1 Apr 2010 07:32:48 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-41-4bb4aeb0a6a7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 97.A7.23740.0BEA4BB4; Thu, 1 Apr 2010 16:33:20 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:31:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CAD1A8.0FD22288" Date: Thu, 1 Apr 2010 16:31:46 +0200 Message-ID: In-Reply-To: <7F76AEFB05C38145BABA0D545E3CFFD54126C134@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: GMPLS Operation Logger pool for interest Thread-Index: AcrRkMf7gNsyzBxnTy6pZUAgKd+UuwAFK91AAACbi9A= References: <7F76AEFB05C38145BABA0D545E3CFFD54126C134@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Diego Caviglia" To: "Lam, Hing-Kam (Kam)" , X-OriginalArrivalTime: 01 Apr 2010 14:31:48.0455 (UTC) FILETIME=[0FE04F70:01CAD1A8] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 14:32:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD1A8.0FD22288 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CAD1A8.0FD22288" ------_=_NextPart_002_01CAD1A8.0FD22288 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Kam Thanks for your comments, yes a mean timely synchronization = and yes is SNMP. =20 BR =20 Diego =20 =20 =20 DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 =20 This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 ________________________________ From: Lam, Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com]=20 Sent: gioved=EC 1 aprile 2010 16.19 To: Diego Caviglia; ccamp@ietf.org Subject: RE: GMPLS Operation Logger pool for interest =20 Hi Diego, =20 I have couple quick questions for clarification. =20 You said "Time synchronization is ...". Do you mean "Timely = synchronization ..." instead? To me, time synchronization might mean = synchronization of the real-time wall clock or the bit frequency for = transport network. =20 You said "... on SNMCP for logging". Do you mean "SNMP" instead? =20 Regards, Kam =20 =20 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Diego Caviglia Sent: Thursday, April 01, 2010 7:45 AM To: ccamp@ietf.org Subject: [CCAMP] GMPLS Operation Logger pool for interest =20 Hi CCAMPers I'd like to hear the feeling of the WG about starting a work = on GMPLS logging. =20 The very basic idea is to have something to synchronize all the time on = the NEs and to have a compressed and optimized client server protocol to = upload GMPLS information to a centralized server. Time synchronization = is essential to rebuild the sequence of events and actions that happens = to a certain LSP. =20 GMPLS is becoming too complex and too business critical to relay on = SNMCP for logging. =20 On the other hand is impossible to store on the NE itself all the GMPLS = logging. =20 BR Diego =20 =20 DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 =20 This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer = =20 =20 ------_=_NextPart_002_01CAD1A8.0FD22288 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

HI Kam

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0Thanks for your comments, yes a mean timely synchronization and yes is = SNMP.

 

BR

 

Diego

 

 

=

3Dline

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, = Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com



3DEricsson





This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email= _disclaimer

From: Lam, = Hing-Kam (Kam) [mailto:kam.lam@alcatel-lucent.com]
Sent: gioved=EC 1 aprile = 2010 16.19
To: Diego Caviglia; = ccamp@ietf.org
Subject: RE: GMPLS = Operation Logger pool for interest

 

Hi = Diego,

 

I have couple quick questions for clarification.

 

You said “Time synchronization is …”. Do you = mean “Timely synchronization …” instead? To me, time synchronization might mean synchronization of the real-time wall clock = or the bit frequency for transport network.

 

You said “… on SNMCP for logging”. Do you = mean “SNMP” instead?

 

Regards,

Kam

 

=

 

=

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Diego Caviglia
Sent: Thursday, April 01, = 2010 7:45 AM
To: ccamp@ietf.org
Subject: [CCAMP] GMPLS = Operation Logger pool for interest

 

Hi = CCAMPers

            I’d like to hear the feeling of the WG about starting a work on = GMPLS logging.

 

The very basic idea = is to have something to synchronize all the time on the NEs and to have a = compressed and optimized client server protocol to upload GMPLS information to a centralized server.  Time synchronization is essential to rebuild = the sequence of events and actions that happens to a certain = LSP.

 

GMPLS is becoming = too complex and too business critical to relay on SNMCP for = logging.

 

On the other hand = is impossible to store on the NE itself all the GMPLS = logging.

 

BR


Diego

 

 

3Dline

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, = Italy
Phone +390106003736
Mobile +393357181762
diego.caviglia@ericsson.com
www.ericsson.com



3DEricsson

 



This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_discla= imer

 

------_=_NextPart_002_01CAD1A8.0FD22288-- ------_=_NextPart_001_01CAD1A8.0FD22288 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== ------_=_NextPart_001_01CAD1A8.0FD22288 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== ------_=_NextPart_001_01CAD1A8.0FD22288-- From adrian@olddog.co.uk Thu Apr 1 09:34:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADB03A6856 for ; Thu, 1 Apr 2010 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no2Uc3NhkdhX for ; Thu, 1 Apr 2010 09:34:40 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id ACCD23A6A1F for ; Thu, 1 Apr 2010 09:34:38 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o31GYtD2027363; Thu, 1 Apr 2010 17:34:56 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o31GYseL027358; Thu, 1 Apr 2010 17:34:55 +0100 Message-ID: <7CAEB9A747DF431B854F059F59AE833F@your029b8cecfe> From: "Adrian Farrel" To: Date: Thu, 1 Apr 2010 17:34:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:34:41 -0000 Hi, Just noticed that I sent this to the old CCAMP address while undergoing sleep deprivation torture in Anaheim. Cheers, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Kohei Shiomoto" Sent: Tuesday, March 23, 2010 5:55 PM Subject: draft-shiomoto-ccamp-switch-programming-01.txt > Hi, > > We just discussed this document at the microphone in Anaheim. > > The question was, what to do with it. > > To remind you, the Abstract says: > > The Resource Reservation Protocol (RSVP) has been extended to support > Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks. The protocol enables signaling > exchanges to establish Label Switched Paths (LSPs) that traverse > nodes and links to provide end-to-end data paths. Each node is > programmed with "cross-connect" information as the signaling messages > are processed. The cross-connection information instructs the node > how to forward data that it receives. > > End points of an LSP need to know when it is safe to start sending > data so that it is not misdelivered, and so that safety issues > specific to the data plane technology are satisfied. Likewise, all > label switching routers along the path of the LSP need to know when > to programme their data planes relative to sending control plane > messages. > > This document clarifies and summarises the RSVP-TE protocol exchanges > with relation to the programming of cross-connects along an LSP for > both unidirectional and bidirectional LSPs. This document does not > define any new procedures or protocol extensions, and defers > completely to the documents that provide normative references. The > clarifications set out in this document may also be used to help > interpret LSP establishment performance figures for MPLS-TE and GMPLS > devices. > > The purpose of the draft, therefore, was not to define any new procedures, > but to attempt to clarify the existing protocol RFCs. The draft is > Informational. > > The WG needs to decide (with the chairs judging the consensus and > determining the action) how we should pursue this. > > I gave three options at the meeting: > > 1. Kill the work (no interest or not helpful) > 2. Adopt as WG draft > 3. Pursue as independent RFC > > I would be happy to hear people's comments on the draft and the options. > > No doubt the WG chairs will want to make any calls for consensus according > to their priorities for the WG. > > Thanks, > Adrian From gregimirsky@gmail.com Thu Apr 1 18:16:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876013A69D2 for ; Thu, 1 Apr 2010 18:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=-1.619, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lseOBiItfCRZ for ; Thu, 1 Apr 2010 18:16:11 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id 2601F3A697A for ; Thu, 1 Apr 2010 18:16:06 -0700 (PDT) Received: by yxe10 with SMTP id 10so705273yxe.18 for ; Thu, 01 Apr 2010 18:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=V5dfrYTlzTDnjG5W4HO5beFqS5gj4gP27VlRKaUz8Ig=; b=C/KFPY1jewyV0P71H3cQvJpAuLMkK3xVroglSPSFtWsr5n1j9YZD8zI5PC6R2UYQkp 7TJQaoiUK4RMybhQZ3ZROLwI8roIcyDH4vZ7JkFX5hsavGdCoAN2XiTnWvg7xEwpT6Rj ar2RmSCft78bXgCi4sPwi3WnxV51N+gzr/Jx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sWj4WXmd19DQQjen+5Af142wUUV2an4xwutd8aznEEup7/nosGV+1yGVmYU393SR6i WirmmgAzZBl/VAHxKpG3EBc+EvZUTdOnmEYSwsl2rFgwh09X1kpHigxasMMpP1KwyG4N BebrJsVvW1cL8IEswQrFHUFAG+jjGvrscnR58= MIME-Version: 1.0 Received: by 10.90.106.16 with HTTP; Thu, 1 Apr 2010 18:16:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Apr 2010 18:16:35 -0700 Received: by 10.90.210.10 with SMTP id i10mr1916233agg.88.1270170995732; Thu, 01 Apr 2010 18:16:35 -0700 (PDT) Message-ID: From: Greg Mirsky To: Diego Caviglia , yaakov_s@rad.com Content-Type: multipart/related; boundary=00163630f0c70134dc048336bbad Cc: ccamp@ietf.org Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 01:16:13 -0000 --00163630f0c70134dc048336bbad Content-Type: multipart/alternative; boundary=00163630f0c70134d8048336bbac --00163630f0c70134d8048336bbac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Diego, I'd like to refer you to Timing over IP Connection and Transfer of Clock ( TICTOC ) WG. I've tried to follow work there and recall that group worked on summarizing requirements for time synchronization from various industries and applications but I cannot point you to the right document in archive . At the last meeting we discussed whether MPLS-TP might have specific requirements to timer synchronization (as I recall it). But I don't remembe= r anybody bringing specific GMPLS requirements yet. It might be interesting t= o look. I've added Yaakov Stein, group's chair, to the discussion. Regards, Greg On Thu, Apr 1, 2010 at 4:45 AM, Diego Caviglia wrote: > Hi CCAMPers > > I=92d like to hear the feeling of the WG about starting a wor= k on > GMPLS logging. > > > > The very basic idea is to have something to synchronize all the time on t= he > NEs and to have a compressed and optimized client server protocol to uplo= ad > GMPLS information to a centralized server. Time synchronization is > essential to rebuild the sequence of events and actions that happens to a > certain LSP. > > > > GMPLS is becoming too complex and too business critical to relay on SNMCP > for logging. > > > > On the other hand is impossible to store on the NE itself all the GMPLS > logging. > > > > BR > > > Diego > > > > > > [image: line] > > *DIEGO CAVIGLIA > Strategic Product Manager* > > > Ericsson Italy > Product Line PAIB > Via A. Negrone 1/A > Genoa, Italy > Phone +390106003736 > Mobile +393357181762 > diego.caviglia@ericsson.com > www.ericsson.com > > > > [image: Ericsson] > > > > > > This Communication is Confidential. We only send and receive email on the > basis of the term set out at www.ericsson.com/email_disclaimer > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > --00163630f0c70134d8048336bbac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Diego,
I'd like to refer you to Timing over IP Connection and T= ransfer of Clock (TICTOC) WG. I've tried to follow work there and recall that group= worked on summarizing requirements for time synchronization from various i= ndustries and applications but I cannot point you to the right document in = archive.
At the last meeting we discussed whether MPLS-TP might have specific requir= ements to timer synchronization (as I recall it). But I don't remember = anybody bringing specific GMPLS requirements yet. It might be interesting t= o look.
I've added Yaakov Stein, group's chair, to the discussion.

R= egards,
Greg

On Thu, Apr 1, 2010 at 4:= 45 AM, Diego Caviglia <diego.caviglia@ericsson.com> wrote:

Hi CCAM= Pers

=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 I=92d like to hear the feeling of the WG about starting a work on GMPLS logging.

=A0

The ver= y basic idea is to have something to synchronize all the time on the NEs and to have a compres= sed and optimized client server protocol to upload GMPLS information to a centralized server.=A0 Time synchronization is essential to rebuild the sequence of events and actions that happens to a certain LSP.=

=A0

GMPLS i= s becoming too complex and too business critical to relay on SNMCP for logging.

=A0

On the = other hand is impossible to store on the NE itself all the GMPLS logging.

=A0

BR


Diego

=A0

=A0

3D"line"

DIEGO CAVIGLIA
Strategic Product Manager


Ericsson = Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
diego.cavi= glia@ericsson.com
www.ericsson.com =



3D"Ericsson"



<= br>
This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer

=A0


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp


--00163630f0c70134d8048336bbac-- --00163630f0c70134dc048336bbad Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.0.2 R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== --00163630f0c70134dc048336bbad Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 0.0.1 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --00163630f0c70134dc048336bbad-- From prvs=67089019b0=sunwq@mit.edu Thu Apr 1 18:42:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E053A6A08 for ; Thu, 1 Apr 2010 18:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxgeqNkZykSv for ; Thu, 1 Apr 2010 18:42:06 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 159B63A69EC for ; Thu, 1 Apr 2010 18:42:00 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-c9-4bb54b895034 Received: from mailhub-4.mit.edu (MAILHUB-4.MIT.EDU [18.7.62.40]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 91.56.12528.98B45BB4; Thu, 1 Apr 2010 21:42:33 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-4.mit.edu (8.13.8/8.9.2) with ESMTP id o321gXfR029854; Thu, 1 Apr 2010 21:42:33 -0400 Received: from [192.168.6.42] ([202.120.39.240]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o321ghOj016073; Thu, 1 Apr 2010 21:42:51 -0400 (EDT) User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 02 Apr 2010 09:42:11 +0800 From: Weiqiang Sun To: Adrian Farrel , Message-ID: Thread-Topic: [CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt Thread-Index: AcrSBbZhn9DpkByCFkSCUX2FALdv8w== In-Reply-To: <7CAEB9A747DF431B854F059F59AE833F@your029b8cecfe> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 01:42:07 -0000 Adrian, I think it is a useful (though lightweight) document that captures something beyond the RSVP-TE specs and would be good to continue to progress in CCAMP. On the other hand, I think it might be better to add some text regarding the LSP recovery case. We would be happy to contribute to that part as it progresses. Thanks, Weiqiang On 4/2/10 12:34 AM, "Adrian Farrel" wrote: > Hi, > > Just noticed that I sent this to the old CCAMP address while undergoing > sleep deprivation torture in Anaheim. > > Cheers, > Adrian > ----- Original Message ----- > From: "Adrian Farrel" > To: > Cc: "Kohei Shiomoto" > Sent: Tuesday, March 23, 2010 5:55 PM > Subject: draft-shiomoto-ccamp-switch-programming-01.txt > > >> Hi, >> >> We just discussed this document at the microphone in Anaheim. >> >> The question was, what to do with it. >> >> To remind you, the Abstract says: >> >> The Resource Reservation Protocol (RSVP) has been extended to support >> Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) networks. The protocol enables signaling >> exchanges to establish Label Switched Paths (LSPs) that traverse >> nodes and links to provide end-to-end data paths. Each node is >> programmed with "cross-connect" information as the signaling messages >> are processed. The cross-connection information instructs the node >> how to forward data that it receives. >> >> End points of an LSP need to know when it is safe to start sending >> data so that it is not misdelivered, and so that safety issues >> specific to the data plane technology are satisfied. Likewise, all >> label switching routers along the path of the LSP need to know when >> to programme their data planes relative to sending control plane >> messages. >> >> This document clarifies and summarises the RSVP-TE protocol exchanges >> with relation to the programming of cross-connects along an LSP for >> both unidirectional and bidirectional LSPs. This document does not >> define any new procedures or protocol extensions, and defers >> completely to the documents that provide normative references. The >> clarifications set out in this document may also be used to help >> interpret LSP establishment performance figures for MPLS-TE and GMPLS >> devices. >> >> The purpose of the draft, therefore, was not to define any new procedures, >> but to attempt to clarify the existing protocol RFCs. The draft is >> Informational. >> >> The WG needs to decide (with the chairs judging the consensus and >> determining the action) how we should pursue this. >> >> I gave three options at the meeting: >> >> 1. Kill the work (no interest or not helpful) >> 2. Adopt as WG draft >> 3. Pursue as independent RFC >> >> I would be happy to hear people's comments on the draft and the options. >> >> No doubt the WG chairs will want to make any calls for consensus according >> to their priorities for the WG. >> >> Thanks, >> Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Attila.Takacs@ericsson.com Thu Apr 1 23:53:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195303A6905; Thu, 1 Apr 2010 23:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXRCHnZuukZq; Thu, 1 Apr 2010 23:53:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BD3443A68DD; Thu, 1 Apr 2010 23:53:12 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-b4-4bb594786926 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A3.C1.23740.87495BB4; Fri, 2 Apr 2010 08:53:44 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.93]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 2 Apr 2010 08:53:43 +0200 From: Attila Takacs To: Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Fri, 2 Apr 2010 08:53:43 +0200 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOA Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> In-Reply-To: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:53:14 -0000 Hi Matthew and George, Please find some comments/questions below. -In Section 5.1 you have: Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num?=20 Is it there to support associated unidirectional Tunnels/LSPs? If so it sho= uld be called out in the text.=20 Same applies to the globally unique case. -In Section 5.2 you simply append one LSP_Num to the above. This is a bit c= onfusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would be= needed too, wouldn't it? -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Num.= So this means that we may have two different tunnels identified with Src-N= ode_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, e= .g., the associated unidirectional case? This should be clarified. Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. -Section 7 has a note saying to be aligned with the OAM fwk, is this still = to be done? -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel lev= el and not at the LSP level? Do we need Tunnel MEG_IDs as defined in 7.1.2.1? -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. -Section 8 talks about open issues? When will these be addressed? Thanks, Attila=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Friday, March 12, 2010 12:33 AM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From diego.caviglia@ericsson.com Thu Apr 1 23:58:32 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64B43A692E; Thu, 1 Apr 2010 23:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=3.177, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm8kszJm9Wo6; Thu, 1 Apr 2010 23:58:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 027A43A68DD; Thu, 1 Apr 2010 23:58:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-2b-4bb595b6f965 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 96.D3.23532.6B595BB4; Fri, 2 Apr 2010 08:59:02 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 08:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 08:58:01 +0200 Message-ID: In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAAAvpBA= References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> From: "Diego Caviglia" To: "Attila Takacs" , "Loa Andersson" , , , , X-OriginalArrivalTime: 02 Apr 2010 06:58:02.0837 (UTC) FILETIME=[D68E7050:01CAD231] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:58:32 -0000 Hi, Some more comments from me more ore less on the same route as Attila. =B7 Section 1.1 o PSC is also used as Packet Switching Capable for OSPF-TE=20 =B7 Section 2 o Tunnel I think that here a reference to the actual identifier = of the quoted entity could help I mean a reference to Section 5 =B7 Section 4=20 o would be good to have a short explanation why numbered = interfaces are not in the scope of MPLS-TP=20 =B7 Section 5 o Even if section 2 points to 3209 than the Tunnel Identifier = chosen is different from what is defined in 3209, Extended Tunnel ID = field is missing while there are two different Tunnel Num that is not = clear how they works. I think here the same convention used in 3209 and = in GMPLS signaling would be good to avoid to have two or more Tunnel = identifiers for MPLS-TP networks using GMPLS.=20 o Why MPLS-TP tunnels must be associated to a LIH? Why MPLS-TP = tunnels need to be configured as FA? Does that imply that in case = OSPF-TE is used it must advertise MPLS-TP tunnels as FA each time a new = tunnel is created? =B7 Section 5.2 I think that sentence "The format of a Tunnel_ID = is:" should be "The format of a LSP_ID is:" same for the globally unique = case. =B7 Section 5.3 addresses some of my above concern about usage = of tunnel and lsp identifiers even if is not a 1:1 mapping given that = the Dst-Tunnel_Num is not mapped in GMPLS Tunnel ID =B7 Remaining of the docs is still WP =20 BR Diego line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Attila Takacs Sent: venerd=EC 2 aprile 2010 8.54 To: Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; = ccamp@ietf.org Subject: Re: [mpls] mpls wg last call on = draft-ietf-mpls-tp-identifiers-01 Hi Matthew and George, Please find some comments/questions below. -In Section 5.1 you have: Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num What is the reason of having a Dst-Tunnel_Num besides the = Src-Tunnel_Num?=20 Is it there to support associated unidirectional Tunnels/LSPs? If so it = should be called out in the text.=20 Same applies to the globally unique case. -In Section 5.2 you simply append one LSP_Num to the above. This is a = bit confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums = would be needed too, wouldn't it? -In Section 5.3 Mapping to GMPLS signaling does not use the = Dst-Tunnel_Num. So this means that we may have two different tunnels = identified with = Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this = intentional, e.g., the associated unidirectional case? This should be = clarified. Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. -Section 7 has a note saying to be aligned with the OAM fwk, is this = still to be done? -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel = level and not at the LSP level? Do we need Tunnel MEG_IDs as defined in 7.1.2.1? -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. -Section 8 talks about open issues? When will these be addressed? Thanks, Attila=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Friday, March 12, 2010 12:33 AM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Fri Apr 2 01:19:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928DF3A68B7; Fri, 2 Apr 2010 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-sJgX0PSAsv; Fri, 2 Apr 2010 01:19:16 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 6D9F63A677D; Fri, 2 Apr 2010 01:19:16 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (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 8F83ED404F; Fri, 2 Apr 2010 10:19:47 +0200 (CEST) Message-ID: <4BB5A8A2.508@pi.nu> Date: Fri, 02 Apr 2010 10:19:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , MPLS-TP ad hoc team , mpls@ietf.org, pwe3@ietf.org, CCAMP References: <4BAD5B78.5000808@pi.nu> In-Reply-To: <4BAD5B78.5000808@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] mpls wg last call on draft-ietf-mpls-tp-oam-framework has ended X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:19:18 -0000 All, the mpls wg last call on draft-ietf-mpls-tp-oam-framework has ended. Could the authors please address the comments and re-publish the document. /Loa On 2010-03-27 02:12, Loa Andersson wrote: > Working Group(s), Ad Hoc Team > > Offline the mpls-tp working group chairs, ADs and for part of the > time the ITU-T SG15 Rapporteurs attending the meeting in Anaheim > have spent time during the IETF week on the issue how to get a > high-quality standard out of the joint mpls-tp project. The > IETF leadership still see great value in keeping to the schedule > we've been working on for the last 9 months and is quite optimistic > about getting a high-quality work done on time. > > The working group chairs have agreed to extend the working group > last call schedule. > > We have made the following extensions/changes for the mpls-tp > project drafts that is currently in (or soon will be) in mpls > wg last call: > > > OAM Acronyms draft-ietf-opsawg-mpls-tp-oam-def > The OPSAWG wg last call will start on March 29 and end on April 18 > > > MPLS-TP Framework draft-ietf-mpls-tp-framework > The MPLS wg last call will start on April 5 and end on April 18 > > > MPLS-TP OAM Framework draft-ietf-mpls-tp-oam-framework > The ongoing MPLS wg last call will end on April 1 > > MPLS-TP Survivability Framework draft-ietf-mpls-tp-survive-fwk > The ongoing MPLS working group last call will end on April 11 > > > MPLS-TP Data plane draft-ietf-mpls-tp-data-plane > The ongoing MPLS working group last call will end on April 11 > > > ACH-TLV structure draft-ietf-mpls-tp-ach-tlv > The ongoing MPLS wg last call will end on April 12 > > > MPLS-TP Identifiers draft-ietf-mpls-tp-identifiers-00 > The ongoing MPLS wg last call will end on April 11 > > The latest version of a excel schedule that has been discussed > is included in this mail. I'd lake to poll for working group(s) > for comments on the schedule. As usual send these comments to > the mpls-tp mailing list only. > > /Loa > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- 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 Italo.Busi@alcatel-lucent.com Fri Apr 2 01:29:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06E03A69A9; Fri, 2 Apr 2010 01:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsBQXMMIpXOt; Fri, 2 Apr 2010 01:29:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6CE663A6803; Fri, 2 Apr 2010 01:29:11 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o328TFTT015479; Fri, 2 Apr 2010 10:29:32 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 10:29:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Apr 2010 10:32:56 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B1A08@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls-tp] [mpls]Term"PSC" indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrL9dLsI+DY3otSR3yV+LTQo2ejFABORLkg References: <8bf39341003231036w3ceaac70l18ee403c034da761@mail.gmail.com><8bf39341003240120r554b72j3f6b924475a11d3c@mail.gmail.com><8bf39341003240227i7fe1e00en9edbe2269b3953cf@mail.gmail.com><4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com><4BAA4873.3020706@chello.nl> From: "BUSI ITALO" To: "Adrian Farrel" , , "Cecil Byles" X-OriginalArrivalTime: 02 Apr 2010 08:29:27.0968 (UTC) FILETIME=[9BF30200:01CAD23E] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: mpls@ietf.org, CCAMP@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC" indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 08:29:17 -0000 Adrian, I think that this thread discussion is actually proving that the idea to = re-define a new term for what everybody in the world known as APS was = not a good idea. We therefore better come back and adopt the widely known concept rather = than inventing a new term and confuse the whole industry. Regarding your references, I think it is worth clarifying that: - APS is a generic term for the coordination protocol and does not imply = any specific protocol implementation; - Ethernet APS is a specific protocol specification of APS in Ethernet = networks and it is defined in G.8031; - SONET/SDH APS is a specific protocol specification of APS in SONET/SDH = networks and it is defined in G.841; - OTN APS is a specific protocol specification of APS in OTN networks = and it is defined in G.873.1 What IETF actually should define the specific realization of APS in = MPLS-TP networks. I do not see any value in calling PSC such a specific realization while = I can see a huge value in calling it as "MPLS-TP APS". Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Adrian Farrel > Sent: gioved=EC 25 marzo 2010 1.33 > To: hhelvoort@chello.nl; Cecil Byles > Cc: mpls@ietf.org; CCAMP@ietf.org; mpls-tp@ietf.org > Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC"=20 > indraft-ietf-mpls-tp-linear-protection-01 >=20 > Huub, >=20 > You will note that the comment in the liaison you reference said: >=20 > "The acronyms PSC and APS are used, in ITU-T APS is a generic=20 > term used in different methodologies and does not provide a solution." >=20 > This was neither a question nor a request for any change. And=20 > it is not really clear that it is a "concern". >=20 > APS is an abstract protocol (G.808.1) with specific=20 > characteristics and behaviors. >=20 > The Survivability Framework deliberately does not prejudge=20 > the abstract protocol or solution protocol that is required.=20 > Instead, it picked another acronym to avoid any assumptions.=20 > This frees the people working in the solution space to choose=20 > the necessary abstract model for the problems they need to=20 > solve, and to develop a protocol realisation that meets the model.=20 > This neither precludes nor forces the use of APS. >=20 > If you like, PSC is simply a generalisation that allows=20 > freedom of interpretation. Viz. >=20 > In some protection switching schemes (such as bidirectional > protection switching), it is necessary to coordinate the protection > state between the edges of the recovery domain. An MPLS-TP > Protection State Coordination (PSC) protocol may be used as an in- > band (i.e., data plane-based) control protocol to align=20 > both ends of > the protected domain. Control plane-based mechanism can=20 > also be used > to coordinate the protection states between the edges of the > protection domain. >=20 > In the view of the authors, the term "APS" has become=20 > synonymous with specific protocol realisations. For example,=20 > in the working copy of G.8131 I have infront of me, section=20 > 10 describes the "APS Protocol" setting out byte formats and=20 > defining messages to go on the wire. While we can interpret=20 > "APS Protocol" as the technology-specific realisation of=20 > "APS", there are sufficient overtones that if the=20 > Survivability Framework used the term "APS"=20 > it might be construed as support for a specific protocol=20 > realisation. Y.1731 defines APS PDUs for Ethernet which gives=20 > us another competing interpretation of the term. (It is=20 > notable that the term "APS Protocol" is used in G.870 to mean=20 > the abstract protocol, which is subtly different from its use=20 > in G.8131 and Y.1731.) >=20 > Surely the working group would prefer to derive the correct=20 > protocol solution without being constrained except at a=20 > functional level? >=20 > Adrian >=20 >=20 > ----- Original Message ----- > From: "Huub van Helvoort" > To: "Cecil Byles" > Cc: ; ; > Sent: Wednesday, March 24, 2010 5:14 PM > Subject: Re: [CCAMP] [mpls-tp] [mpls] Term"PSC"=20 > indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Hello Cecil, >=20 > You wrote: >=20 > > Can I therefore also asked how PSC "Protection State=20 > Coordination" in the=20 > > MPLS-TP parlance align with ITU-T 808.1 recommendation that=20 > "defines the=20 > > generic functional models, characteristics and processes=20 > associated with=20 > > various linear protection schemes for connection-oriented=20 > layer networks;=20 > > e.g., Optical Transport Networks (OTN), Synchronous Digital=20 > Hierarchy=20 > > (SDH) networks and Asynchronous Transfer Mode (ATM)=20 > networks" and the=20 > > sections covering Terms and Definitions as well as=20 > Abbreviations. IMO=20 > > all transport engineers and the general telecom community=20 > understand that=20 > > 1+1 or 1:1 are either SNCP or APS. Hence why introduce a=20 > new TLA (three=20 > > letter abbreviation) cover the same function and feature=20 > for MPLS-TP. I=20 > > can only agree that this will only cause confusion. >=20 > I agree with you. >=20 > In addition to that: > The ITU-T experts that reviewed the survivability draft had the same > concerns, and expressed that in their reply liaison for the review of > this draft: https://datatracker.ietf.org/liaison/618/ that was > sent in november last year. > This concern has not been addressed yet. >=20 > Regards, Huub. >=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 > Always remember that you are unique...just like everyone else... > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From benjamin.niven-jenkins@bt.com Fri Apr 2 04:40:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB923A677E; Fri, 2 Apr 2010 04:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QepXBhwLBJSx; Fri, 2 Apr 2010 04:40:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 6C39B3A6900; Fri, 2 Apr 2010 04:38:59 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 12:39:15 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 2 Apr 2010 12:39:32 +0100 From: To: , Date: Fri, 2 Apr 2010 12:39:28 +0100 Thread-Topic: [CCAMP] [mpls] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrL8UXTy/5QKB/HSvmNL816886NAAABtBiAAZhELCQ= Message-ID: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org, CCAMP@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:40:40 -0000 LOL, if only I had got around to reading this e-mail yesterday :-) Ben On 25/03/2010 08:52, "Alexander Vainshtein" wrote: > Adrian, > Lots of thanks for pointing to 5513, I've missed its publication. > IMHO and FWIW (which are not covered by 5513) it is extremely relevant fo= r the > MPLS-TP project. > Do you consider 5513bis to cover MPLS-TP? >=20 > Regards, > Sasha >=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Thursday, March 25, 2010 9:56 AM > To: Alexander Vainshtein; Vivien Sterling > Cc: mpls@ietf.org; CCAMP@ietf.org; mpls-tp@ietf.org > Subject: Re: [CCAMP] [mpls] Term "PSC" > indraft-ietf-mpls-tp-linear-protection-01 >=20 > For issues related to clashes of acronyms please see RFC 5513. >=20 >=20 > ----- Original Message ----- > From: "Alexander Vainshtein" > To: "Vivien Sterling" > Cc: ; ; > Sent: Wednesday, March 24, 2010 8:30 AM > Subject: Re: [CCAMP] [mpls] Term "PSC" > indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Vivien and all, > AFAIK, PSC stands for "Protection State Coordination" in the MPLS-TP > parlance (see MPLS-TP Survivability > Framework) > - a new fancy name for what has been known as "APS Protocol" in SONET/SDH= . >=20 > As you've noted, it has a completely different meaning in GMPLS. >=20 > Since GMPLS is going to be used with MPLS-TP, double usage of this acrony= m > looks highly problematic. >=20 > Regards, > Sasha >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Vivien Sterling > Sent: Wednesday, March 24, 2010 10:21 AM > To: CCAMP@ietf.org; mpls@ietf.org; mpls-tp@ietf.org > Subject: [mpls] Term "PSC" in draft-ietf-mpls-tp-linear-protection-01 >=20 > Dear Experts, >=20 > I'm surprised to find the term "PSC" used in this draft. I suppose the > authors are talking about data plane not control plane, right? Isn't PSC = in > GMPLS elaborated as "Packet Switch Capable" ? It's confusing :-( >=20 > -- > Cheers, > Vivien >=20 >=20 >=20 > -------------------------------------------------------------------------= ----- > -- >=20 >=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From benjamin.niven-jenkins@bt.com Fri Apr 2 04:46:02 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E897D3A683B; Fri, 2 Apr 2010 04:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRcPBOksAQNx; Fri, 2 Apr 2010 04:46:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id C8D283A67E7; Fri, 2 Apr 2010 04:46:01 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 12:46:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 2 Apr 2010 12:46:34 +0100 From: To: , Date: Fri, 2 Apr 2010 12:46:29 +0100 Thread-Topic: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrMKNK8FWUFkFW/SVqIiiY2J/JcfQGMU8b4 Message-ID: In-Reply-To: <67ec4be61003250738v272809bcwd339d5771566f390@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cecil.Byles@interoute.com, mpls@ietf.org, CCAMP@ietf.org, Alexander.Vainshtein@ecitele.com, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 11:46:03 -0000 Zhi, Thanks, I understand you perspective. However I suspect other operators may target their existing data network operations staff to maintain and operate an MPLS-TP network! The functionality needs to be as aligned to existing practices (MPLS and Transport) as possible. Re-learning/Re-definition of existing operations processes should be minimised but given that MPLS-TP is bridging a gap between data and transport networks some relearning on both sides is inevitable. HTH Ben On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: > Hi, >=20 > I like to give my perspective. As a small network company (but one of the > largest transit agencies), we have a small operating staff split into two > groups: one that handles traditional data network (Ethernet, IP), and one= that > handles transport network (SONET, WDM). >=20 > We are targeting the transport network operating staff to maintain and op= erate > the MPLS-TP network. As such, anything that will help to reduce the learn= ing > curve (less training), simplify operating, and make the MOP as consistent= as > possible between SONET and MPLS-TP would be hugely beneficial. >=20 > Obviously there will be some differences since MPLS-TP is a packet-based > transport network, but the standards groups (I don't really care for poli= tics > of IETF and ITU) should strive to make these differences easy to learn. >=20 > Thanks > Zhi >=20 >=20 > On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar > > wrote: >=20 > In message=20 > <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> > "Cecil Byles" writes: >>=20 >>=20 >> Hi, >> Can I therefore also asked how PSC "Protection State Coordination" in >> the MPLS-TP parlance align with ITU-T 808.1 recommendation that "defines >> the generic functional models, characteristics and processes associated >> with various linear protection schemes for connection-oriented layer >> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital >> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" >> and the sections covering Terms and Definitions as well as >> Abbreviations. IMO all transport engineers and the general telecom >> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why >> introduce a new TLA (three letter abbreviation) cover the same function >> and feature for MPLS-TP. I can only agree that this will only cause >> confusion. >>=20 >> Cecil Byles >=20 >=20 > Though this is joint work, this is the IETF not the ITU. We should > use ITU terms where appropriate but where there is a conflict such as > this we need to pick another term and another TLA. If the ITU wants > to update 808.1 at some later date that is up to the ITU. In the mean > time we can use another term and point out the mapping. >=20 > Curtis > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From zhangguoying2010@gmail.com Fri Apr 2 06:31:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3523A6915 for ; Fri, 2 Apr 2010 06:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 tagged_above=-999 required=5 tests=[AWL=1.362, BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz2RaE+FkDcx for ; Fri, 2 Apr 2010 06:31:10 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 792AC3A69D5 for ; Fri, 2 Apr 2010 06:31:10 -0700 (PDT) Received: by gwj15 with SMTP id 15so1377622gwj.31 for ; Fri, 02 Apr 2010 06:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=V2UtBQ+2urWPaRnx7jZWnjRPMSE1KFJ988FW4hpAIkw=; b=eABnsxOFFzkAwTXsPs+7QAHdzbA1d+0OgrvCEN+mT3M04s+KYXCCfcpPUbohqQ5axM yigDoxLI/PUqXgh5zpVfchAZzqI+nd7Qkb7XPyvuxAD14YxBVs8U3Ho040dAzWK6eoIP 9j+2kEvh/Q1/iS+DLh6m0rOgdL6ykeAvwpoMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=T0dOj2xEIfB2+x0IUSdiroxIvbLzSYqvtaOohc7y/PT/VruNfdmbOnKpkNKmJKY6O4 1DOm7n80Xo1pA91Bg7Cvq/zTs9VslJv8gFOKLUfhfNe0bdUoIA1mKw3WieOE7rUgyLTi /AKiHO/9HaaLqdWzntWgbZikmVUWXtb7a7V48= Received: by 10.101.134.13 with SMTP id l13mr5700266ann.160.1270215100539; Fri, 02 Apr 2010 06:31:40 -0700 (PDT) Received: from gyzhang ([123.118.100.188]) by mx.google.com with ESMTPS id c21sm9002894ibr.4.2010.04.02.06.31.36 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 06:31:40 -0700 (PDT) Date: Fri, 2 Apr 2010 21:31:46 -0800 From: "zhangguoying2010" To: "ccamp" Message-ID: <201004022131418439969@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon710647410702_=====" Subject: [CCAMP] test X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:31:11 -0000 This is a multi-part message in MIME format. --=====003_Dragon710647410702_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit test . please ignore. 2010-04-02 zhangguoying2010 --=====003_Dragon710647410702_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
test . please ignore.
 
2010-04-02
zhangguoying2010
--=====003_Dragon710647410702_=====-- From benjamin.niven-jenkins@bt.com Fri Apr 2 08:30:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 675D73A6821; Fri, 2 Apr 2010 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=1.405, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alXRGzr1bARB; Fri, 2 Apr 2010 08:30:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id E54FB3A67DA; Fri, 2 Apr 2010 08:30:24 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 2 Apr 2010 16:30:41 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.222]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 2 Apr 2010 16:30:57 +0100 From: To: , , Date: Fri, 2 Apr 2010 16:30:52 +0100 Thread-Topic: [mpls] [CCAMP] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 Thread-Index: AcrMKNK8FWUFkFW/SVqIiiY2J/JcfQGMU8b4AAVl4mwAAnBDYw== Message-ID: In-Reply-To: <436B49B8E459C54C8B47A7826292AFB4027A09@NYCTEXVS06.transit.nyct.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Cecil.Byles@interoute.com, mpls@ietf.org, CCAMP@ietf.org, Alexander.Vainshtein@ecitele.com, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:30:26 -0000 Zhi, I suspect your requirement is to keep the operational procedures (MOP) for MPLS-TP as closely aligned to those of your existing transport network as possible. In other words if scenario A occurs, operations need to follow steps B, C and D etc. where the functions of A, B, C and D are as similar a= s possible for MPLS-TP and your existing transport network. Whether the protection switching mechanism is called APS or FOO is a very minor point in the overall operations procedure, otherwise I suspect your operations personnel are going to really struggle with MPLS-TP with its introduction of other new acronyms Vs transport networks like LSP, PW, BFD etc ;-) Ben On 02/04/2010 15:26, "Lin, Zhi-Wei" wrote: > Hi Ben, >=20 > Yes, definitely there are other operators with different operational > considerations. I was offering my perspective and what my company plans t= o do. >=20 > However, in terms of the acronyms, even if in your company you plan to ha= ve > your data group handle MPLS-TP, whether the term is "MPLS-TP APS" or "PSC= ", > from their perspective it will be a new term and therefore no difference = which > it should be. >=20 > However, for other operators (such as us) who plans to have the transport > personnel handle MPLS-TP, then "MPLS-TP APS" would make more sense. Again= , > functionally, our transport staff will need to be trained on specific > procedures associated with MPLS-TP, but anything that keeps things "simil= ar" > is better than nothing. >=20 > As such, MPLS-TP APS would be a better term that would make more operator= s' > life easier, yes? >=20 > Thanks > Zhi >=20 >=20 > ________________________________ > From: mpls-bounces@ietf.org on behalf of benjamin.niven-jenkins@bt.com > Sent: Fri 4/2/2010 7:46 AM > To: zhiwlin@gmail.com; curtis@occnc.com > Cc: Cecil.Byles@interoute.com; mpls@ietf.org; CCAMP@ietf.org; > Alexander.Vainshtein@ecitele.com; mpls-tp@ietf.org > Subject: Re: [mpls] [CCAMP] [mpls-tp] Term > "PSC"indraft-ietf-mpls-tp-linear-protection-01 >=20 >=20 > Zhi, >=20 > Thanks, I understand you perspective. >=20 > However I suspect other operators may target their existing data network > operations staff to maintain and operate an MPLS-TP network! >=20 > The functionality needs to be as aligned to existing practices (MPLS and > Transport) as possible. Re-learning/Re-definition of existing operations > processes should be minimised but given that MPLS-TP is bridging a gap > between data and transport networks some relearning on both sides is > inevitable. >=20 > HTH > Ben >=20 >=20 >=20 > On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: >=20 >> Hi, >>=20 >> I like to give my perspective. As a small network company (but one of th= e >> largest transit agencies), we have a small operating staff split into tw= o >> groups: one that handles traditional data network (Ethernet, IP), and on= e >> that >> handles transport network (SONET, WDM). >>=20 >> We are targeting the transport network operating staff to maintain and >> operate >> the MPLS-TP network. As such, anything that will help to reduce the lear= ning >> curve (less training), simplify operating, and make the MOP as consisten= t as >> possible between SONET and MPLS-TP would be hugely beneficial. >>=20 >> Obviously there will be some differences since MPLS-TP is a packet-based >> transport network, but the standards groups (I don't really care for pol= itics >> of IETF and ITU) should strive to make these differences easy to learn. >>=20 >> Thanks >> Zhi >>=20 >>=20 >> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar >> > wrote: >>=20 >> In message >>=20 <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com> 0 >> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> >> "Cecil Byles" writes: >>>=20 >>>=20 >>> Hi, >>> Can I therefore also asked how PSC "Protection State Coordination" in >>> the MPLS-TP parlance align with ITU-T 808.1 recommendation that "define= s >>> the generic functional models, characteristics and processes associated >>> with various linear protection schemes for connection-oriented layer >>> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital >>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" >>> and the sections covering Terms and Definitions as well as >>> Abbreviations. IMO all transport engineers and the general telecom >>> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why >>> introduce a new TLA (three letter abbreviation) cover the same function >>> and feature for MPLS-TP. I can only agree that this will only cause >>> confusion. >>>=20 >>> Cecil Byles >>=20 >>=20 >> Though this is joint work, this is the IETF not the ITU. We should >> use ITU terms where appropriate but where there is a conflict such as >> this we need to pick another term and another TLA. If the ITU wants >> to update 808.1 at some later date that is up to the ITU. In the mean >> time we can use another term and point out the mapping. >>=20 >> Curtis >> _______________________________________________ >> 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 From sriganesh.kini@ericsson.com Fri Apr 2 06:11:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606713A69BC; Fri, 2 Apr 2010 06:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrZfnwegXu0J; Fri, 2 Apr 2010 06:11:09 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6E9F33A6845; Fri, 2 Apr 2010 06:11:09 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o32DFU2M017872; Fri, 2 Apr 2010 08:15:30 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 2 Apr 2010 09:11:41 -0400 From: Sriganesh Kini To: Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Fri, 2 Apr 2010 09:11:41 -0400 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBc0WnZb3W+AQWTpuJTuXgXymZDgQ8Q2Qw Message-ID: <5A5E55DF96F73844AF7DFB0F48721F0F52E4835FCC@EUSAACMS0703.eamcs.ericsson.se> References: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> In-Reply-To: <97ea8a23065211ee6df8f08ea5e4ba67.squirrel@pi.nu> 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 X-Mailman-Approved-At: Fri, 02 Apr 2010 13:31:09 -0700 Subject: Re: [CCAMP] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:11:10 -0000 Hi, 1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the S= ource Node_ID and a locally assigned tunnel number." a) Should "Source" be replaced by the "endpoint's" since later the "Dst-= Node_ID" is used? b) Useful to clarify the scope of "uniquely identified" before this stat= ement.=20 C) Should there be a similar identifier at each intermediate node beside= s the endpoints? 2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that= . Thanks - Sri =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Thursday, March 11, 2010 3:33 PM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we=20 > haven't been able to come to conclusion. Once we reach=20 > agreement the document will be updated. Comments in this area=20 > are welcome during the working group last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > = From yaakov_s@rad.com Fri Apr 2 07:11:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A163D3A679C; Fri, 2 Apr 2010 07:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so-bVC8m8RCP; Fri, 2 Apr 2010 07:11:12 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id A1C4C3A67AE; Fri, 2 Apr 2010 07:11:08 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 02 Apr 2010 17:11:22 +0300 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Fri, 2 Apr 2010 17:11:22 +0300 From: Yaakov Stein To: Fatai Zhang , Greg Mirsky , Diego Caviglia , Lou Berger , "Deborah A, ALABS Brungard" Date: Fri, 2 Apr 2010 17:11:14 +0300 Thread-Topic: Time synchronization discussion //Re: [CCAMP] GMPLS Operation Logger pool for interest Thread-Index: AcrSCuy+nUU389d2QIKe/kDVIV2jdAAYz3SQ Message-ID: <48E7911F78327A449A9FB956376672864725ED17@exrad4.ad.rad.co.il> References: <039101cad20a$e6e4ca20$674c460a@china.huawei.com> In-Reply-To: <039101cad20a$e6e4ca20$674c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_"; type="multipart/alternative" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Apr 2010 13:31:09 -0700 Cc: "ccamp@ietf.org" , "tictoc@ietf.org" Subject: Re: [CCAMP] Time synchronization discussion //Re: GMPLS Operation Logger pool for interest X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:11:21 -0000 --_005_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_ Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_" --_000_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Although timeliness is indeed important for logging, the accuracy of the ti= mestamp is also important. The definition of an MPLS-specific encapsulation for time flows is indeed o= ne of the high-priority items on TICTOC's list. Y(J)S From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, April 02, 2010 05:19 To: Greg Mirsky; Diego Caviglia; Yaakov Stein; Lou Berger; Deborah A, ALABS= Brungard Cc: ccamp@ietf.org; tictoc@ietf.org Subject: Time synchronization discussion //Re: [CCAMP] GMPLS Operation Logg= er pool for interest Hi Greg, I follow up your discussion, although Diego meant "timely synchronization" = not "Time synchronization", :-)~~~ As for timing or clock, I think it is really very interesting to investigat= e what GMPLS can do for timing or clock. I attended the TICTOC session during Anaheim meeting, some people are inter= ested in "Path Finding". >From my point of view, if we have Path Finding, it is very convenient to f= ind the optimized path to minimize delay, to avoid timing loops, and the mo= st important thing is that it can resist multiple failures like GMPLS resto= ration. In addition, Path Finding is a kind of automatic mechnism (i.e., sm= art enough), so it can reduce manual configurations and make it easy to des= ign timing/clock network. Therefore, I am happy to see some joint work between CCAMP and TICTOC on th= is topic. I added co-chairs of CCAMP and CC to TICTOC WG. Best Regards Fatai ----- Original Message ----- From: Greg Mirsky To: Diego Caviglia ; yaakov_s@rad.com Cc: ccamp@ietf.org Sent: Friday, April 02, 2010 9:16 AM Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest Dear Diego, I'd like to refer you to Timing over IP Connection and Transfer of Clock (T= ICTOC) WG. I've tried to fo= llow work there and recall that group worked on summarizing requirements fo= r time synchronization from various industries and applications but I canno= t point you to the right document in archive. At the last meeting we discussed whether MPLS-TP might have specific requir= ements to timer synchronization (as I recall it). But I don't remember anyb= ody bringing specific GMPLS requirements yet. It might be interesting to lo= ok. I've added Yaakov Stein, group's chair, to the discussion. Regards, Greg On Thu, Apr 1, 2010 at 4:45 AM, Diego Caviglia > wrote: Hi CCAMPers I'd like to hear the feeling of the WG about starting a work on= GMPLS logging. The very basic idea is to have something to synchronize all the time on the= NEs and to have a compressed and optimized client server protocol to uploa= d GMPLS information to a centralized server. Time synchronization is essen= tial to rebuild the sequence of events and actions that happens to a certai= n LSP. GMPLS is becoming too complex and too business critical to relay on SNMCP f= or logging. On the other hand is impossible to store on the NE itself all the GMPLS log= ging. BR Diego DIEGO CAVIGLIA Strategic Product Manager Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com [cid:image002.gif@01CAD287.7FEB5EB0] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Although timeliness is indeed important for logging, the accuracy of the timestamp is also important.

 

The definition of an MPLS-specific encapsulation for time fl= ows is indeed one of the high-priority items on TICTOC's list.

 

Y(J)S

 

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, April 02, 2010 05:19
To: Greg Mirsky; Diego Caviglia; Yaakov Stein; Lou Berger; Deborah A= , ALABS Brungard
Cc: ccamp@ietf.org; tictoc@ietf.org
Subject: Time synchronization discussion //Re: [CCAMP] GMPLS Operati= on Logger pool for interest

 

Hi Gr= eg,

 

I fol= low up your discussion, although Diego meant "timely synchronization" no= t "Time synchronization", :-)~~~

 

As fo= r timing or clock, I think it is really very interesting to investigate what GMPLS c= an do for timing or clock.

 

I att= ended the TICTOC session during Anaheim meeting, some people are interested = in "Path Finding".

 

From = my point of view,  if we have Path Finding, it is very convenient to find the optimized path to minimize delay, to avoid timing loops, and the most impor= tant thing is that it can resist multiple failures like GMPLS restoration. In addition, Path Finding is a kind of automatic mechnism (i.e., smart enough)= , so it can reduce manual configurations and make it easy to design timing/clock network.

 

There= fore, I am happy to see some joint work between CCAMP and TICTOC on this topic.

 

I add= ed co-chairs of CCAMP and CC to TICTOC WG.


Best Regards
 
Fatai
 

----- Original Message -----

From: Greg Mirsky

Sent: Friday, April 02, 2= 010 9:16 AM

Subject: Re: [CCAMP] GMPLS Operation Logger pool for interest

 

Dear Diego,
I'd like to refer you to Timing over IP Connection and Transfer of Clock (<= a href=3D"http://datatracker.ietf.org/wg/tictoc/charter/">TICTOC) WG. I'v= e tried to follow work there and recall that group worked on summarizing requirements for time synchronization from various industries and applicati= ons but I cannot point you to the right document in archive.
At the last meeting we discussed whether MPLS-TP might have specific requirements to timer synchronization (as I recall it). But I don't remembe= r anybody bringing specific GMPLS requirements yet. It might be interesting t= o look.
I've added Yaakov Stein, group's chair, to the discussion.

Regards,
Greg

On Thu, Apr 1, 2010 at 4:45 AM, Diego Caviglia <diego.caviglia@ericsson.com= > wrote:

Hi CCAMPers

   &nbs= p;        I’d like to hear the feeling of the WG about starting a work on GMPLS= logging.

 

The very basic idea is= to have something to synchronize all the time on the NEs and to have a compres= sed and optimized client server protocol to upload GMPLS information to a centr= alized server.  Time synchronization is essential to rebuild the sequence of events and actions that happens to a certain LSP.

 

GMPLS is becoming too complex and too business critical to relay on SNMCP for logging.

 

On the other hand is i= mpossible to store on the NE itself all the GMPLS logging.

 

BR


Diego

 

 

3Dline

D= IEGO CAVIGLIA
Strategic Product Manager <= o:p>


Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
diego.cavi= glia@ericsson.com
www.ericsson.com =



3DEricsson

 


This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com= /email_disclaimer <= /span>

 


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

 

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

--_000_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_-- --_005_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1417; creation-date="Fri, 02 Apr 2010 17:11:19 GMT"; modification-date="Fri, 02 Apr 2010 17:11:19 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh/wADAPcAABUpeBUoeBQse1WrIWCvHQCDrwCOUhQtewCLcRMvfACMZQCEoxiYOzqiLQCN XwCMZp0MXEYdbQCHkkAfbjyjLAhhnwdlojAicgCNWgCGlQCOVQRvqQRxqgCIhg9BiQZopFYaag6U P8YEU3C0FrYHVwtUln4SYgCGlxI1gHUUZACKeCmdNFsZaYgRYACQR8MFVIQRYRE3gqcKWpoNXACF nnIVZGsWZi0ichomdghenQN1rQhgngCHjg5HjQ9AiHa2ExE6hDkgcACIiUwcbDShL7kHVg9Dijwf b3gUY4y9CgpXmF8ZaACOWGuyGFCqI2OwG24WZZS/BkqoJgCJewCDrE2pJQtTlQCHiyyeMyEldVut HwCMaBA8hRA/hxyZOdUBUMwDUqoKWQCFmwF8sgF+swCNYaQLWgCEqgCCtgCEpwCFnACJfwCKdgCL bWgXZgCPTCojcwCFoBQqeSQkdAldnAJ6sAN0rFkaaQxNkQlbmwCHjQ1Kjw5GjACLaz+kKgCQSRE5 g7MIVwVtp4S6DZrBBAdjoKAMWzGgMM8OWl2uHgGQRQORRHO1FHsTYxaXPJEPXo++CYe7DACPSkkd bU8ca7AJWGixGQN3rgVrphcndwZqpWawGgdkoWIYaAZno5K/CC+fMY0PXwCHkAxQkwCKegCIhLwG VQCPUCGbNzeiLgiTQgCNXCScNhCVPhOWPX64EJzCA2UXZ0SmKBA9hlKqIgxOkh6aONICUVIba88C USecNRMwfq0JWACCs3m3EgCGmQCJgACIgpfABRI2gQCMY78GVVisIACEqIG5DwCCtQ5EiwCEpYES YQF/tACBtQCJfZQOXQCKdEinJ4m8CwCLbwpWl0KlKQCOVwCPTjMhcYoQX0MebgtRlB0ldZcOXQVu qCckdACFogCGkwCDsQJ7sQCKcgWSQwRyqw1MkG6zFzcgcAlamgCDrgCIh3y4EQ1JjhMyfhIzfwJ4 rwCLagCNXgCOUwpYmQuUQLPPN+Drqp/DAtXkjK/NLLHOK/Ccu////yH5BAAAAAAALAAAAAD/AAMA AAj/AP/9y8cPFiFhUT5BSjIt0iBkr9z5+sFoRLomljY9IZBIi7EBtJxUkSJNljU/FBqkInIIFJYV ulihsuWFgSNXrULcU2VukSIXfyS9wXbKQD0N15hgWEXPQRliCh5smdenDTUE5aKxUUFqyrM1wIKV 6tBOyBU9PERJEJfhxC8xamjECbdgWZpjZ6iwKzCuVzI0zpqRGUOujrxLOuyc47DhmyBMmj54ssCp UIUdOejkWWdPSbUSVriNqoUH3Z53PfgoM+LBR5dZXIAAijEMRTx4uxIcECAHQIBMOLplmQMOzo0L 2dQFOTJhW4RJQyjhAnGHxZJOsdzYgFIjBZJGJpjB/2ihLdQjaN5mQDBkRkYYXpUCkShiqtgLESLA 5Lp1y59Agf3oYxBCCjHkEEQSUWQRRhpx5BFIIpFkEkoqseQSTDLRZBNOOvHkE1BCEWUUUkox5RRU UlFlFVZaceUVWGKRZRZaarHlFlxy0WUXXnrx5RdgghFmGGKKMeYYZJJRZhlmmnHmGWiikWYaaqqx 5hpsstFmG2668eYbcMIRZxxyyjHnHHTSUWcddtpx5x144pFnHnrqsecefPLRZx9++t3yBSL//bMP PgMmtFBDD0U0UUUXZbRRRx+FNFJJJ6W0UksvxTRTTTfltFNPPwU1VFFHJbVUU09FNVVVV2W1VVdf hWY1VllnpbVWW2/FNVddd+W1V19/BTZYYYcltlhjj0U2WWWXZbZZZ5+FNlppp6W2WmuvxTZbbbfl tltvvwU3XHHHJbdcc89FN11112W3XXffhTdeeeelt15778U3X3335bffF/79ExAAOw== --_005_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=4024; creation-date="Fri, 02 Apr 2010 17:11:20 GMT"; modification-date="Fri, 02 Apr 2010 17:11:20 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPf/AOrs8ezu8ylMflZulPn5+zNSgbK8zVx0mYWWsSRFefDz9fn6/JWhuoKRrdjd 5T9Zht7j6XaGpQgoZqq3yU5kje7x9DdHewosaGF2mtbc5Y2dtr7G1ZyrwF1xl3GFpVNpknmKqPf4 +pqpv0JdiQ4ybAkqaPr8/UpdiWp+oe3w8wIbXtHY4Qwuam6CojhTgsPK2KKvw+Pm7PH09mZ4nC5O f3+MqszT3g0wazJNfuXo7ufr8HSJqBA1bsnQ3Bk6cpypv87U3pKhuf39/sDI11Rqkm1+oLbB0CFC d0ZciClKfQUiYqy2ySZKfBI3cKezxtXb5KWxxD1UgwcmZRk+dB1Cd8rR3FBnkAYkZBAybZimvOHl 67vE07nC0lpulY2btbS+zkBbiCE/dS1Dd5Cet/P1+Imas7rC0gYkYufq75aku2qAoUlgi2l8n9Ta 4wAUWQ80bcrS3XGCo0Vah8bO2ihIelpwlhc7cq+5yhY2b6i0x0hijHiIpg8wbAQgYQMeX8HK1yxK fGZ9nz1VhCxGeZmnvgkpZgARVxk8coSSrlFmj3+Oq2x9n2l7ng0wbDhVg2J4nAknZhIuagQhYg4v aixIexE3bxM0bgwuaQstaf///xA2b3mMqhI4cSlMfShMfRI4cCpMfipMfypNfxE4cHiMqniMqQor aPL09/L19/X2+f7+/v3+/q24yggoZRI4b+3w9BI5cBAzbYWYsklkjv7+/6+7zLjC0cTN2cXO2vP0 9/T2+Ojr8B89cwUjY8bO2aCuwsPN2fz9/VVrlEVgi1dii3uNqn+QrXuOqytMfRM7cu/x9XWHp1dw lxYzbDtYhj9SgoyctRg3caStwbC6zJelvA4oZQosZ2V5m8/W4O/y9hs/dWl3mh06csLJ12R1m8nR 3OPp7cLL2IWUsNDW4AwvaxA2bnqFpdrf54iXsuXp7rjB0Jilu6+7y/b3+f7//8bN2vL09khch2Jz mFJii1BijLvF1L3F0xM5ctvg6PT2+fX3+PX3+aGtwRE2bxE3cP///yH5BAEAAP8ALAAAAAD0AVEA AAj/AGVtIrVpYKlNBwsqRFgq4cCCDgsSlEhq4sKIpSwu3FgKwb+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPqpFKpX7+e/nxWAtrPn9FKQX0WNap0adGfS40mRZrUZ9CjS4n6o6Kzq9evYMOK HUu2rNmzMgUEHSoVKVWgcJNKlRtV6VV/bu9ihRr1qk8BaAMLHky4sOHDiLsK+NmWKd6jeJ1StevY adPLSTXR7fk0sk9RiUOLHk26tOnTJBcLtWw3a2Skmjh3nmrV89O+eiFn7RcKte/fwIMLH17SE9Kf mosOfbpcrlvKyo8/hnyccVS2eCcLBUy8u/fv4MPr/1RNtfJdq8d7Tq7MGe8nEqYkFGLhtHJRzXKZ 9uMuvr///wB+t1hV6q2mlCZQPQaUXk9xUgkLkpiCAzMD+HABdsrxxZhnPfUW4IcghijiYGr5g59V Sj0HVV7oNfcJJ29I0YcP3kBxziomDIHDBXPVJpR+UYE24pBEFmkkTCU29Zp+QDZFFGc3XMHCGgxg E0ImWGIJwyRv2PWWY2slBcqRZJZpppGe9IOgdD8qqZds/vBwgymF0KBIFcpkqWcmT4RBwnkoIkjX X2cWauih4HViYo9OHtVeZJzwcIkEphzxyBIp0LLnnrdEg0Vu2W0YmVEeImrqqaiGplp0PuYXJoxS 9P/CCxFZnLPprbqwUYKBTD4K2ZipBivssGN1wplWmElXiSskFHICOnMscOumAdhyjSlvgIlhVefx R+y34Ib7UpIYylafUVjEEoQO0+5pwhwNIEGCFDx8glV7zc3FlLfi9uvvv/+oNl1nfbHFgwQoqNIu lqvgw4AezfThxxUkoPhYbZEhaFmpAHfscbCrSqUcXrH51c8bphDSbjC7fHGNHX6oYEoBgRxwBCad LZfck0ry+/HPQJdpLMZGaZyiUjwUAs2tAXSjCCB+uHEFJSjcEQCWNrhwwdHVuTqZz0GHLTaIApu8 4YpJmfKAFlkuYMMYFJhiiBs+dPBDG5tOwOVtcLr/uRSwYwcuuH+dUKZeeY7BVQIYMGwhwgBhRC0F ldjAM22fN1QH55tXgT3456D7JoDRZtc2FFCu9HPBJJZIoIIkdIAwRDYLZ7IBHhX/eGyPInMc+u/A j5YkisxlWJsmnNwgxRVhHLBEAArXLgMGuzaZIJDHeR789tyftVhybkoXplEsTGLFGA7UnqUWXxBh Cg98CUrXWiXv1/39+Jullo9Oas4UCdEgRCrUl4kAbAEELpCCFE6Hsbw0pzq8yZ8EJ6gYNXGLb0AK SiFaoD4hVAEaSOCDCqQWi6uoJ1S884s/tEfBFrowJaIYla+OdhWUiaBdQogBIawQDUmooAQjMMYy /+iAibUc6zYHIpjvXsjEJpJEUbNxy3qy4483FKIMmxJCAOyBAh/ETAKAaMELCOCOVZzjAVsrHmua tEInuvGNICkbbMxlsZ5cwAUZyFIA3iGOAihBaoN4hBPSsalapAuCbTIiYyqxRDg6coICYBEKzQWk EriAA7VIQyJIMLdYdOEHT2hXBsLQiOvNBjJyaeQjV9m9Eo0KN1TkjCsqYQopkKMPUnvAGL6BitrV A3cGiuJUrgI4Vhqze2nCijLrortKxKIQSkhABLqRAgLuwn1qvI6oflKJYh7zm79zJclmc0qhkMMS dYABGqK3sBDEQBpgeJ8aG3OxqLAQnPgMWiSjg/+snD3lBj7IAwEzwb5FHOEKONOdZCh5LCHl86GB K9wymWSbfhxsGepTQD0QkUAlXIIT9jIZWxYEyzZC9KRhUxQqkWgyE73hAjdsFxDKsAZLnEEKb/jE KMplsZ4aTpUoDaq4CrdIfF2PgYVAwKZUEQMoDIAbJSjEJMrBiQSNrJ7T6RFQNHFPoXoVZMGsymqC siZM4AAOetxAERIggQvcgAf5cpPI1oOZkXnzq3gdlrFoo5nySFFB1qDDOmzhBRcUgmJvOddexDdM kREPqHmN7KHUUiCxTpE5nGDBFaSghBKIzDahUhGb9IWeutxVsqg1FGWNhhkCrakfnKiiP6rqwNf/ WFVf5kpPm6xy2tT6lkyeWAsNTYcirXBrfNjjHXS4uSLLdPW30CWbYvODMTVJZmTL3WYiM0RPvgTl udENr3+CqyJOgNReDjKvUWLbjxcJRb1tie1OpcKJnWJnFA6abWyDsl/hMlK8AB4SuSrxCVP04gpX 6IUE+iEBBPeiEDzwxwUkMQl7TbgPvWgELFjQiz5I4gawwIQk/KAEEsAiRn3owwViawol0Ksfh81p QwNMY+nCRhM8GAEG6tABDOiBE3rogJAfQA4SOGMGyCABGOPQAEbQoRAJiAMiikAHKQDCA4hgRAIw wYJENGAPNJAAD8CAAQrEggd6EMYU3jAZyNb4/83DiWRSGoEFA+TjFKdARTim0ANd5DkF/LgANUJA ij4oAgALWEAqoPEACKSCAKgowgm0oI8Q6KIIV2BFLhKtAzZAYgL7yIYVIoGLHAjCFAXqLZxXHRzj WIXO9ciECNjgAWZ84gkmqIE5FOAOGqjMA8MQwgIYgIQWDIADmXACJSjgiGlk4geUGIAYFJGJdCTC CwUEBCuwxIVI2CAbgtgVY8DL6nKLJk1uaQQfbJEJQsygBbPAQhtCsA1igCMHVFAZCmCQCRiooMG9 +EUmVrAHC/ShFpmoQgTE0AdgZEIRhsDEHDKhBiiYQBkhGMAGUhAFcX/X3CAPzj57Qg4ssDtL4f8g hw30pIY+cMAdHuBCJiKggmR8ghzO+AOWdNCBZ+ACSxA4wDcyQYTDbvsYTiCDBpTRgzkEQBCFyAu5 Q051wRSuErEpObtlMY8uuCAWbVgANcyQCQb4AdkoUBkrJKEECWgWEicwQCZu4YZq0EMdmciDETIh DkNMYuiBcMIq5CD3dqQjCoVoi0OrznhVVYXOW8h7DcTBhns4wARReAYqZKANEbhjGY5IBS1YIY9l YIAZDZDDttlRhz3EPRNBUEMwANABBmQiBgn4Qibi8QATZEIH4b7N4htP/MLsMyiNiMUEUvCKALzi D1QIhw4o0Is/VIAZsnjFDvwwA3zkggzZSEP/MRRwimyMwwVBkAEqFGADQUhhHa+QwSnwIYxPp2AW fZhABTLgAlNsaPjFF4BoQVlJwQM0MAIP8AAjUABNUAAPMAU3gAxgwAQJMAxH8ExTYAUz8AEJcAQa SATaYApJQAQzYAWHwAI8UAKO8AhdQAW7QgMPSALaMAKOYAfwYxVTJ4A6eBOjAxf9gAmtUAiFIAGY UAkXUAhvwAmYUAg3cAOtUDGcMC8uRgIkkGBSYGJR4mI3sFOaYGBXcAN4cQlI6A8k0ArvA0EAuINq +BUSNRcvElKj0A/49V50NVsvghf1FVKzNQrzVR6f8BYOwhj24kCqtoaGaBPBNTLLcRtLsiA9/6Ex YNIaKsJcTNE1XuIjaXiImkgTiWhVi1SJ2lRb3LUedGQ6F5Me2MEZbraJrMgSA+I3tAEorsEkRKMv 7OFPJzIVPZGDrdiLIrEYiHRKYUI8u+UjicUo0WEi7dEXncGLvviMnZgv0mhUxENdBKIsb8EWu6Fb deGMz9iLewVL/tRT2UEUrZFIjhWJrwVBVVGI3/iOIUFZyAIXbFIf52iP3JSO3DVXWZEXeJGJ8BiQ H5FMgHIeoMVNl9UYyKIgi1gf2jEb7iiQ39gJ8pOPllhdDak7pENau7EiwWg2ACmR70hZDmkdfqUk 3kVStjhdxfVKBBIUISmSz7gqkqggt1gXJv9EGZCYVQy5GcIFJqsok60IRTnJkwiJHndBjS3iGa7S Xa0xFd4olDpYIstIHUiEkMoUFw7UN8pxIstoPH4RlVIZgImYHwl5WwRzLqyBONdljsb1GBE5lpoI Raa4lCv1WQXzFIKSHtMhGx85P0Epl4Y4IC7ZWAlijgxSiQz5I4mDL88xMKQimAFJl9foJJLRlCb0 KEdEWpelIdblE3EpmWrYhuWBXRejG59IV8dCUmmpIK0SF/4Qk6K5huTRKLSIlJ/VUsRoOHjJHFh1 F6E5mwJImBypH1xpVCjkF5rZWj3lK7sonDPpK0XJjFR0NtrIIbvZKiaZktsBnb5IXlIUGyWVdVV3 QTpYqU3XQ0VGxJZi4p29aBxz4ZzDiFUsqVXFU5z1VFxIIZvuWXzfUzq/6V33UVnG85j5aJ3FRZ5u EZz9WXUJsIioSU6BUpO2aELzGZ/kWZ1MwQQNuokj4AkCIACdMKIiKgCe4AkjeqInaqICIAom2gks KqIwGqIhCqMuiqIySqMwuqMg2gmikKIrygQj0KGaGBAAOw== --_005_48E7911F78327A449A9FB956376672864725ED17exrad4adradcoil_-- From zhiwlin@gmail.com Fri Apr 2 14:38:48 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE63F3A6823; Fri, 2 Apr 2010 14:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.970, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdPwFiBkV4fd; Fri, 2 Apr 2010 14:38:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4887C3A6AE7; Fri, 2 Apr 2010 14:25:57 -0700 (PDT) Received: by gwj20 with SMTP id 20so82831gwj.31 for ; Fri, 02 Apr 2010 14:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=uJgj9+2EqWGwnk4RvD39xPOzloEOPV/xpAg31FyaIi0=; b=b1ZBLOePI+eNA8nzjj9aKvLvahbDjaQTlsgKyuC5ZT0yDSuosTs+o2kre3IHEx8AgA AUg7Hrz+AqhYkFvEJ9uL1ptqVzljUi9inqi5s+WOSjOCfwdUAzhbPsIQjaIrMDVwhDKh s0uI4GJFdvgIWJF80C+63VrGuU4sNd2XepVWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QTkbuQmPEJCILd3SR3K5ex6EWY4sPm1VbMSobqRWNVDC+H+SBA9rmuYlptN9QVe4P8 FWgykfGmBkaeIoUslksstTtU8kn9sObHfecyacqC3h1i3Pzy+XQVZe+UVX4GJR+JKRmp pz/LsW81nrYJ1KnPjt04DaXLy9MaYC6HNg1nU= MIME-Version: 1.0 Received: by 10.100.47.12 with HTTP; Fri, 2 Apr 2010 14:26:27 -0700 (PDT) In-Reply-To: References: <436B49B8E459C54C8B47A7826292AFB4027A09@NYCTEXVS06.transit.nyct.com> Date: Fri, 2 Apr 2010 17:26:27 -0400 Received: by 10.101.131.15 with SMTP id i15mr6138539ann.13.1270243587490; Fri, 02 Apr 2010 14:26:27 -0700 (PDT) Message-ID: From: Zhi-Wei Lin To: benjamin.niven-jenkins@bt.com Content-Type: multipart/alternative; boundary=001636c92421cf84a2048347a154 Cc: mpls@ietf.org, Alexander.Vainshtein@ecitele.com, Cecil.Byles@interoute.com, CCAMP@ietf.org, Zhi-Wei.Lin@nyct.com, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [mpls-tp] Term "PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:38:48 -0000 --001636c92421cf84a2048347a154 Content-Type: text/plain; charset=UTF-8 Hi Ben, Yes, exactly! As a small network operator, we don't have the luxury that you may have in terms of a larger workforce and better funding for training. So anything that keeps things similar would be helpful, and would alleviate us struggling with terminology and fundamental technology differences. Of course there would be lots of new terms, but if we keep part of the terminology as closely coupled to transport network as possible (e.g., protection switching, manual switch, force switch, lockout, wait to restore), these would be concepts they are already familiar with and can identify. Thanks Zhi On Fri, Apr 2, 2010 at 11:30 AM, wrote: > Zhi, > > I suspect your requirement is to keep the operational procedures (MOP) for > MPLS-TP as closely aligned to those of your existing transport network as > possible. In other words if scenario A occurs, operations need to follow > steps B, C and D etc. where the functions of A, B, C and D are as similar > as > possible for MPLS-TP and your existing transport network. > > Whether the protection switching mechanism is called APS or FOO is a very > minor point in the overall operations procedure, otherwise I suspect your > operations personnel are going to really struggle with MPLS-TP with its > introduction of other new acronyms Vs transport networks like LSP, PW, BFD > etc ;-) > > Ben > > > > On 02/04/2010 15:26, "Lin, Zhi-Wei" wrote: > > > Hi Ben, > > > > Yes, definitely there are other operators with different operational > > considerations. I was offering my perspective and what my company plans > to do. > > > > However, in terms of the acronyms, even if in your company you plan to > have > > your data group handle MPLS-TP, whether the term is "MPLS-TP APS" or > "PSC", > > from their perspective it will be a new term and therefore no difference > which > > it should be. > > > > However, for other operators (such as us) who plans to have the transport > > personnel handle MPLS-TP, then "MPLS-TP APS" would make more sense. > Again, > > functionally, our transport staff will need to be trained on specific > > procedures associated with MPLS-TP, but anything that keeps things > "similar" > > is better than nothing. > > > > As such, MPLS-TP APS would be a better term that would make more > operators' > > life easier, yes? > > > > Thanks > > Zhi > > > > > > ________________________________ > > From: mpls-bounces@ietf.org on behalf of benjamin.niven-jenkins@bt.com > > Sent: Fri 4/2/2010 7:46 AM > > To: zhiwlin@gmail.com; curtis@occnc.com > > Cc: Cecil.Byles@interoute.com; mpls@ietf.org; CCAMP@ietf.org; > > Alexander.Vainshtein@ecitele.com; mpls-tp@ietf.org > > Subject: Re: [mpls] [CCAMP] [mpls-tp] Term > > "PSC"indraft-ietf-mpls-tp-linear-protection-01 > > > > > > Zhi, > > > > Thanks, I understand you perspective. > > > > However I suspect other operators may target their existing data network > > operations staff to maintain and operate an MPLS-TP network! > > > > The functionality needs to be as aligned to existing practices (MPLS and > > Transport) as possible. Re-learning/Re-definition of existing operations > > processes should be minimised but given that MPLS-TP is bridging a gap > > between data and transport networks some relearning on both sides is > > inevitable. > > > > HTH > > Ben > > > > > > > > On 25/03/2010 14:38, "Zhi-Wei Lin" wrote: > > > >> Hi, > >> > >> I like to give my perspective. As a small network company (but one of > the > >> largest transit agencies), we have a small operating staff split into > two > >> groups: one that handles traditional data network (Ethernet, IP), and > one > >> that > >> handles transport network (SONET, WDM). > >> > >> We are targeting the transport network operating staff to maintain and > >> operate > >> the MPLS-TP network. As such, anything that will help to reduce the > learning > >> curve (less training), simplify operating, and make the MOP as > consistent as > >> possible between SONET and MPLS-TP would be hugely beneficial. > >> > >> Obviously there will be some differences since MPLS-TP is a packet-based > >> transport network, but the standards groups (I don't really care for > politics > >> of IETF and ITU) should strive to make these differences easy to learn. > >> > >> Thanks > >> Zhi > >> > >> > >> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar > >> > wrote: > >> > >> In message > >> > <4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com 4B2E951>> > 0 > >> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> > >> "Cecil Byles" writes: > >>> > >>> > >>> Hi, > >>> Can I therefore also asked how PSC "Protection State Coordination" in > >>> the MPLS-TP parlance align with ITU-T 808.1 recommendation that > "defines > >>> the generic functional models, characteristics and processes associated > >>> with various linear protection schemes for connection-oriented layer > >>> networks; e.g., Optical Transport Networks (OTN), Synchronous Digital > >>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) networks" > >>> and the sections covering Terms and Definitions as well as > >>> Abbreviations. IMO all transport engineers and the general telecom > >>> community understand that 1+1 or 1:1 are either SNCP or APS. Hence why > >>> introduce a new TLA (three letter abbreviation) cover the same function > >>> and feature for MPLS-TP. I can only agree that this will only cause > >>> confusion. > >>> > >>> Cecil Byles > >> > >> > >> Though this is joint work, this is the IETF not the ITU. We should > >> use ITU terms where appropriate but where there is a conflict such as > >> this we need to pick another term and another TLA. If the ITU wants > >> to update 808.1 at some later date that is up to the ITU. In the mean > >> time we can use another term and point out the mapping. > >> > >> Curtis > >> _______________________________________________ > >> 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 > > --001636c92421cf84a2048347a154 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben,

Yes, exactly! As a small network operator, we don't have= the luxury that you may have in terms of a larger workforce and better fun= ding for training. So anything that keeps things similar would be helpful, = and would alleviate us struggling with terminology and fundamental technolo= gy differences.

Of course there would be lots of new terms, but if we keep part of the = terminology as closely coupled to transport network as possible (e.g., prot= ection switching, manual switch, force switch, lockout, wait to restore), t= hese would be concepts they are already familiar with and can identify.

Thanks
Zhi


On Fri, Apr 2, 2010= at 11:30 AM, <benjamin.niven-jenkins@bt.com> wrote:
Zhi,

I suspect your requirement is to keep the operational procedures (MOP) for<= br> MPLS-TP as closely aligned to those of your existing transport network as possible. In other words if scenario A occurs, operations need to follow steps B, C and D etc. where the functions of A, B, C and D are as similar a= s
possible for MPLS-TP and your existing transport network.

Whether the protection switching mechanism is called APS or FOO is a very minor point in the overall operations procedure, otherwise I suspect your operations personnel are going to really struggle with MPLS-TP with its
introduction of other new acronyms Vs transport networks like LSP, PW, BFD<= br> etc ;-)

Ben



On 02/04/2010 15:26, "Lin, Zhi-Wei" <Zhi-Wei.Lin@nyct.com> wrote:

> Hi Ben,
>
> Yes, definitely there are other operators with different operational > considerations. I was offering my perspective and what my company plan= s to do.
>
> However, in terms of the acronyms, even if in your company you plan to= have
> your data group handle MPLS-TP, whether the term is "MPLS-TP APS&= quot; or "PSC",
> from their perspective it will be a new term and therefore no differen= ce which
> it should be.
>
> However, for other operators (such as us) who plans to have the transp= ort
> personnel handle MPLS-TP, then "MPLS-TP APS" would make more= sense. Again,
> functionally, our transport staff will need to be trained on specific<= br> > procedures associated with MPLS-TP, but anything that keeps things &qu= ot;similar"
> is better than nothing.
>
> As such, MPLS-TP APS would be a better term that would make more opera= tors'
> life easier, yes?
>
> Thanks
> Zhi
>
>
> ________________________________
> From: mpls-bounces@ietf.org on behalf of benjamin.n= iven-jenkins@bt.com
> Sent: Fri 4/2/2010 7:46 AM
> To: zhiwlin@gmail.com; curtis@occnc.com
> Cc: Cecil.Byles@interoute= .com; mpls@ietf.org; CCAMP@ietf.org;
> Alexander.Vainshte= in@ecitele.com; mpls-tp@ietf.org
> Subject: Re: [mpls] [CCAMP] [mpls-tp] Term
> "PSC"indraft-ietf-mpls-tp-linear-protection-01
>
>
> Zhi,
>
> Thanks, I understand you perspective.
>
> However I suspect other operators may target their existing data netwo= rk
> operations staff to maintain and operate an MPLS-TP network!
>
> The functionality needs to be as aligned to existing practices (MPLS a= nd
> Transport) as possible. Re-learning/Re-definition of existing operatio= ns
> processes should be minimised but given that MPLS-TP is bridging a gap=
> between data and transport networks some relearning on both sides is > inevitable.
>
> HTH
> Ben
>
>
>
> On 25/03/2010 14:38, "Zhi-Wei Lin" <zhiwlin@gmail.com> wrote:
>
>> Hi,
>>
>> I like to give my perspective. As a small network company (but one= of the
>> largest transit agencies), we have a small operating staff split i= nto two
>> groups: one that handles traditional data network (Ethernet, IP), = and one
>> that
>> handles transport network (SONET, WDM).
>>
>> We are targeting the transport network operating staff to maintain= and
>> operate
>> the MPLS-TP network. As such, anything that will help to reduce th= e learning
>> curve (less training), simplify operating, and make the MOP as con= sistent as
>> possible between SONET and MPLS-TP would be hugely beneficial.
>>
>> Obviously there will be some differences since MPLS-TP is a packet= -based
>> transport network, but the standards groups (I don't really ca= re for politics
>> of IETF and ITU) should strive to make these differences easy to l= earn.
>>
>> Thanks
>> Zhi
>>
>>
>> On Thu, Mar 25, 2010 at 2:09 AM, Curtis Villamizar
>> <curtis@occnc.com<ma= ilto:curtis@occnc.com>> wrote= :
>>
>> In message
>>
<4B2E9510FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com= <mailto:4B2E951>>
0
>> FA2E7E4EB223A7F2F9EE3A9503A2FE59@PREX22.interoute.com>> >> "Cecil Byles" writes:
>>>
>>>
>>> Hi,
>>> Can I therefore also asked how PSC "Protection State Coor= dination" in
>>> the MPLS-TP parlance align with ITU-T 808.1 recommendation tha= t "defines
>>> the generic functional models, characteristics and processes a= ssociated
>>> with various linear protection schemes for connection-oriented= layer
>>> networks; e.g., Optical Transport Networks (OTN), Synchronous = Digital
>>> Hierarchy (SDH) networks and Asynchronous Transfer Mode (ATM) = networks"
>>> and the sections covering =C2=A0Terms and Definitions as well = as
>>> Abbreviations. =C2=A0IMO all transport engineers and the gener= al telecom
>>> community understand that 1+1 or 1:1 are either SNCP or APS. H= ence why
>>> introduce a new TLA (three letter abbreviation) cover the same= function
>>> and feature for MPLS-TP. =C2=A0I can only agree that this will= only cause
>>> confusion.
>>>
>>> Cecil Byles
>>
>>
>> Though this is joint work, this is the IETF not the ITU. =C2=A0We = should
>> use ITU terms where appropriate but where there is a conflict such= as
>> this we need to pick another term and another TLA. =C2=A0If the IT= U wants
>> to update 808.1 at some later date that is up to the ITU. =C2=A0In= the mean
>> time we can use another term and point out the mapping.
>>
>> Curtis
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org<mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


--001636c92421cf84a2048347a154-- From loa@pi.nu Sat Apr 3 02:36:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF30E3A6A01; Sat, 3 Apr 2010 02:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsuVXtBwcajt; Sat, 3 Apr 2010 02:36:34 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 76DF23A6A18; Sat, 3 Apr 2010 02:31:24 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (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 D90B6D404F; Sat, 3 Apr 2010 11:31:20 +0200 (CEST) Message-ID: <4BB70AE7.1020605@pi.nu> Date: Sat, 03 Apr 2010 11:31:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, MPLS-TP ad hoc team , pwe3@ietf.org, CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 09:36:34 -0000 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /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 From zhangguoying2010@gmail.com Sat Apr 3 18:47:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18F83A68EE for ; Sat, 3 Apr 2010 18:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.08 X-Spam-Level: **** X-Spam-Status: No, score=4.08 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW2CUv1l0eU6 for ; Sat, 3 Apr 2010 18:47:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5A0153A6405 for ; Sat, 3 Apr 2010 18:47:40 -0700 (PDT) Received: by vws16 with SMTP id 16so460551vws.31 for ; Sat, 03 Apr 2010 18:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=Z0NWces9z0ucmd1z5Qa3u+LZeHMCkZcWZStG9ddO+JI=; b=Ykii+i2hkpJuxurPYvHzS4+YykybEw81nycsjWHxZ+0osL74Fr9qaOe8QprIqPcCgV s0UMX5JBfsL84N9nMT+I2PMTmWSXQ3lCQbwyI4HLtqmhZ7qMwLYW7xbPksgdZrRy7QX2 rK+9Y6NsihSN1tUzUyp3oQHJu2rXlCwi09x3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=BTAxyfNamj5CQ1VIdn+Zx5A+jGNdhogsfJrzHbLo661s0HHiolrUdD6rUp+WTqzifn 3QEd4S2XNILQ9Yn1uMXeJl4ht7pNO+QQ6/HzQAxm9w9/ULcoHWTjkl53xojfO/KYD3t5 mBXZ+HCtKpOtqgjZHhdufKCi18PFXBVFfyW0I= Received: by 10.220.126.222 with SMTP id d30mr1790675vcs.198.1270345656451; Sat, 03 Apr 2010 18:47:36 -0700 (PDT) Received: from gyzhang ([123.118.104.36]) by mx.google.com with ESMTPS id 21sm42753072vws.2.2010.04.03.18.47.32 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Apr 2010 18:47:35 -0700 (PDT) Date: Sun, 4 Apr 2010 09:47:44 -0700 From: "zhangguoying2010" To: "ccamp@ietf.org" Message-ID: <201004040947409841860@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon432850018826_=====" Subject: [CCAMP] reply to draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 01:47:41 -0000 This is a multi-part message in MIME format. --=====003_Dragon432850018826_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi Adrian and all, This draft summarizes and clarifies the relationship between control plane and data plane behavier for LSP in GMPLS/MPLS networks which are dispersed in a number of related RFCs. The information and analysis provided in this draft is not only useful to interpret the LSP establishment performence measurement, and also help the GMPLS device vendors to better implement the data plane behaviour and avoid misdilivery of user data. And as it has been discussed in Anaheim meeting, this draft has a strong relationship with RFC5814 and draft-sun-DPM-darft, provide supportive evidence and information. Therefore, I think it would be a better idea for CCAMP to progress this work as WG document. Guoying Adrian Farrel 2010-04-01 09:34:48 ccamp@ietf.org [CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt Hi, Just noticed that I sent this to the old CCAMP address while undergoing sleep deprivation torture in Anaheim. Cheers, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Kohei Shiomoto" Sent: Tuesday, March 23, 2010 5:55 PM Subject: draft-shiomoto-ccamp-switch-programming-01.txt > Hi, > > We just discussed this document at the microphone in Anaheim. > > The question was, what to do with it. > > To remind you, the Abstract says: > > The Resource Reservation Protocol (RSVP) has been extended to support > Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) networks. The protocol enables signaling > exchanges to establish Label Switched Paths (LSPs) that traverse > nodes and links to provide end-to-end data paths. Each node is > programmed with "cross-connect" information as the signaling messages > are processed. The cross-connection information instructs the node > how to forward data that it receives. > > End points of an LSP need to know when it is safe to start sending > data so that it is not misdelivered, and so that safety issues > specific to the data plane technology are satisfied. Likewise, all > label switching routers along the path of the LSP need to know when > to programme their data planes relative to sending control plane > messages. > > This document clarifies and summarises the RSVP-TE protocol exchanges > with relation to the programming of cross-connects along an LSP for > both unidirectional and bidirectional LSPs. This document does not > define any new procedures or protocol extensions, and defers > completely to the documents that provide normative references. The > clarifications set out in this document may also be used to help > interpret LSP establishment performance figures for MPLS-TE and GMPLS > devices. > > The purpose of the draft, therefore, was not to define any new procedures, > but to attempt to clarify the existing protocol RFCs. The draft is > Informational. > > The WG needs to decide (with the chairs judging the consensus and > determining the action) how we should pursue this. > > I gave three options at the meeting: > > 1. Kill the work (no interest or not helpful) > 2. Adopt as WG draft > 3. Pursue as independent RFC > > I would be happy to hear people's comments on the draft and the options. > > No doubt the WG chairs will want to make any calls for consensus according > to their priorities for the WG. > > Thanks, > Adrian 2010-04-03 zhangguoying --=====003_Dragon432850018826_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Hi Adrian and all,
 
This draft summarizes and clarifies the relationship between control plane and data plane behavier for LSP in GMPLS/MPLS networks which are dispersed in a number of related RFCs.
 
The information and analysis provided in this draft is not only useful to interpret the LSP establishment performence measurement, and also help the GMPLS device vendors to better implement the data plane behaviour and avoid misdilivery of user data.
 
And as it has been discussed in Anaheim meeting, this draft has a strong relationship with RFC5814 and draft-sun-DPM-darft, provide supportive evidence and information.
 
Therefore, I think it would be a better idea for CCAMP to progress this work as WG document.
 
Guoying
 
Adrian Farrel
2010-04-01  09:34:48
 
[CCAMP] Fw: draft-shiomoto-ccamp-switch-programming-01.txt
Hi,
Just noticed that I sent this to the old CCAMP address while undergoing 
sleep deprivation torture in Anaheim.
Cheers,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: "Kohei Shiomoto" <Shiomoto.Kohei@lab.ntt.co.jp>
Sent: Tuesday, March 23, 2010 5:55 PM
Subject: draft-shiomoto-ccamp-switch-programming-01.txt
> Hi,
>
> We just discussed this document at the microphone in Anaheim.
>
> The question was, what to do with it.
>
> To remind you, the Abstract says:
>
>   The Resource Reservation Protocol (RSVP) has been extended to support
>   Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and
>   Generalized MPLS (GMPLS) networks. The protocol enables signaling
>   exchanges to establish Label Switched Paths (LSPs) that traverse
>   nodes and links to provide end-to-end data paths. Each node is
>   programmed with "cross-connect" information as the signaling messages
>   are processed. The cross-connection information instructs the node
>   how to forward data that it receives.
>
>   End points of an LSP need to know when it is safe to start sending
>   data so that it is not misdelivered, and so that safety issues
>   specific to the data plane technology are satisfied. Likewise, all
>   label switching routers along the path of the LSP need to know when
>   to programme their data planes relative to sending control plane
>   messages.
>
>   This document clarifies and summarises the RSVP-TE protocol exchanges
>   with relation to the programming of cross-connects along an LSP for
>   both unidirectional and bidirectional LSPs. This document does not
>   define any new procedures or protocol extensions, and defers
>   completely to the documents that provide normative references. The
>   clarifications set out in this document may also be used to help
>   interpret LSP establishment performance figures for MPLS-TE and GMPLS
>   devices.
>
> The purpose of the draft, therefore, was not to define any new procedures, 
> but to attempt to clarify the existing protocol RFCs. The draft is 
> Informational.
>
> The WG needs to decide (with the chairs judging the consensus and 
> determining the action) how we should pursue this.
>
> I gave three options at the meeting:
>
> 1. Kill the work (no interest or not helpful)
> 2. Adopt as WG draft
> 3. Pursue as independent RFC
>
> I would be happy to hear people's comments on the draft and the options.
>
> No doubt the WG chairs will want to make any calls for consensus according 
> to their priorities for the WG.
>
> Thanks,
> Adrian 
 
2010-04-03
zhangguoying
--=====003_Dragon432850018826_=====-- From ryoo@etri.re.kr Mon Apr 5 02:38:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8AD3A677D for ; Mon, 5 Apr 2010 02:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.81 X-Spam-Level: X-Spam-Status: No, score=-99.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxbAaEJSwzny for ; Mon, 5 Apr 2010 02:38:28 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id 9D83E3A68B9 for ; Mon, 5 Apr 2010 02:38:24 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Mon, 5 Apr 2010 18:38:15 +0900 X-ReadCheckMessageID: Thread-Topic: Re: [mpls] [CCAMP] [mpls-tp] Term"PSC"indraft-ietf-mpls-tp-linear-protection-01 X-ReadCheckName: CCAMP%40ietf.org Thread-Index: AcrUo7a9r1wnsfvyTLWvjLRhXrHBjAAAABhT From: "Ryoo, Jeong-dong" To: "Zhi-Wei Lin" , Priority: normal Date: Mon, 5 Apr 2010 18:38:15 +0900 Comment: ??, ??, X-SNIPER-SPF: pass (localhost: SPF record at ietf.org designates 64.170.98.32 as permitted sender) Message-ID: X-SNIPER-SENDERIP: 64.170.98.32 Content-Transfer-Encoding: 7bit X-SNIPER-MAILFROM: mpls-bounces@ietf.org X-Mailer: Microsoft CDO for Exchange 2000 X-SNIPER-RCPTTO: bcchoi@etri.re.kr, bskim25@etri.re.kr, choits@etri.re.kr, cmpark@etri.re.kr, cts@etri.re.kr, eycho@etri.re.kr, ilwoo@etri.re.kr, jaesup@etri.re.kr, jykim@etri.re.kr, mhson@etri.re.kr, parkpk@etri.re.kr, ryoo@etri.re.kr, shbyun@etri.re.kr, yhkim@etri.re.kr, yhs@etri.re.kr X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Content-class: urn:content-classes:message Importance: normal X-Virus-Scanned: amavisd-new at amsl.com X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references:date:received:message-id:subject:from:to:cc:content-type; bh=uJgj9+2EqWGwnk4RvD39xPOzloEOPV/xpAg31FyaIi0=; b=b1ZBLOePI+eNA8nzjj9aKvLvahbDjaQTlsgKyuC5ZT0yDSuosTs+o2kre3IHEx8AgAAUg7Hrz+AqhYkFvEJ9uL1ptqVzljUi9inqi5s+WOSjOCfwdUAzhbPsIQjaIrMDVwhDKhs0uI4GJFdvgIWJF80C+63VrGuU4sNd2XepVWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to:cc:content-type; b=QTkbuQmPEJCILd3SR3K5ex6EWY4sPm1VbMSobqRWNVDC+H+SBA9rmuYlptN9QVe4P8FWgykfGmBkaeIoUslksstTtU8kn9sObHfecyacqC3h1i3Pzy+XQVZe+UVX4GJR+JKRmppz/LsW81nrYJ1KnPjt04DaXLy9MaYC6HNg1nU= MIME-Version: 1.0 In-Reply-To: References: <436B49B8E459C54C8B47A7826292AFB4027A09@NYCTEXVS06.transit.nyct.com> X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: multipart/mixed; boundary="===============0122421123==" Errors-To: mpls-bounces@ietf.org X-OriginalArrivalTime: 02 Apr 2010 21:39:58.0739 (UTC) FILETIME=[0AE44E30:01CAD2AD] X-Mailman-Approved-At: Mon, 05 Apr 2010 11:34:07 -0700 Cc: mpls@ietf.org, Alexander.Vainshtein@ecitele.com, Cecil.Byles@interoute.com, CCAMP@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [mpls-tp] Term"PSC"indraft-ietf-mpls-tp-linear-protection-01 X-BeenThere: ccamp@ietf.org Reply-To: "Ryoo, Jeong-dong" List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 09:38:29 -0000 This is a multi-part message in MIME format. --===============0122421123== Content-Type: multipart/alternative; boundary="001636c92421cf84a2048347a154" --001636c92421cf84a2048347a154 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" --001636c92421cf84a2048347a154 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlh bCI+DQo8RElWPkhpLCBhbGwuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JIGRvbid0 IGhhdmUgYW55IGJpZyZuYnNwO2lzc3VlcyB3aXRoJm5ic3A7dGhlJm5ic3A7d29yZCBmb3IgYSBw cm90ZWN0aW9uIHN3aXRjaGluZywgQVBTLCZuYnNwO1BTQywgeFNDLCBvciB3aGF0ZXZlci4gQnV0 LCBqdXN0IEZZSSwgUkZDNTU4Ni1NUExTIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIGRvY3Vt ZW50IGFscmVhZHkgdXNlcyB0aGUgdGVybSBBUFMgKEF1dG9tYXRpYyBQcm90ZWN0aW9uIFN3aXRj aGluZykuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5CZXN0IHJlZ2FyZHMsPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5KZW9uZy1kb25nPC9ESVY+DQo8RElWPjxCUj4mbmJz cDs8L0RJVj4NCjxESVYgc3R5bGU9IldPUkQtQlJFQUs6IGJyZWFrLWFsbDsgRk9OVC1GQU1JTFk6 ICI+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6ICI+DQo8RElWPg0KPERJViBzdHls ZT0iRk9OVC1GQU1JTFk6ICI+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6ICI+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08QlI+SmVvbmctZG9uZyBSeW9vLCBQaC5ELjxCUj5QcmluY2lwYWwg TWVtYmVyIG9mIFJlc2VhcmNoIFN0YWZmPEJSPk5ldHdvcmsgUmVzZWFyY2ggRGVwYXJ0bWVudDxC Uj5FbGVjdHJvbmljcyBhbmQgVGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAo RVRSSSkgPEJSPlBob25lOiArODItNDItODYwLTUzODQsIEZheDogKzgyLTQyLTg2MC02MzQyPC9G T05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxCUj5FbWFpbDogPC9GT05UPjxBIGhyZWY9Im1h aWx0bzpyeW9vQGV0cmkucmUua3IiIHRhcmdldD1fYmxhbms+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+cnlvb0BldHJpLnJlLmtyPC9GT05UPjwvQT48QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRk9OVD48L0RJ Vj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj4NCjxESVY+PEJSPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiAiWmhpLVdlaSBMaW4iICZs dDt6aGl3bGluQGdtYWlsLmNvbSZndDs8QlI+PEI+RnJvbSBEYXRlOjwvQj4gMjAxMC0wNC0wMyBB TSA2OjI2OjI3PEJSPjxCPlRvOjwvQj4gImJlbmphbWluLm5pdmVuLWplbmtpbnNAYnQuY29tIiAm bHQ7YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20mZ3Q7PEJSPjxCPkNjOjwvQj4gIm1wbHNA aWV0Zi5vcmciICZsdDttcGxzQGlldGYub3JnJmd0OywgIkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tIiAmbHQ7QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20mZ3Q7LCAiQ2Vj aWwuQnlsZXNAaW50ZXJvdXRlLmNvbSIgJmx0O0NlY2lsLkJ5bGVzQGludGVyb3V0ZS5jb20mZ3Q7 LCAiQ0NBTVBAaWV0Zi5vcmciICZsdDtDQ0FNUEBpZXRmLm9yZyZndDssICJjdXJ0aXNAb2NjbmMu Y29tIiAmbHQ7Y3VydGlzQG9jY25jLmNvbSZndDssICJtcGxzLXRwQGlldGYub3JnIiAmbHQ7bXBs cy10cEBpZXRmLm9yZyZndDs8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbbXBsc10gW0NDQU1QXSBb bXBscy10cF0gVGVybSJQU0MiaW5kcmFmdC1pZXRmLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24t MDE8QlI+PEJSPkhpIEJlbiw8QlI+PEJSPlllcywgZXhhY3RseSEgQXMgYSBzbWFsbCBuZXR3b3Jr IG9wZXJhdG9yLCB3ZSBkb24ndCBoYXZlIHRoZSBsdXh1cnkgdGhhdCB5b3UgbWF5IGhhdmUgaW4g dGVybXMgb2YgYSBsYXJnZXIgd29ya2ZvcmNlIGFuZCBiZXR0ZXIgZnVuZGluZyBmb3IgdHJhaW5p bmcuIFNvIGFueXRoaW5nIHRoYXQga2VlcHMgdGhpbmdzIHNpbWlsYXIgd291bGQgYmUgaGVscGZ1 bCwgYW5kIHdvdWxkIGFsbGV2aWF0ZSB1cyBzdHJ1Z2dsaW5nIHdpdGggdGVybWlub2xvZ3kgYW5k IGZ1bmRhbWVudGFsIHRlY2hub2xvZ3kgZGlmZmVyZW5jZXMuPEJSPjxCUj5PZiBjb3Vyc2UgdGhl cmUgd291bGQgYmUgbG90cyBvZiBuZXcgdGVybXMsIGJ1dCBpZiB3ZSBrZWVwIHBhcnQgb2YgdGhl IHRlcm1pbm9sb2d5IGFzIGNsb3NlbHkgY291cGxlZCB0byB0cmFuc3BvcnQgbmV0d29yayBhcyBw b3NzaWJsZSAoZS5nLiwgcHJvdGVjdGlvbiBzd2l0Y2hpbmcsIG1hbnVhbCBzd2l0Y2gsIGZvcmNl IHN3aXRjaCwgbG9ja291dCwgd2FpdCB0byByZXN0b3JlKSwgdGhlc2Ugd291bGQgYmUgY29uY2Vw dHMgdGhleSBhcmUgYWxyZWFkeSBmYW1pbGlhciB3aXRoIGFuZCBjYW4gaWRlbnRpZnkuPEJSPjxC Uj5UaGFua3M8QlI+WmhpPEJSPjxCUj48QlI+PC9ESVY+DQo8RElWIGNsYXNzPWdtYWlsX3F1b3Rl Pk9uIEZyaSwgQXByIDIsIDIwMTAgYXQgMTE6MzAgQU0sIDxTUEFOIGRpcj1sdHI+Jmx0OzxBIGhy ZWY9Im1haWx0bzpiZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbSIgdGFyZ2V0PV9ibGFuaz5i ZW5qYW1pbi5uaXZlbi1qZW5raW5zQGJ0LmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+DQo8 QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1B UkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7IEJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFw eCBzb2xpZCI+WmhpLDxCUj48QlI+SSBzdXNwZWN0IHlvdXIgcmVxdWlyZW1lbnQgaXMgdG8ga2Vl cCB0aGUgb3BlcmF0aW9uYWwgcHJvY2VkdXJlcyAoTU9QKSBmb3I8QlI+TVBMUy1UUCBhcyBjbG9z ZWx5IGFsaWduZWQgdG8gdGhvc2Ugb2YgeW91ciBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29yayBh czxCUj5wb3NzaWJsZS4gSW4gb3RoZXIgd29yZHMgaWYgc2NlbmFyaW8gQSBvY2N1cnMsIG9wZXJh dGlvbnMgbmVlZCB0byBmb2xsb3c8QlI+c3RlcHMgQiwgQyBhbmQgRCBldGMuIHdoZXJlIHRoZSBm dW5jdGlvbnMgb2YgQSwgQiwgQyBhbmQgRCBhcmUgYXMgc2ltaWxhciBhczxCUj5wb3NzaWJsZSBm b3IgTVBMUy1UUCBhbmQgeW91ciBleGlzdGluZyB0cmFuc3BvcnQgbmV0d29yay48QlI+PEJSPldo ZXRoZXIgdGhlIHByb3RlY3Rpb24gc3dpdGNoaW5nIG1lY2hhbmlzbSBpcyBjYWxsZWQgQVBTIG9y IEZPTyBpcyBhIHZlcnk8QlI+bWlub3IgcG9pbnQgaW4gdGhlIG92ZXJhbGwgb3BlcmF0aW9ucyBw cm9jZWR1cmUsIG90aGVyd2lzZSBJIHN1c3BlY3QgeW91cjxCUj5vcGVyYXRpb25zIHBlcnNvbm5l bCBhcmUgZ29pbmcgdG8gcmVhbGx5IHN0cnVnZ2xlIHdpdGggTVBMUy1UUCB3aXRoIGl0czxCUj5p bnRyb2R1Y3Rpb24gb2Ygb3RoZXIgbmV3IGFjcm9ueW1zIFZzIHRyYW5zcG9ydCBuZXR3b3JrcyBs aWtlIExTUCwgUFcsIEJGRDxCUj5ldGMgOy0pPEJSPjxCUj5CZW48QlI+DQo8RElWPg0KPERJVj48 L0RJVj4NCjxESVYgY2xhc3M9aDU+PEJSPjxCUj48QlI+T24gMDIvMDQvMjAxMCAxNToyNiwgIkxp biwgWmhpLVdlaSIgJmx0OzxBIGhyZWY9Im1haWx0bzpaaGktV2VpLkxpbkBueWN0LmNvbSIgdGFy Z2V0PV9ibGFuaz5aaGktV2VpLkxpbkBueWN0LmNvbTwvQT4mZ3Q7IHdyb3RlOjxCUj48QlI+Jmd0 OyBIaSBCZW4sPEJSPiZndDs8QlI+Jmd0OyBZZXMsIGRlZmluaXRlbHkgdGhlcmUgYXJlIG90aGVy IG9wZXJhdG9ycyB3aXRoIGRpZmZlcmVudCBvcGVyYXRpb25hbDxCUj4mZ3Q7IGNvbnNpZGVyYXRp b25zLiBJIHdhcyBvZmZlcmluZyBteSBwZXJzcGVjdGl2ZSBhbmQgd2hhdCBteSBjb21wYW55IHBs YW5zIHRvIGRvLjxCUj4mZ3Q7PEJSPiZndDsgSG93ZXZlciwgaW4gdGVybXMgb2YgdGhlIGFjcm9u eW1zLCBldmVuIGlmIGluIHlvdXIgY29tcGFueSB5b3UgcGxhbiB0byBoYXZlPEJSPiZndDsgeW91 ciBkYXRhIGdyb3VwIGhhbmRsZSBNUExTLVRQLCB3aGV0aGVyIHRoZSB0ZXJtIGlzICJNUExTLVRQ IEFQUyIgb3IgIlBTQyIsPEJSPiZndDsgZnJvbSB0aGVpciBwZXJzcGVjdGl2ZSBpdCB3aWxsIGJl IGEgbmV3IHRlcm0gYW5kIHRoZXJlZm9yZSBubyBkaWZmZXJlbmNlIHdoaWNoPEJSPiZndDsgaXQg c2hvdWxkIGJlLjxCUj4mZ3Q7PEJSPiZndDsgSG93ZXZlciwgZm9yIG90aGVyIG9wZXJhdG9ycyAo c3VjaCBhcyB1cykgd2hvIHBsYW5zIHRvIGhhdmUgdGhlIHRyYW5zcG9ydDxCUj4mZ3Q7IHBlcnNv bm5lbCBoYW5kbGUgTVBMUy1UUCwgdGhlbiAiTVBMUy1UUCBBUFMiIHdvdWxkIG1ha2UgbW9yZSBz ZW5zZS4gQWdhaW4sPEJSPiZndDsgZnVuY3Rpb25hbGx5LCBvdXIgdHJhbnNwb3J0IHN0YWZmIHdp bGwgbmVlZCB0byBiZSB0cmFpbmVkIG9uIHNwZWNpZmljPEJSPiZndDsgcHJvY2VkdXJlcyBhc3Nv Y2lhdGVkIHdpdGggTVBMUy1UUCwgYnV0IGFueXRoaW5nIHRoYXQga2VlcHMgdGhpbmdzICJzaW1p bGFyIjxCUj4mZ3Q7IGlzIGJldHRlciB0aGFuIG5vdGhpbmcuPEJSPiZndDs8QlI+Jmd0OyBBcyBz dWNoLCBNUExTLVRQIEFQUyB3b3VsZCBiZSBhIGJldHRlciB0ZXJtIHRoYXQgd291bGQgbWFrZSBt b3JlIG9wZXJhdG9ycyc8QlI+Jmd0OyBsaWZlIGVhc2llciwgeWVzPzxCUj4mZ3Q7PEJSPiZndDsg VGhhbmtzPEJSPiZndDsgWmhpPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPEJSPiZndDsgRnJvbTogPEEgaHJlZj0ibWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L0E+IG9u IGJlaGFsZiBvZiA8QSBocmVmPSJtYWlsdG86YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb20i IHRhcmdldD1fYmxhbms+YmVuamFtaW4ubml2ZW4tamVua2luc0BidC5jb208L0E+PEJSPiZndDsg U2VudDogRnJpIDQvMi8yMDEwIDc6NDYgQU08QlI+Jmd0OyBUbzogPEEgaHJlZj0ibWFpbHRvOnpo aXdsaW5AZ21haWwuY29tIiB0YXJnZXQ9X2JsYW5rPnpoaXdsaW5AZ21haWwuY29tPC9BPjsgPEEg aHJlZj0ibWFpbHRvOmN1cnRpc0BvY2NuYy5jb20iIHRhcmdldD1fYmxhbms+Y3VydGlzQG9jY25j LmNvbTwvQT48QlI+Jmd0OyBDYzogPEEgaHJlZj0ibWFpbHRvOkNlY2lsLkJ5bGVzQGludGVyb3V0 ZS5jb20iIHRhcmdldD1fYmxhbms+Q2VjaWwuQnlsZXNAaW50ZXJvdXRlLmNvbTwvQT47IDxBIGhy ZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1wbHNAaWV0Zi5vcmc8L0E+ OyA8QSBocmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+Q0NBTVBAaWV0 Zi5vcmc8L0E+OzxCUj4mZ3Q7IDxBIGhyZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbSIgdGFyZ2V0PV9ibGFuaz5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTwvQT47IDxBIGhyZWY9Im1haWx0bzptcGxzLXRwQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1w bHMtdHBAaWV0Zi5vcmc8L0E+PEJSPiZndDsgU3ViamVjdDogUmU6IFttcGxzXSBbQ0NBTVBdIFtt cGxzLXRwXSBUZXJtPEJSPiZndDsgIlBTQyJpbmRyYWZ0LWlldGYtbXBscy10cC1saW5lYXItcHJv dGVjdGlvbi0wMTxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBaaGksPEJSPiZndDs8QlI+Jmd0OyBU aGFua3MsIEkgdW5kZXJzdGFuZCB5b3UgcGVyc3BlY3RpdmUuPEJSPiZndDs8QlI+Jmd0OyBIb3dl dmVyIEkgc3VzcGVjdCBvdGhlciBvcGVyYXRvcnMgbWF5IHRhcmdldCB0aGVpciBleGlzdGluZyBk YXRhIG5ldHdvcms8QlI+Jmd0OyBvcGVyYXRpb25zIHN0YWZmIHRvIG1haW50YWluIGFuZCBvcGVy YXRlIGFuIE1QTFMtVFAgbmV0d29yayE8QlI+Jmd0OzxCUj4mZ3Q7IFRoZSBmdW5jdGlvbmFsaXR5 IG5lZWRzIHRvIGJlIGFzIGFsaWduZWQgdG8gZXhpc3RpbmcgcHJhY3RpY2VzIChNUExTIGFuZDxC Uj4mZ3Q7IFRyYW5zcG9ydCkgYXMgcG9zc2libGUuIFJlLWxlYXJuaW5nL1JlLWRlZmluaXRpb24g b2YgZXhpc3Rpbmcgb3BlcmF0aW9uczxCUj4mZ3Q7IHByb2Nlc3NlcyBzaG91bGQgYmUgbWluaW1p c2VkIGJ1dCBnaXZlbiB0aGF0IE1QTFMtVFAgaXMgYnJpZGdpbmcgYSBnYXA8QlI+Jmd0OyBiZXR3 ZWVuIGRhdGEgYW5kIHRyYW5zcG9ydCBuZXR3b3JrcyBzb21lIHJlbGVhcm5pbmcgb24gYm90aCBz aWRlcyBpczxCUj4mZ3Q7IGluZXZpdGFibGUuPEJSPiZndDs8QlI+Jmd0OyBIVEg8QlI+Jmd0OyBC ZW48QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBPbiAyNS8wMy8yMDEwIDE0OjM4LCAi WmhpLVdlaSBMaW4iICZsdDs8QSBocmVmPSJtYWlsdG86emhpd2xpbkBnbWFpbC5jb20iIHRhcmdl dD1fYmxhbms+emhpd2xpbkBnbWFpbC5jb208L0E+Jmd0OyB3cm90ZTo8QlI+Jmd0OzxCUj4mZ3Q7 Jmd0OyBIaSw8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgSSBsaWtlIHRvIGdpdmUgbXkgcGVyc3Bl Y3RpdmUuIEFzIGEgc21hbGwgbmV0d29yayBjb21wYW55IChidXQgb25lIG9mIHRoZTxCUj4mZ3Q7 Jmd0OyBsYXJnZXN0IHRyYW5zaXQgYWdlbmNpZXMpLCB3ZSBoYXZlIGEgc21hbGwgb3BlcmF0aW5n IHN0YWZmIHNwbGl0IGludG8gdHdvPEJSPiZndDsmZ3Q7IGdyb3Vwczogb25lIHRoYXQgaGFuZGxl cyB0cmFkaXRpb25hbCBkYXRhIG5ldHdvcmsgKEV0aGVybmV0LCBJUCksIGFuZCBvbmU8QlI+Jmd0 OyZndDsgdGhhdDxCUj4mZ3Q7Jmd0OyBoYW5kbGVzIHRyYW5zcG9ydCBuZXR3b3JrIChTT05FVCwg V0RNKS48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgV2UgYXJlIHRhcmdldGluZyB0aGUgdHJhbnNw b3J0IG5ldHdvcmsgb3BlcmF0aW5nIHN0YWZmIHRvIG1haW50YWluIGFuZDxCUj4mZ3Q7Jmd0OyBv cGVyYXRlPEJSPiZndDsmZ3Q7IHRoZSBNUExTLVRQIG5ldHdvcmsuIEFzIHN1Y2gsIGFueXRoaW5n IHRoYXQgd2lsbCBoZWxwIHRvIHJlZHVjZSB0aGUgbGVhcm5pbmc8QlI+Jmd0OyZndDsgY3VydmUg KGxlc3MgdHJhaW5pbmcpLCBzaW1wbGlmeSBvcGVyYXRpbmcsIGFuZCBtYWtlIHRoZSBNT1AgYXMg Y29uc2lzdGVudCBhczxCUj4mZ3Q7Jmd0OyBwb3NzaWJsZSBiZXR3ZWVuIFNPTkVUIGFuZCBNUExT LVRQIHdvdWxkIGJlIGh1Z2VseSBiZW5lZmljaWFsLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBP YnZpb3VzbHkgdGhlcmUgd2lsbCBiZSBzb21lIGRpZmZlcmVuY2VzIHNpbmNlIE1QTFMtVFAgaXMg YSBwYWNrZXQtYmFzZWQ8QlI+Jmd0OyZndDsgdHJhbnNwb3J0IG5ldHdvcmssIGJ1dCB0aGUgc3Rh bmRhcmRzIGdyb3VwcyAoSSBkb24ndCByZWFsbHkgY2FyZSBmb3IgcG9saXRpY3M8QlI+Jmd0OyZn dDsgb2YgSUVURiBhbmQgSVRVKSBzaG91bGQgc3RyaXZlIHRvIG1ha2UgdGhlc2UgZGlmZmVyZW5j ZXMgZWFzeSB0byBsZWFybi48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgVGhhbmtzPEJSPiZndDsm Z3Q7IFpoaTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBPbiBUaHUsIE1hciAy NSwgMjAxMCBhdCAyOjA5IEFNLCBDdXJ0aXMgVmlsbGFtaXphcjxCUj4mZ3Q7Jmd0OyAmbHQ7PEEg aHJlZj0ibWFpbHRvOmN1cnRpc0BvY2NuYy5jb20iIHRhcmdldD1fYmxhbms+Y3VydGlzQG9jY25j LmNvbTwvQT4mbHQ7bWFpbHRvOjxBIGhyZWY9Im1haWx0bzpjdXJ0aXNAb2NjbmMuY29tIiB0YXJn ZXQ9X2JsYW5rPmN1cnRpc0BvY2NuYy5jb208L0E+Jmd0OyZndDsgd3JvdGU6PEJSPiZndDsmZ3Q7 PEJSPiZndDsmZ3Q7IEluIG1lc3NhZ2U8QlI+Jmd0OyZndDs8QlI+Jmx0OzxBIGhyZWY9Im1haWx0 bzo0QjJFOTUxMEZBMkU3RTRFQjIyM0E3RjJGOUVFM0E5NTAzQTJGRTU5QFBSRVgyMi5pbnRlcm91 dGUuY29tIiB0YXJnZXQ9X2JsYW5rPjRCMkU5NTEwRkEyRTdFNEVCMjIzQTdGMkY5RUUzQTk1MDNB MkZFNTlAUFJFWDIyLmludGVyb3V0ZS5jb208L0E+Jmx0O21haWx0bzo8QSBocmVmPSJtYWlsdG86 NEIyRTk1MSIgdGFyZ2V0PV9ibGFuaz40QjJFOTUxPC9BPiZndDsmZ3Q7PEJSPjA8QlI+Jmd0OyZn dDsgPEEgaHJlZj0ibWFpbHRvOkZBMkU3RTRFQjIyM0E3RjJGOUVFM0E5NTAzQTJGRTU5QFBSRVgy Mi5pbnRlcm91dGUuY29tIiB0YXJnZXQ9X2JsYW5rPkZBMkU3RTRFQjIyM0E3RjJGOUVFM0E5NTAz QTJGRTU5QFBSRVgyMi5pbnRlcm91dGUuY29tPC9BPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7ICJDZWNp bCBCeWxlcyIgd3JpdGVzOjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsm Z3Q7Jmd0OyBIaSw8QlI+Jmd0OyZndDsmZ3Q7IENhbiBJIHRoZXJlZm9yZSBhbHNvIGFza2VkIGhv dyBQU0MgIlByb3RlY3Rpb24gU3RhdGUgQ29vcmRpbmF0aW9uIiBpbjxCUj4mZ3Q7Jmd0OyZndDsg dGhlIE1QTFMtVFAgcGFybGFuY2UgYWxpZ24gd2l0aCBJVFUtVCA4MDguMSByZWNvbW1lbmRhdGlv biB0aGF0ICJkZWZpbmVzPEJSPiZndDsmZ3Q7Jmd0OyB0aGUgZ2VuZXJpYyBmdW5jdGlvbmFsIG1v ZGVscywgY2hhcmFjdGVyaXN0aWNzIGFuZCBwcm9jZXNzZXMgYXNzb2NpYXRlZDxCUj4mZ3Q7Jmd0 OyZndDsgd2l0aCB2YXJpb3VzIGxpbmVhciBwcm90ZWN0aW9uIHNjaGVtZXMgZm9yIGNvbm5lY3Rp b24tb3JpZW50ZWQgbGF5ZXI8QlI+Jmd0OyZndDsmZ3Q7IG5ldHdvcmtzOyBlLmcuLCBPcHRpY2Fs IFRyYW5zcG9ydCBOZXR3b3JrcyAoT1ROKSwgU3luY2hyb25vdXMgRGlnaXRhbDxCUj4mZ3Q7Jmd0 OyZndDsgSGllcmFyY2h5IChTREgpIG5ldHdvcmtzIGFuZCBBc3luY2hyb25vdXMgVHJhbnNmZXIg TW9kZSAoQVRNKSBuZXR3b3JrcyI8QlI+Jmd0OyZndDsmZ3Q7IGFuZCB0aGUgc2VjdGlvbnMgY292 ZXJpbmcgP1Rlcm1zIGFuZCBEZWZpbml0aW9ucyBhcyB3ZWxsIGFzPEJSPiZndDsmZ3Q7Jmd0OyBB YmJyZXZpYXRpb25zLiA/SU1PIGFsbCB0cmFuc3BvcnQgZW5naW5lZXJzIGFuZCB0aGUgZ2VuZXJh bCB0ZWxlY29tPEJSPiZndDsmZ3Q7Jmd0OyBjb21tdW5pdHkgdW5kZXJzdGFuZCB0aGF0IDErMSBv ciAxOjEgYXJlIGVpdGhlciBTTkNQIG9yIEFQUy4gSGVuY2Ugd2h5PEJSPiZndDsmZ3Q7Jmd0OyBp bnRyb2R1Y2UgYSBuZXcgVExBICh0aHJlZSBsZXR0ZXIgYWJicmV2aWF0aW9uKSBjb3ZlciB0aGUg c2FtZSBmdW5jdGlvbjxCUj4mZ3Q7Jmd0OyZndDsgYW5kIGZlYXR1cmUgZm9yIE1QTFMtVFAuID9J IGNhbiBvbmx5IGFncmVlIHRoYXQgdGhpcyB3aWxsIG9ubHkgY2F1c2U8QlI+Jmd0OyZndDsmZ3Q7 IGNvbmZ1c2lvbi48QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyBDZWNpbCBCeWxlczxC Uj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBUaG91Z2ggdGhpcyBpcyBqb2ludCB3 b3JrLCB0aGlzIGlzIHRoZSBJRVRGIG5vdCB0aGUgSVRVLiA/V2Ugc2hvdWxkPEJSPiZndDsmZ3Q7 IHVzZSBJVFUgdGVybXMgd2hlcmUgYXBwcm9wcmlhdGUgYnV0IHdoZXJlIHRoZXJlIGlzIGEgY29u ZmxpY3Qgc3VjaCBhczxCUj4mZ3Q7Jmd0OyB0aGlzIHdlIG5lZWQgdG8gcGljayBhbm90aGVyIHRl cm0gYW5kIGFub3RoZXIgVExBLiA/SWYgdGhlIElUVSB3YW50czxCUj4mZ3Q7Jmd0OyB0byB1cGRh dGUgODA4LjEgYXQgc29tZSBsYXRlciBkYXRlIHRoYXQgaXMgdXAgdG8gdGhlIElUVS4gP0luIHRo ZSBtZWFuPEJSPiZndDsmZ3Q7IHRpbWUgd2UgY2FuIHVzZSBhbm90aGVyIHRlcm0gYW5kIHBvaW50 IG91dCB0aGUgbWFwcGluZy48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgQ3VydGlzPEJSPiZndDsm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZn dDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PEJSPiZndDsmZ3Q7IDxBIGhyZWY9Im1haWx0bzptcGxz QGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPm1wbHNAaWV0Zi5vcmc8L0E+Jmx0O21haWx0bzo8QSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz5tcGxzQGlldGYub3JnPC9B PiZndDs8QlI+Jmd0OyZndDsgPEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzIiB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBsczwvQT48QlI+Jmd0OyZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDsgbXBscyBtYWlsaW5n IGxpc3Q8QlI+Jmd0OyA8QSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFu az5tcGxzQGlldGYub3JnPC9BPjxCUj4mZ3Q7IDxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L0E+PEJSPjxCUj48L0RJVj48L0RJVj48L0JMT0NLUVVP VEU+PC9ESVY+DQo8RElWPjxCUj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUi IHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9S ZWFkQ2hlY2suYXNweD9lbWFpbD1DQ0FNUEBpZXRmLm9yZyZuYW1lPUNDQU1QJTQwaWV0Zi5vcmcm ZnJvbWVtYWlsPXJ5b29AZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDYjdmNmNmZGEtMjMxZS00MjIz LWIyOGEtY2U5MDBmNGZmYTYzQGV0cmkucmUua3IlM0UiPg== --001636c92421cf84a2048347a154-- --===============0122421123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0122421123==-- From db3546@att.com Tue Apr 6 12:20:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD0A3A6994 for ; Tue, 6 Apr 2010 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7szY7bcX6yv for ; Tue, 6 Apr 2010 12:20:15 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 45E8F3A6A1E for ; Tue, 6 Apr 2010 12:17:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-121.messagelabs.com!1270581449!35926669!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17250 invoked from network); 6 Apr 2010 19:17:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Apr 2010 19:17:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o36JHGAB007203 for ; Tue, 6 Apr 2010 15:17:16 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o36JHB4m007099 for ; Tue, 6 Apr 2010 15:17:11 -0400 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: Tue, 6 Apr 2010 15:17:23 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQ== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:20:16 -0000 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah From danli@huawei.com Tue Apr 6 17:38:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069693A697B for ; Tue, 6 Apr 2010 17:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvJ5V66btLYc for ; Tue, 6 Apr 2010 17:38:48 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2750F3A62C1 for ; Tue, 6 Apr 2010 17:38:46 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00E4IDS9MO@szxga01-in.huawei.com> for ccamp@ietf.org; Wed, 07 Apr 2010 08:38:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00IZNDS9M9@szxga01-in.huawei.com> for ccamp@ietf.org; Wed, 07 Apr 2010 08:38:33 +0800 (CST) Received: from l37133a ([10.70.77.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0H008FJDS86L@szxml04-in.huawei.com> for ccamp@ietf.org; Wed, 07 Apr 2010 08:38:32 +0800 (CST) Date: Wed, 07 Apr 2010 08:38:32 +0800 From: Dan Li To: "BRUNGARD, DEBORAH A (ATTLABS)" , CCAMP Message-id: <00b501cad5ea$a6aadec0$484d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_n+slenn2V+cG4f7VWayxFQ)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:38:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_n+slenn2V+cG4f7VWayxFQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Support! as an author of this draft. Dan ----- Original Message ----- From: BRUNGARD, DEBORAH A (ATTLABS) To: CCAMP Sent: Wednesday, April 07, 2010 3:17 AM Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_n+slenn2V+cG4f7VWayxFQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Support! as an author of this draft.
 
Dan
 
----- Original Message -----
To: CCAMP
Sent: Wednesday, April 07, 2010 3:17 AM
Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02

All,

This is to start a two week poll on making
draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Tuesday, April 20th.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--Boundary_(ID_n+slenn2V+cG4f7VWayxFQ)-- From daniele.ceccarelli@ericsson.com Tue Apr 6 23:47:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB32D3A6A81 for ; Tue, 6 Apr 2010 23:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2PX0VEG3D5u for ; Tue, 6 Apr 2010 23:47:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AA1413A6A2F for ; Tue, 6 Apr 2010 23:47:09 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ec-4bbc2a693766 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B7.BA.23740.96A2CBB4; Wed, 7 Apr 2010 08:47:06 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 08:47:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 08:47:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAYB9nA References: From: "Daniele Ceccarelli" To: "BRUNGARD, DEBORAH A (ATTLABS)" , "CCAMP" X-OriginalArrivalTime: 07 Apr 2010 06:47:05.0508 (UTC) FILETIME=[22D2BE40:01CAD61E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:47:11 -0000 Yes/Support=20 BR Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A (ATTLABS) Sent: marted=EC 6 aprile 2010 21.17 To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making = draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group = document. Send a mail to the mailing list indicating "yes/support" or = "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From diego.caviglia@ericsson.com Tue Apr 6 23:49:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623C83A67D2 for ; Tue, 6 Apr 2010 23:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAtexYQ+gN0h for ; Tue, 6 Apr 2010 23:49:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 654963A684C for ; Tue, 6 Apr 2010 23:49:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ea-4bbc2b0db923 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D6.0B.23740.D0B2CBB4; Wed, 7 Apr 2010 08:49:49 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 08:49:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 08:49:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAYB9nAAAAkNdA= References: From: "Diego Caviglia" To: "CCAMP" X-OriginalArrivalTime: 07 Apr 2010 06:49:49.0537 (UTC) FILETIME=[84979510:01CAD61E] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 06:49:55 -0000 Yes/Support BR Diego line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Daniele Ceccarelli Sent: mercoled=EC 7 aprile 2010 8.47 To: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Yes/Support=20 BR Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A (ATTLABS) Sent: marted=EC 6 aprile 2010 21.17 To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making = draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group = document. Send a mail to the mailing list indicating "yes/support" or = "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Pietro_Vittorio.Grandi@alcatel-lucent.com Wed Apr 7 00:27:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616893A6891 for ; Wed, 7 Apr 2010 00:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRVxbEFrjUqq for ; Wed, 7 Apr 2010 00:27:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id A71053A681D for ; Wed, 7 Apr 2010 00:27:07 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o377PLr2027892 for ; Wed, 7 Apr 2010 09:26:53 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 09:26:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CAD623.A20608BC" Date: Wed, 7 Apr 2010 09:26:26 +0200 Message-ID: <72B2DB3EB0EAE243B7613C6F00B7C16F02629D6E@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 thread-index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAYB9nAAAAkNdAAAURTkA== References: From: "GRANDI PIETRO VITTORIO" To: "CCAMP" X-OriginalArrivalTime: 07 Apr 2010 07:26:26.0620 (UTC) FILETIME=[A227D7C0:01CAD623] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:27:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD623.A20608BC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support as co-author. Pietro =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's = relativity. (A. Einstein) -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Diego Caviglia Sent: mercoled=EC 7 aprile 2010 8.50 To: CCAMP Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Yes/Support BR Diego line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Daniele Ceccarelli Sent: mercoled=EC 7 aprile 2010 8.47 To: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Yes/Support=20 BR Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A (ATTLABS) Sent: marted=EC 6 aprile 2010 21.17 To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making = draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group = document. Send a mail to the mailing list indicating "yes/support" or = "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp ------_=_NextPart_001_01CAD623.A20608BC Content-Type: text/x-vcard; name="Grandi Pietro (pietro_vittorio.grandi@alcatel-lucent.it).vcf" Content-Transfer-Encoding: base64 Content-Description: Grandi Pietro (pietro_vittorio.grandi@alcatel-lucent.it).vcf Content-Disposition: attachment; filename="Grandi Pietro (pietro_vittorio.grandi@alcatel-lucent.it).vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlBpZXRybztHcmFuZGkNCkZOOkdyYW5kaSBQaWV0 cm8gKHBpZXRyb192aXR0b3Jpby5ncmFuZGlAYWxjYXRlbC1sdWNlbnQuaXQpDQpPUkc6QWxjYXRl bC1sdWNlbnQ7T3B0aWNzDQpURUw7V09SSztWT0lDRTorMzkgMDM5IDY4NiA0OTMwDQpURUw7Q0VM TDtWT0lDRTorMzkgMzQ4IDIyNDEwNjINClRFTDtXT1JLO0ZBWDorMzkgMDM5IDY4NiAzNTkwDQpB RFI7V09SSzo7Q1RPO1ZpYSBUcmVudG8gMzA7VmltZXJjYXRlO01pbGFuOzIwMDU5O0l0YWx5DQpM QUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6Q1RPPTBEPTBBVmlhIFRyZW50byAz MD0wRD0wQVZpbWVyY2F0ZSwgTWlsYW4gMjAwNTk9MEQ9MEFJdGFseQ0KRU1BSUw7UFJFRjtJTlRF Uk5FVDpwaWV0cm9fdml0dG9yaW8uZ3JhbmRpQGFsY2F0ZWwtbHVjZW50Lml0DQpSRVY6MjAwOTA3 MTRUMDk0MzAxWg0KRU5EOlZDQVJEDQo= ------_=_NextPart_001_01CAD623.A20608BC-- From isacco.fontana@trentinonetwork.it Wed Apr 7 00:38:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621033A679F for ; Wed, 7 Apr 2010 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5h6kN0ABsz2 for ; Wed, 7 Apr 2010 00:38:46 -0700 (PDT) Received: from croce.trentinonetwork.it (croce.trentinonetwork.it [77.72.192.4]) by core3.amsl.com (Postfix) with ESMTP id 56AF83A6783 for ; Wed, 7 Apr 2010 00:38:46 -0700 (PDT) Received: from croce.trentinonetwork.it (localhost [127.0.0.1]) by croce.trentinonetwork.it (Postfix) with ESMTP id 913CE3AC2A3; Wed, 7 Apr 2010 09:39:35 +0200 (CEST) Received: from [172.25.18.56] (unknown [172.25.18.56]) by croce.trentinonetwork.it (Postfix) with ESMTP id 845AC3AC092; Wed, 7 Apr 2010 09:39:35 +0200 (CEST) Message-ID: <4BBC3674.6020604@trentinonetwork.it> Date: Wed, 07 Apr 2010 09:38:28 +0200 From: Isacco Fontana User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A (ATTLABS)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: CCAMP Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:38:47 -0000 BRUNGARD, DEBORAH A (ATTLABS) ha scritto: > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > support. Isacco --------------------------------------------------------------------------------------------------------------------------- From Sergio.Belotti@alcatel-lucent.com Wed Apr 7 00:48:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D979F3A679F for ; Wed, 7 Apr 2010 00:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVmeUfYSNI40 for ; Wed, 7 Apr 2010 00:48:50 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 347A13A6A82 for ; Wed, 7 Apr 2010 00:48:49 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o377md8t030186; Wed, 7 Apr 2010 09:48:42 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 09:48:39 +0200 Received: from FRMRSSMBS35.ad2.ad.alcatel.com ([155.132.6.15]) by FRVELSMBS21.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 09:48:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 09:48:38 +0200 Message-ID: <4CC99780D4CB2F4EB248D3AAC1DF5021547090@FRMRSSMBS35.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAaH4qw References: From: "BELOTTI SERGIO" To: "CCAMP" X-OriginalArrivalTime: 07 Apr 2010 07:48:39.0110 (UTC) FILETIME=[BC61AE60:01CAD626] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [CCAMP] R: poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:48:52 -0000 =20 Yes/Support! as an author of this draft. =20 Best Regards Sergio Sergio Belotti CTO Optics Division Alcatel-Lucent +39 039 6863033 +39 039 6863590 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di = BRUNGARD, DEBORAH A (ATTLABS) Inviato: marted=EC 6 aprile 2010 21.17 A: CCAMP Oggetto: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making = draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group = document. Send a mail to the mailing list indicating "yes/support" or = "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From hhelvoort@chello.nl Wed Apr 7 00:49:25 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7BE3A6A8E for ; Wed, 7 Apr 2010 00:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnnOJyWQyAfP for ; Wed, 7 Apr 2010 00:49:24 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id EEFCD3A679F for ; Wed, 7 Apr 2010 00:49:23 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep14-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100407074920.YWQN2911.viefep14-int.chello.at@edge02.upcmail.net> for ; Wed, 7 Apr 2010 09:49:20 +0200 Received: from McAsterix.local ([24.132.217.64]) by edge02.upcmail.net with edge id 2XpJ1e07p1Px1NY02XpL0D; Wed, 07 Apr 2010 09:49:20 +0200 X-SourceIP: 24.132.217.64 Message-ID: <4BBC38FE.6080401@chello.nl> Date: Wed, 07 Apr 2010 09:49:18 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: ccamp@ietf.org References: <00b501cad5ea$a6aadec0$484d460a@china.huawei.com> In-Reply-To: <00b501cad5ea$a6aadec0$484d460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=tsaDvxd5BMYuajhtvJLL+Ppe47iaIgCGP4JcOtoQkcg= c=1 sm=0 a=kwPPv95kyT8A:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=NXqN3XgwPrUniCVLse0A:9 a=DxxwlJJjgiel3swteesA:7 a=-7nqyMDLxTG54W5tQkzgDUk4CfwA:4 a=wPNLvfGTeEIA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:49:25 -0000 Support! Regards, Huub. > ----- Original Message ----- > *From:* BRUNGARD, DEBORAH A (ATTLABS) > *To:* CCAMP > *Sent:* Wednesday, April 07, 2010 3:17 AM > *Subject:* [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 > > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp -- ================================================================ Always remember that you are unique...just like everyone else... From lieven.levrau@alcatel-lucent.com Wed Apr 7 00:50:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735D03A6A8C for ; Wed, 7 Apr 2010 00:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0uniDRr1yb9 for ; Wed, 7 Apr 2010 00:50:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 61E0D3A679F for ; Wed, 7 Apr 2010 00:50:52 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o377ojFc029793 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Apr 2010 09:50:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 7 Apr 2010 09:50:24 +0200 From: "LEVRAU, LIEVEN (LIEVEN)" To: "ccamp@ietf.org" Date: Wed, 7 Apr 2010 09:50:22 +0200 Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrWJt4OGiG89ROpQnipXS2vRzjRuQAAA5Kw Message-ID: References: <00b501cad5ea$a6aadec0$484d460a@china.huawei.com> <4BBC38FE.6080401@chello.nl> In-Reply-To: <4BBC38FE.6080401@chello.nl> 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 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:50:53 -0000 Support ./ Lieven >=20 > > ----- Original Message ----- > > *From:* BRUNGARD, DEBORAH A (ATTLABS) > > *To:* CCAMP > > *Sent:* Wednesday, April 07, 2010 3:17 AM > > *Subject:* [CCAMP] poll on draft-zhang-ccamp-gmpls-g709- > framework-02 > > > > All, > > > > This is to start a two week poll on making > > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working > group > > document. Send a mail to the mailing list indicating > "yes/support" or > > "no/do not support". > > > > The poll ends Tuesday, April 20th. > > > > Deborah > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 From Attila.Takacs@ericsson.com Wed Apr 7 01:11:36 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420C23A6A95 for ; Wed, 7 Apr 2010 01:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylP4YrEwoSC7 for ; Wed, 7 Apr 2010 01:11:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4964D3A6A92 for ; Wed, 7 Apr 2010 01:11:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-10-4bbc3e2e4e0e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CA.09.23532.E2E3CBB4; Wed, 7 Apr 2010 10:11:26 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.198]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 7 Apr 2010 10:11:26 +0200 From: Attila Takacs To: "BRUNGARD, DEBORAH A (ATTLABS)" , CCAMP Date: Wed, 7 Apr 2010 10:11:25 +0200 Thread-Topic: poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAbBm8Q Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C12D7B6CA03@ESESSCMS0355.eemea.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:11:36 -0000 Support. Attila=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: Tuesday, April 06, 2010 9:17 PM > To: CCAMP > Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 >=20 > All, >=20 > This is to start a two week poll on making=20 > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working=20 > group document. Send a mail to the mailing list indicating=20 > "yes/support" or "no/do not support". >=20 > The poll ends Tuesday, April 20th. >=20 > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > = From dieter.beller@alcatel-lucent.com Wed Apr 7 01:51:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194543A6830 for ; Wed, 7 Apr 2010 01:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udyv7PTRNLJF for ; Wed, 7 Apr 2010 01:51:26 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 094773A682D for ; Wed, 7 Apr 2010 01:51:25 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o378oq1w017582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 7 Apr 2010 10:51:21 +0200 Received: from [149.204.106.249] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 7 Apr 2010 10:51:01 +0200 Message-ID: <4BBC4775.2040809@alcatel-lucent.com> Date: Wed, 7 Apr 2010 10:51:01 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 CC: CCAMP References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000009000906020906000707" X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:51:27 -0000 --------------000009000906020906000707 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit yes/support

Cheers,
Dieter

On 06.04.2010 21:17, BRUNGARD, DEBORAH A (ATTLABS) wrote: 
All,

This is to start a two week poll on making
draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Tuesday, April 20th.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--
--------------000009000906020906000707 Content-Type: text/x-vcard; charset="utf-8"; name="Dieter_Beller.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Dieter_Beller.vcf" begin:vcard fn:Dieter Beller n:Beller;Dieter org:Alcatel-Lucent, Carrier Product Group;Optics Product Division - Product Unit Cross Connects adr:;;Lorenzstrasse 10;Stuttgart;;70435;Germany email;internet:Dieter.Beller@alcatel-lucent.com tel;work:+49 711 821-43125 tel;cell:+49 175 7266874 note;quoted-printable:Alcatel-Lucent Deutschland AG=0D=0A= =0D=0A= Domicile of the Company: Stuttgart =C2=B7 Local Court Stuttgart HRB 4026=0D=0A= Chairman of the Supervisory Board: Michael Oppenhoff=0D=0A= Board of Management: Alf Henryk Wulf (Chairman) =C2=B7 Hans-J=C3=B6rg Dau= b =C2=B7=0D=0A= Dr. Rainer Fechner =C2=B7 Peter Kury x-mozilla-html:TRUE version:2.1 end:vcard --------------000009000906020906000707-- From kam.lam@alcatel-lucent.com Wed Apr 7 03:51:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CC13A694F for ; Wed, 7 Apr 2010 03:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y9sEcQkZZ89 for ; Wed, 7 Apr 2010 03:51:54 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id ACD9D3A68C3 for ; Wed, 7 Apr 2010 03:51:54 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o37Appvf008091 for ; Wed, 7 Apr 2010 05:51:51 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o37AppYk017408 for ; Wed, 7 Apr 2010 05:51:51 -0500 (CDT) Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 7 Apr 2010 05:51:51 -0500 From: "Lam, Hing-Kam (Kam)" To: CCAMP Date: Wed, 7 Apr 2010 05:51:42 -0500 Thread-Topic: poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAglhcg Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD5413A1916@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:51:55 -0000 Support --Kam =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > BRUNGARD, DEBORAH A (ATTLABS) > Sent: Tuesday, April 06, 2010 3:17 PM > To: CCAMP > Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 >=20 > All, >=20 > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". >=20 > The poll ends Tuesday, April 20th. >=20 > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From eve.varma@alcatel-lucent.com Wed Apr 7 04:11:58 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575253A68B8 for ; Wed, 7 Apr 2010 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7graeekSid8q for ; Wed, 7 Apr 2010 04:11:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 78A873A6870 for ; Wed, 7 Apr 2010 04:11:57 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o37BBrvZ026644; Wed, 7 Apr 2010 06:11:53 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id o37BBrk5018729; Wed, 7 Apr 2010 06:11:53 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 7 Apr 2010 06:11:53 -0500 From: "Varma, Eve L (Eve)" To: "BRUNGARD, DEBORAH A (ATTLABS)" , CCAMP Date: Wed, 7 Apr 2010 06:11:52 -0500 Thread-Topic: poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAhU6Vg Message-ID: <84208699E388BB4B83AD8BEA84A04AC724F83E210A@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Wed, 07 Apr 2010 05:11:10 -0700 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 11:11:58 -0000 Yes/support. Eve -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= RUNGARD, DEBORAH A (ATTLABS) Sent: Tuesday, April 06, 2010 3:17 PM To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From prvs=17132f20be=sunwq@mit.edu Wed Apr 7 05:20:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA363A6892 for ; Wed, 7 Apr 2010 05:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+wULFm0WSwC for ; Wed, 7 Apr 2010 05:20:09 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 154A13A6922 for ; Wed, 7 Apr 2010 05:19:23 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-09-4bbc7846843a Received: from mailhub-1.mit.edu (MAILHUB-1.MIT.EDU [18.9.21.34]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 59.93.12528.6487CBB4; Wed, 7 Apr 2010 08:19:18 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-1.mit.edu (8.13.8/8.9.2) with ESMTP id o37CJHtp023382; Wed, 7 Apr 2010 08:19:18 -0400 Received: from [192.168.1.107] (210.195.79.124.broad.xw.sh.dynamic.163data.com.cn [124.79.195.210] (may be forged)) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o37CJd4u011148; Wed, 7 Apr 2010 08:19:41 -0400 (EDT) User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 07 Apr 2010 20:18:59 +0800 From: Weiqiang Sun To: "BRUNGARD, DEBORAH A (ATTLABS)" , CCAMP Message-ID: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAjrb52 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:20:17 -0000 Yes/support. -weiqiang On 4/7/10 3:17 AM, "BRUNGARD, DEBORAH A (ATTLABS)" wrote: > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jeff.tantsura@ericsson.com Wed Apr 7 08:49:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDF83A6945 for ; Wed, 7 Apr 2010 08:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV6n2U2zU2m9 for ; Wed, 7 Apr 2010 08:49:03 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1226D3A6992 for ; Wed, 7 Apr 2010 08:48:56 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o37Fqt8S026158 for ; Wed, 7 Apr 2010 10:52:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 7 Apr 2010 11:48:53 -0400 From: Jeff Tantsura To: "ccamp@ietf.org" Date: Wed, 7 Apr 2010 11:48:52 -0400 Thread-Topic: [CCAMP] R: poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAaH4qwABDdeCA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60481AE625A@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] R: poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 15:49:04 -0000 Yes/Support Regards, Jeff =20 -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di BRU= NGARD, DEBORAH A (ATTLABS) Inviato: marted=EC 6 aprile 2010 21.17 A: CCAMP Oggetto: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-fra= mework-02.txt a ccamp working group document. Send a mail to the mailing li= st indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From malcolm.betts@zte.com.cn Wed Apr 7 09:47:04 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E973A6860 for ; Wed, 7 Apr 2010 09:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.188 X-Spam-Level: X-Spam-Status: No, score=-101.188 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFjEHxvDpaxZ for ; Wed, 7 Apr 2010 09:47:03 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E47B03A6940 for ; Wed, 7 Apr 2010 09:46:52 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 58071473195744; Thu, 8 Apr 2010 00:44:46 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 83532.473195744; Thu, 8 Apr 2010 00:46:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o37Gl4K0038240 for ; Thu, 8 Apr 2010 00:47:04 +0800 (CST) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: To: "CCAMP" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 7 Apr 2010 12:46:35 -0400 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-08 00:46:44, Serialize complete at 2010-04-08 00:46:44 Content-Type: multipart/alternative; boundary="=_alternative 005C258D852576FE_=" X-MAIL: mse2.zte.com.cn o37Gl4K0038240 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:47:04 -0000 This is a multipart message in MIME format. --=_alternative 005C258D852576FE_= Content-Type: text/plain; charset="US-ASCII" Yes/support. Malcolm "BRUNGARD, DEBORAH A (ATTLABS)" Sent by: ccamp-bounces@ietf.org 06/04/2010 03:17 PM To "CCAMP" cc Subject [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 005C258D852576FE_= Content-Type: text/html; charset="US-ASCII"
Yes/support.

Malcolm



"BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
Sent by: ccamp-bounces@ietf.org

06/04/2010 03:17 PM

To
"CCAMP" <ccamp@ietf.org>
cc
Subject
[CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02





All,

This is to start a two week poll on making
draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Tuesday, April 20th.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--=_alternative 005C258D852576FE_=-- From julien.meuric@orange-ftgroup.com Wed Apr 7 09:51:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F01E3A6765 for ; Wed, 7 Apr 2010 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPBPFZKPOg7f for ; Wed, 7 Apr 2010 09:51:00 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 364973A6937 for ; Wed, 7 Apr 2010 09:50:59 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7D1078B8003; Wed, 7 Apr 2010 18:50:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 767E38B8002; Wed, 7 Apr 2010 18:50:58 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 18:50:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 18:50:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 thread-index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAszuXQ References: From: To: X-OriginalArrivalTime: 07 Apr 2010 16:50:49.0077 (UTC) FILETIME=[79C0BA50:01CAD672] Cc: ccamp@ietf.org Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 16:51:01 -0000 Hi Deborah. I would like to help Yielding an Effective Support and say "YES". :-) Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Apr 7 11:55:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E3C3A68F3 for ; Wed, 7 Apr 2010 11:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fb5oVx0Auyg for ; Wed, 7 Apr 2010 11:55:40 -0700 (PDT) Received: from outbound-mail-01.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 18F893A67F5 for ; Wed, 7 Apr 2010 11:55:40 -0700 (PDT) Received: (qmail 6722 invoked by uid 0); 7 Apr 2010 18:55:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 7 Apr 2010 18:55:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=m9oYjiPJv1wEeX9gqybZd2Ftn4F6hxVYVXqQiDqpiLHV7Df89BWOTF+7tMdieX3BJAaoryXpe1ao24GmpFIWwXgaT6QnuBh2kMofZ15rMqtVkiFmey4JkAykxC5xgGh+; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NzaPZ-0004Dz-8f; Wed, 07 Apr 2010 12:55:37 -0600 Message-ID: <4BBCD538.8060005@labn.net> Date: Wed, 07 Apr 2010 14:55:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Chairs Subject: [CCAMP] Draft IETF77 CCAMP WG minutes posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 18:55:41 -0000 Thanks to Dan King the draft minutes from IETF 77 can be found at: http://www.ietf.org/proceedings/10mar/minutes/ccamp.htm . Please send any corrections you may have to the chairs and Dan by April 22. Much thanks, Lou From root@core3.amsl.com Wed Apr 7 12:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 349393A694D; Wed, 7 Apr 2010 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100407191502.349393A694D@core3.amsl.com> Date: Wed, 7 Apr 2010 12:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-06.txt Pages : 55 Date : 2010-04-07 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. In addition, electro-optical network elements and their compatibility constraints relative to optical signal parameters are characterized. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation architectures that could be realized via various combinations of extended GMPLS and PCE protocols. This memo focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-07120520.I-D@ietf.org> --NextPart-- From ylee@huawei.com Wed Apr 7 12:59:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F493A67D3 for ; Wed, 7 Apr 2010 12:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcjIuUHeRreR for ; Wed, 7 Apr 2010 12:59:05 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 33BC63A67A4 for ; Wed, 7 Apr 2010 12:59:05 -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 <0L0I006MPVID95@usaga02-in.huawei.com> for ccamp@ietf.org; Wed, 07 Apr 2010 12:59:02 -0700 (PDT) Received: from L73682 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0I00IWTVIDUL@usaga02-in.huawei.com> for ccamp@ietf.org; Wed, 07 Apr 2010 12:59:01 -0700 (PDT) Date: Wed, 07 Apr 2010 14:59:02 -0500 From: Young Lee In-reply-to: To: "'BRUNGARD, DEBORAH A (ATTLABS)'" , 'CCAMP' Message-id: <008701cad68c$c5136ab0$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQAzvNzw References: Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 19:59:06 -0000 Yes/support. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Tuesday, April 06, 2010 2:17 PM To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From fu.xihua@zte.com.cn Wed Apr 7 22:47:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFDC3A69E0 for ; Wed, 7 Apr 2010 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpcPcjvy-fO2 for ; Wed, 7 Apr 2010 22:47:43 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BD86B3A69CE for ; Wed, 7 Apr 2010 22:44:25 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 58071473195744; Thu, 8 Apr 2010 13:42:14 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 97773.2187257994; Thu, 8 Apr 2010 13:41:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o385i2Yu032457; Thu, 8 Apr 2010 13:44:02 +0800 (CST) (envelope-from fu.xihua@zte.com.cn) To: "CCAMP" , db3546@att.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 8 Apr 2010 13:46:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-04-08 13:43:55, Serialize complete at 2010-04-08 13:43:55 Content-Type: multipart/alternative; boundary="=_alternative 001F7B80482576FF_=" X-MAIL: mse2.zte.com.cn o385i2Yu032457 Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 05:47:44 -0000 This is a multipart message in MIME format. --=_alternative 001F7B80482576FF_= Content-Type: text/plain; charset="US-ASCII" Yes/support. Xihua Fu ZTE Corporation "BRUNGARD, DEBORAH A (ATTLABS)" Sent by: ccamp-bounces@ietf.org 06/04/2010 03:17 PM To "CCAMP" cc Subject [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 001F7B80482576FF_= Content-Type: text/html; charset="US-ASCII"
Yes/support.

Xihua Fu
ZTE Corporation



"BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
Sent by: ccamp-bounces@ietf.org

06/04/2010 03:17 PM

To
"CCAMP" <ccamp@ietf.org>
cc
Subject
[CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02





All,

This is to start a two week poll on making
draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Tuesday, April 20th.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--=_alternative 001F7B80482576FF_=-- From root@core3.amsl.com Thu Apr 8 01:45:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 206093A6783; Thu, 8 Apr 2010 01:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100408084502.206093A6783@core3.amsl.com> Date: Thu, 8 Apr 2010 01:45:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Labels for Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt Pages : 14 Date : 2010-04-08 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi- Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-08013810.I-D@ietf.org> --NextPart-- From danli@huawei.com Thu Apr 8 02:38:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966E63A6407 for ; Thu, 8 Apr 2010 02:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv0HBciOc7Gt for ; Thu, 8 Apr 2010 02:38:00 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B170F3A6835 for ; Thu, 8 Apr 2010 02:37:58 -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 <0L0J00HZHXEW1U@szxga03-in.huawei.com> for ccamp@ietf.org; Thu, 08 Apr 2010 17:37:45 +0800 (CST) Received: from 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 <0L0J00373XEWZW@szxga03-in.huawei.com> for ccamp@ietf.org; Thu, 08 Apr 2010 17:37:44 +0800 (CST) Received: from l37133a ([10.70.77.72]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0J007RHXEW5V@szxml06-in.huawei.com> for ccamp@ietf.org; Thu, 08 Apr 2010 17:37:44 +0800 (CST) Date: Thu, 08 Apr 2010 17:37:38 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <025c01cad6ff$20d44ff0$484d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_wRbkCwXDq9rBP7S4zKJfZA)" X-Priority: 3 X-MSMail-priority: Normal References: <20100408084502.206093A6783@core3.amsl.com> Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:38:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wRbkCwXDq9rBP7S4zKJfZA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, We just updated the lambda-label draft (version 07): http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt There is no technical change, only minor editorial changes have been made: 1) The order of the authors' list, and also the editors on first page; 2) Corrected the label format figures in appendix section. Co-chairs, we think this draft is stable and would like to request the WG LC processing. Thanks, Dan ----- Original Message ----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ietf.org Sent: Thursday, April 08, 2010 4:45 PM Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Labels for Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt Pages : 14 Date : 2010-04-08 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi- Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------------ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_wRbkCwXDq9rBP7S4zKJfZA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
We just updated the lambda-label draft (version 07):
 
There is no technical change, only minor editorial changes have been made:
1) The order of the authors' list, and also the editors on first page;
2) Corrected the label format figures in appendix section.
 
Co-chairs, we think this draft is stable and would like to request the WG LC processing.
 
Thanks,
 
Dan
 
----- Original Message -----
Sent: Thursday, April 08, 2010 4:45 PM
Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.


Title           : Generalized Labels for Lambda-Switching Capable Label Switching Routers
Author(s)       : T. Otani, et al.
Filename        : draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt
Pages           : 14
Date            : 2010-04-08

Technology in the optical domain is constantly evolving and as a
consequence new equipment providing lambda switching capability has
been developed and is currently being deployed. However, [RFC3471]
has defined that a wavelength label (section 3.2.1.1) "only has
significance between two neighbors" and global wavelength continuity
is not considered. In order to achieve interoperability in a network
composed of next generation lambda switch-capable equipment, this
document defines a standard lambda label format, being compliant
with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover
some consideration on how to ensure lambda continuity with RSVP-TE
is provided. This document is a companion to the Generalized Multi-
Protocol Label Switching (GMPLS) signaling. It defines the label
format when Lambda Switching is requested in an all optical network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-07.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--Boundary_(ID_wRbkCwXDq9rBP7S4zKJfZA)-- From ylee@huawei.com Thu Apr 8 07:55:23 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6307A3A69FB for ; Thu, 8 Apr 2010 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhTDufrsQRSj for ; Thu, 8 Apr 2010 07:55:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2B6CF3A67B4 for ; Thu, 8 Apr 2010 07:55:09 -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 <0L0K00JYOC3TAJ@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 08 Apr 2010 09:55:06 -0500 (CDT) Received: from L73682 ([10.124.12.75]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0K0052OC3RJS@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 08 Apr 2010 09:55:05 -0500 (CDT) Date: Thu, 08 Apr 2010 09:55:03 -0500 From: Young Lee To: 'CCAMP' Message-id: <002201cad72b$78debfb0$4b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_e83riDxHbhv6FaHEkmO7Lw)" Thread-index: AcrXK3fY/v0ik5IlTkC1XzKYRT9shQ== Subject: [CCAMP] adjacent lambda constraint X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:55:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_e83riDxHbhv6FaHEkmO7Lw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi CCAMPers, During the last CCAMP meeting in Anaheim, the adjacent lambda constraint issue (http://tools.ietf.org/html/draft-schroetter-wson-ospf-link-info-00) was raised if this should be included in the WSON Framework. An Adjacent Lambda constraint is a particular example of an impairment associated constraint, e.g., when there are 40G and 10G channels coexist. Hence this is a bit advanced topic to be included in the current WSON framework. How best to model this needs a bit more thought, though this is one reasonable approach. For some DWDM systems different polarization is used on adjacent channels and hence can couple adjacent channel effects with PMD as well as simple cross talk due to spectrum overlap. Hence we probably would want to bring this issue up with ITU-T. As such we would want to address this in the impairment framework document. We believe that the WSON Framework (06 version) is ready for WG LC. The following is the summary of changes in 06 version: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-06 - We deleted research-oriented/background material: o Section 4.3 "Lightpath Temporal Characteristic" has been taken out o Section 6.1.4 RWA algorithm related information has been taken out. o Section 6.3.1 Lightpath duration/timeliness discussion has been taken out. - Editorial: o Deleted section 6.4 summary (redundant info) o Defined translucent/transparent network in the terminology section Please let us know if there is any question on the updated version. Thanks. Greg and Young --Boundary_(ID_e83riDxHbhv6FaHEkmO7Lw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = CCAMPers,

 

During the last = CCAMP meeting in Anaheim, the adjacent lambda constraint issue (http://tools.ietf.org/html/draft-schroetter-wson-ospf-link-info-00= ) was raised if this should be included in the WSON Framework. =

 

An Adjacent Lambda constraint is a particular example of an impairment associated = constraint, e.g., when there are 40G and 10G channels coexist. Hence this is a bit = advanced topic to be included in the current WSON framework. How best to model = this needs a bit more thought, though this is one reasonable approach. For = some DWDM systems different polarization is used on adjacent channels and hence = can couple adjacent channel effects with PMD as well as simple cross talk due to = spectrum overlap. Hence we probably would want to bring this issue up with ITU-T. = As such we would want to address this in the impairment framework = document.

 

We believe that the = WSON Framework (06 version) is ready for WG LC. The following is the summary = of changes in 06 version: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-06

 

­        We deleted research-oriented/background material:

 

o     Section 4.3 "Lightpath Temporal Characteristic" has been taken = out

o     Section 6.1.4 RWA algorithm related information has been taken = out.

o     Section 6.3.1 Lightpath duration/timeliness discussion has been taken = out.

 

­        Editorial:

o     Deleted section 6.4 summary (redundant info) =

o     Defined translucent/transparent network in the terminology = section

 

Please let us know if there is any question = on the updated version. Thanks.

 

Greg and Young

--Boundary_(ID_e83riDxHbhv6FaHEkmO7Lw)-- From davari@broadcom.com Thu Apr 8 12:00:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCDB3A6ACE; Thu, 8 Apr 2010 12:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDnTjdtugPy3; Thu, 8 Apr 2010 12:00:02 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 32C6A3A69B2; Thu, 8 Apr 2010 12:00:02 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 08 Apr 2010 11:59:50 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 8 Apr 2010 11:59:49 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 11:59:48 -0700 Thread-Topic: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> In-Reply-To: <4BB70AE7.1020605@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A0F82C38O166931249-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [CCAMP] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:00:03 -0000 Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CC= AMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /Loa --=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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From jdrake@juniper.net Thu Apr 8 12:25:48 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977DF3A6A13; Thu, 8 Apr 2010 12:25:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P77snLQMQXAp; Thu, 8 Apr 2010 12:25:47 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id A2BB93A68DD; Thu, 8 Apr 2010 12:25:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS74trX4Qb95rMr2U68Dihk60FNUjzTfj@postini.com; Thu, 08 Apr 2010 12:25:44 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Apr 2010 12:20:38 -0700 From: John E Drake To: Shahram Davari , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:20:36 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbA= Message-ID: <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:25:48 -0000 Sharam, We have been through this at least twice before. The best way to think E-L= SPs is that the former EXP bits in the header are part of an extended label= . So you effectively have eight parallel LSPs and there is no packet re-or= dering within each. Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made. Thanks, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Thursday, April 08, 2010 12:00 PM > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Apr 8 12:30:23 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76843A6ABD; Thu, 8 Apr 2010 12:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp0NTzrrphRA; Thu, 8 Apr 2010 12:30:22 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 703643A6AD3; Thu, 8 Apr 2010 12:30:22 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 08 Apr 2010 12:30:05 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 8 Apr 2010 12:30:05 -0700 From: "Shahram Davari" To: "John E Drake" , "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "MPLS-TP ad hoc team" , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:30:03 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A0F13731G84960335-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:30:23 -0000 Hi John, Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?=20 Thanks SD -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Thursday, April 08, 2010 12:21 PM To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP= ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11 Sharam, We have been through this at least twice before. The best way to think E-L= SPs is that the former EXP bits in the header are part of an extended label= . So you effectively have eight parallel LSPs and there is no packet re-or= dering within each. Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made. Thanks, John > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Thursday, April 08, 2010 12:00 PM > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Thu Apr 8 12:31:08 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84033A6ACA; Thu, 8 Apr 2010 12:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUNqmY3dn4Rs; Thu, 8 Apr 2010 12:31:07 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 1DDA73A6ABE; Thu, 8 Apr 2010 12:31:06 -0700 (PDT) Received: by ywh38 with SMTP id 38so1302611ywh.29 for ; Thu, 08 Apr 2010 12:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=DLP7A3H0WQ9m+/webozNCiWoYKjm+qRHeeoX1ZkYKUc=; b=CVwmQarLqOH8NZeui2xVUpHePU35mY3HfyNH+sk66/1aeuEwALlt4jVDLv/OHd6rGC 6ID/0xRlF1lu1CMjiyvrcuyDm5ISGP4GDff0D1+Su73li4P/ZAJGwWBypYZvOwS56oEV uKOXYKdy+2L8QyI8tVUQxGGWBG6xeCMMMW4aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cQkVqvOA3rOcNRjhXpDeUew6a3coqNcsQEp8gq/5d+GbDgR41Iaw7b6eeiyDu69SWu S4eidfx1bjYjA7LHfQtDvi8ru9jQBoXsS/gqTtTaftSn9FQpdpk6pVAxrC3r7NA3v50R ryhOZF+kKEN4QF3bct+oGUhc9+j6cJsq8B1bY= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:30:59 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 12:30:59 -0700 Received: by 10.90.14.37 with SMTP id 37mr155597agn.94.1270755059569; Thu, 08 Apr 2010 12:30:59 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=0016361e8936ec189d0483beb745 Cc: "mpls@ietf.org" , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:31:08 -0000 --0016361e8936ec189d0483beb745 Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > Hi Loa, > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > we know traditional transport layers only have one CoS. However E-LSP has > multiple CoS, which can reorder packets (I know that the reorder packets > belong to different CoS). Additionally the definition of E-LSP OAM and > performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > should be discouraged. > > Regards, > Shahram > > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > CCAMP > Subject: [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > All, > > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > Please note that this wg last call is limited to verify that comments > raised during the orevious working group last call and reviews have > been correctly addressed. > > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. > > /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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --0016361e8936ec189d0483beb745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
I share your concern regarding applicability of E-LSP in p= acket transport network. Though the document is about the Transport Profile= , references to MPLS-TP as packet transport network technology been changed= recently. Now MPLS-TP is referred as "packet network". It is my = understanding that applicability of MPLS-TP functionality, features and cap= abilities to the packet transport network will be decided later, separately= .
Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 = at 11:59 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [m= ailto:pwe3-bounces@ietf.org] O= n Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11

All,

this is to start a short working group last call on "A Framework
for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the orevious working group last call and reviews have
been correctly addressed.

Please sen comments to the mpls-tp mailing list on April 17th, the
latest.

/Loa
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@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 =A0+46 767 72 92 13
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


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

--0016361e8936ec189d0483beb745-- From gregimirsky@gmail.com Thu Apr 8 12:33:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F043A68F3; Thu, 8 Apr 2010 12:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXZW9BMgOC0p; Thu, 8 Apr 2010 12:33:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8E7133A67E7; Thu, 8 Apr 2010 12:33:32 -0700 (PDT) Received: by gwaa20 with SMTP id a20so1355795gwa.31 for ; Thu, 08 Apr 2010 12:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=VfDPhpt/m4vUh00oI90YPxNi6ri7+ZeewjbwWqQabFA=; b=KT4VH8omm41QOUGLxh1uFq1DL0ciowk9RVUwUtUfJOKEALvqZJ5gwV+PEkxj7wVfAg gGwzfHD+YqeknkEsLlyYpQqsQZWzBb72kUIKZz1YEtovuXZagSPOwv93hLk4XCA1RmD9 j+OeFLFO+KEpI76BCTP2+BiXRu4TjDDY/BTUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ohq8i65JAT6eJauEOerBKIoNy5BKB6aozTWj7MDsW9tICNWqs7fgOdmVCtcIyVTftN E+Zm0qVugRN394234I9L1JRApLRq2ZL/keL7/SZTwDQkbco0DZYgGRItxpS/C35jENqI ou/XE9N2nZMr4JZmbs1ie+aj85cVEVNjQW5r0= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:33:25 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 12:33:25 -0700 Received: by 10.90.18.30 with SMTP id 30mr150478agr.77.1270755205913; Thu, 08 Apr 2010 12:33:25 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=0016361e82caa51dd00483bec02f Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] [mpls] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:33:34 -0000 --0016361e82caa51dd00483bec02f Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, as John mentioned, OAM per CoS for E-LSP was discussed on another thread. I believe that we agreed that OAM SHOULD be per CoS. Right? Regards, Greg On Thu, Apr 8, 2010 at 12:30 PM, Shahram Davari wrote: > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? > > Thanks > SD > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Sharam, > > We have been through this at least twice before. The best way to think > E-LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packet > re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. > > Thanks, > > John > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /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 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016361e82caa51dd00483bec02f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
as John mentioned, OAM per CoS for E-LSP was discussed on an= other thread. I believe that we agreed that OAM SHOULD be per CoS. Right?
Regards,
Greg

On Thu, Apr 8, 201= 0 at 12:30 PM, Shahram Davari <davari@broadcom.com> wrote:
Hi John,

Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?

Thanks
SD

-----Original Message-----
From: John E Drake [mailto:jdrake@jun= iper.net]
Sent: Thursday, April 08, 2010 12:21 PM
To: Shahram Davari; Loa Andersson; mpls= -tp@ietf.org; mpls@ietf.org; MPLS-= TP ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11

Sharam,

We have been through this at least twice before. =A0The best way to think E= -LSPs is that the former EXP bits in the header are part of an extended lab= el. =A0So you effectively have eight parallel LSPs and there is no packet r= e-ordering within each.

Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made.

Thanks,

John

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Shahram Davari
> Sent: Thursday, April 08, 2010 12:00 PM
> To: Loa Andersson; mpls-tp@ietf.or= g; mpls@ietf.org; MPLS-TP ad hoc t= eam;
> pwe3@ietf.org; CCAMP
> Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi Loa,
>
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP.= As
> we know traditional transport layers only have one CoS. However E-LSP = has
> multiple CoS, which can reorder packets (I know that the reorder packe= ts
> belong to different CoS). Additionally the definition of E-LSP OAM and=
> performance and protection and availability, etc will be questionable<= br> > (because of carrying multiple CoS).
>
> Therefore I think E-LSP should not be supported in MPLS-TP or at least=
> should be discouraged.
>
> Regards,
> Shahram
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Loa Andersson
> Sent: Saturday, April 03, 2010 2:31 AM
> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> CCAMP
> Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11
>
> All,
>
> this is to start a short working group last call on "A Framework<= br> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11)= .
>
> Please note that this wg last call is limited to verify that comments<= br> > raised during the orevious working group last call and reviews have > been correctly addressed.
>
> Please sen comments to the mpls-tp mailing list on April 17th, the
> latest.
>
> /Loa
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com=
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@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 =A0 +46 767 72 92 13
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


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

--0016361e82caa51dd00483bec02f-- From david.i.allan@ericsson.com Thu Apr 8 12:45:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE113A6AE4; Thu, 8 Apr 2010 12:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QSibP6E41VQ; Thu, 8 Apr 2010 12:45:33 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A310E28C0DC; Thu, 8 Apr 2010 12:45:28 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o38JnO0T013985; Thu, 8 Apr 2010 14:49:24 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 8 Apr 2010 15:45:21 -0400 From: David Allan I To: Greg Mirsky , Shahram Davari Date: Thu, 8 Apr 2010 15:45:19 -0400 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZw Message-ID: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.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_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , CCAMP , MPLS-TP ad hoc team , "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:45:34 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiat= e a number of L-LSPs, which is a significant amount of state at every hop, = or I can instantiate one E-LSP, which is an N:1 compression in the amount o= f state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was prot= ecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or anothe= r E-LSP, and if they were co-routed, the majority of failure cases (link cu= ts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched = (although there would be 'n' signal fail indications internally to contend = with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP tak= es 'n' times the flows to be instumented like 'n' L-LSPs so what???? I app= reciate that the ability to generate per PHB flows may be undesirable for s= ome, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable bene= fits. The analysis is flawed. my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.= org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport n= etwork. Though the document is about the Transport Profile, references to M= PLS-TP as packet transport network technology been changed recently. Now MP= LS-TP is referred as "packet network". It is my understanding that applicab= ility of MPLS-TP functionality, features and capabilities to the packet tra= nsport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm not quite following this=20 argument....
 
If I have a number of co-routed paths with differe= nt PHBs,=20 I can instantiate a number of L-LSPs, which is a significant amount of stat= e at=20 every hop, or I can instantiate one E-LSP, which is an N:1 compression= in=20 the amount of state in transit nodes.
 
The only wrinkle is all PHBs of an E-LSP fate shar= e. But=20 then if I was protecting the L-LSP or the E-LSP version I'd have= =20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majori= ty of=20 failure cases (link cuts) would result in a loud clang as many L-LSPs = vs.=20 one E-LSP was switched (although there would be 'n' signal fail indications= =20 internally to contend with). Overall, it sounds to me like an E-LSP ma= y be=20 a bit faster there....
 
The actual OAM load to instrument them equally is = the same.=20 If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs=20 so what????  I appreciate that the ability to generate per P= HB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
 
IMO there is no penalty for supporting E-LSPs and = there are=20 measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent:= =20 Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc:= =20 mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org;=20 pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3] short working gr= oup=20 last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability of= =20 E-LSP in packet transport network. Though the document is about the Transpo= rt=20 Profile, references to MPLS-TP as packet transport network technology been= =20 changed recently. Now MPLS-TP is referred as "packet network". It is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harrison= =20 pointed several times that a connection, transport path cannot have multipl= e=20 classes, otherwise it leads to significant increased complexity of OAM, whi= ch=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <davari@broadcom.com> wrot= e:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported in= =20 MPLS-TP. As we know traditional transport layers only have one CoS. Howev= er=20 E-LSP has multiple CoS, which can reorder packets (I know that the reorde= r=20 packets belong to different CoS). Additionally the definition of E-LSP OA= M and=20 performance and protection and availability, etc will be questionable (be= cause=20 of carrying multiple CoS).

Therefore I think E-LSP should not be=20 supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:pwe3-bounces@ietf.org">pwe3-bounces@ietf.org] On Behal= f Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3]= short=20 working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a sho= rt=20 working group last call on "A Framework
for MPLS in Transport Networks= "=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last c= all=20 is limited to verify that comments
raised during the orevious working = group=20 last call and reviews have
been correctly addressed.

Please sen= =20 comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson     &= nbsp;=20                   email: loa.andersson@ericsson.com=
Sr=20 Strategy and Standards Manager            <= A=20 href=3D"mailto:loa@pi.nu">loa@pi.nu
Ericsson Inc     &nb= sp;=20                    phon= e:=20 +46 10 717 52 13
              &nbs= p;=20                     &nb= sp;=20        +46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

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

--_000_60C093A41B5E45409A19D42CF7786DFD4F9953DBF7EUSAACMS0703e_-- From jdrake@juniper.net Thu Apr 8 12:55:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B053A6868; Thu, 8 Apr 2010 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjpIOtQYrqhm; Thu, 8 Apr 2010 12:55:08 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id CD79E3A6945; Thu, 8 Apr 2010 12:55:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS740jjFUlHeQE0nuzDQDPPStBNta54+h@postini.com; Thu, 08 Apr 2010 12:55:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Apr 2010 12:51:32 -0700 From: John E Drake To: David Allan I , Greg Mirsky , Shahram Davari Date: Thu, 8 Apr 2010 12:51:31 -0700 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwAACHmoA= Message-ID: <5E893DB832F57341992548CDBB3331639806CF47E6@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> 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" , team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" , MPLS-TP Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:55:09 -0000 Dave, My only comment is with your last sentence: "The analysis is flawed." To = be clearer, it should be: "The analysis that concludes that E-LSPs are a b= ad idea is flawed." Your analysis seems completely correct. Thanks, John > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > David Allan I > Sent: Thursday, April 08, 2010 12:45 PM > To: Greg Mirsky; Shahram Davari > Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls- > tp@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft= - > ietf-mpls-tp-framework-11 >=20 > I'm not quite following this argument.... >=20 > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. >=20 > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally > to contend with). Overall, it sounds to me like an E-LSP may be a bit > faster there.... >=20 > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I > appreciate that the ability to generate per PHB flows may be undesirable > for some, but that does not make it a bad idea. >=20 > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. >=20 > my 2 cents > D >=20 > ________________________________ >=20 > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Greg Mirsky > Sent: Thursday, April 08, 2010 3:31 PM > To: Shahram Davari > Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft= - > ietf-mpls-tp-framework-11 >=20 >=20 > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references t= o > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. >=20 > Regards, > Greg >=20 >=20 > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: >=20 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS- > TP. As we know traditional transport layers only have one CoS. However E- > LSP has multiple CoS, which can reorder packets (I know that the reorder > packets belong to different CoS). Additionally the definition of E-LSP OA= M > and performance and protection and availability, etc will be questionable > (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at > least should be discouraged. >=20 > Regards, > Shahram >=20 >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that > comments > raised during the orevious working group last call and reviews have > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the > latest. >=20 > /Loa > -- >=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 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From gregimirsky@gmail.com Thu Apr 8 12:57:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30BB928C153; Thu, 8 Apr 2010 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh1P2Lpz0Q6z; Thu, 8 Apr 2010 12:57:19 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 3CFAA3A6945; Thu, 8 Apr 2010 12:57:19 -0700 (PDT) Received: by ywh38 with SMTP id 38so1314362ywh.29 for ; Thu, 08 Apr 2010 12:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=OUQreu4iQPs7vBwfMT3Kw1Z7TY4zY+S3jB2812rhWNM=; b=UbFaBJFjI4VpR6IBQmP66RKkIBqpU7t69n5GqHrCEXivyUPzl4EB3PyGY6cF55ZM/w b/On9Q557cfj91TsCry2uO0ZY/4sZxMbYov/bhnpOoCdet+i6rl+hfGU4XUKvvA/fp9i JmVc0FQWKhqRy9kEqyvQylCeas0yFbamj9zmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cZ6Wn2UkBRxe5oF91y03hits00YnLD84f0aOh+ElJ67mAOoq3yI0jN00xfZDNAG3Uf T9sSDaDNm0ItdoM1EFTjW7GmI6FX72+qBN6hb4mBUahtr6Bdl7xnT047Mg97e3JqS/j8 R6Zth5Yk5vmD5J4Y8gPW1s7Tfz9dHhPsO9IQc= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 12:57:12 -0700 (PDT) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> Date: Thu, 8 Apr 2010 12:57:12 -0700 Received: by 10.91.185.3 with SMTP id m3mr168065agp.79.1270756632816; Thu, 08 Apr 2010 12:57:12 -0700 (PDT) Message-ID: From: Greg Mirsky To: David Allan I Content-Type: multipart/alternative; boundary=0016e6460744b1ef110483bf158f Cc: "mpls@ietf.org" , Shahram Davari , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:57:21 -0000 --0016e6460744b1ef110483bf158f Content-Type: text/plain; charset=ISO-8859-1 Dear David, my understanding of pro-active CV/CC when applied to E-LSP is that all supported CoS will be run at all time regardless whether a particular class ever used. Though that might be taken care of by a intelligent OAM implementation. The protection of N L-LSPs might be done through PST to reduce the bang level. In my view both methods to do DiffServ in MPLS have proven itself. Both have merits and drawbacks. Both are part of MPLS-TP. Will they be both part of packet transport? Regards, Greg On Thu, Apr 8, 2010 at 12:45 PM, David Allan I wrote: > I'm not quite following this argument.... > > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally to > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > there.... > > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? I > appreciate that the ability to generate per PHB flows may be undesirable for > some, but that does not make it a bad idea. > > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. > > my 2 cents > D > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Greg Mirsky > *Sent:* Thursday, April 08, 2010 3:31 PM > *To:* Shahram Davari > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references to > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. > > Regards, > Greg > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > >> Hi Loa, >> >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As >> we know traditional transport layers only have one CoS. However E-LSP has >> multiple CoS, which can reorder packets (I know that the reorder packets >> belong to different CoS). Additionally the definition of E-LSP OAM and >> performance and protection and availability, etc will be questionable >> (because of carrying multiple CoS). >> >> Therefore I think E-LSP should not be supported in MPLS-TP or at least >> should be discouraged. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Saturday, April 03, 2010 2:31 AM >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; >> CCAMP >> Subject: [PWE3] short working group last call on >> draft-ietf-mpls-tp-framework-11 >> >> All, >> >> this is to start a short working group last call on "A Framework >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >> >> Please note that this wg last call is limited to verify that comments >> raised during the orevious working group last call and reviews have >> been correctly addressed. >> >> Please sen comments to the mpls-tp mailing list on April 17th, the >> latest. >> >> /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 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --0016e6460744b1ef110483bf158f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear David,
my understanding of pro-active CV/CC when applied to E-LSP i= s that all supported CoS will be run at all time regardless whether a parti= cular class ever used. Though that might be taken care of by a intelligent = OAM implementation. The protection of N L-LSPs might be done through PST to= reduce the bang level.
In my view both methods to do DiffServ in MPLS have proven itself. Both hav= e merits and drawbacks. Both are part of MPLS-TP. Will they be both part of= packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I <david.i.allan@ericsson.com><= /span> wrote:
I'm not quite following this=20 argument....
=A0
If I have a number of co-routed paths with different PHBs,=20 I can instantiate a number of L-LSPs, which is a significant amount of stat= e at=20 every hop, or I can instantiate=A0one E-LSP, which is an N:1 compression in= =20 the amount of state in transit nodes.
=A0
The only wrinkle is all PHBs of an E-LSP fate share. But=20 then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have=20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, th= e majority of=20 failure cases (link cuts) would result in a loud clang as many L-LSPs=A0vs.= =20 one E-LSP was switched (although there would be 'n' signal fail ind= ications=20 internally to contend with).=A0Overall, it sounds to me like an E-LSP may b= e=20 a bit faster there....
=A0
The actual OAM load to instrument them equally is the same.=20 If an E-LSP takes 'n' times the flows to be instumented like 'n= ' L-LSPs=20 so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
=A0
IMO there is no penalty for supporting E-LSPs and there are=20 measurable benefits. The analysis is flawed.
=A0
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky
Sent:=20 Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc:= =20 mpls@ietf.org; MPLS-= TP ad hoc team; CCAMP; mpls-tp@ietf.org;=20 pwe3@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3] short working group=20 last call on draft-ietf-mpls-tp-framework-11

=
Dear Shahram,
I share your concern regarding applicability of= =20 E-LSP in packet transport network. Though the document is about the Transpo= rt=20 Profile, references to MPLS-TP as packet transport network technology been= =20 changed recently. Now MPLS-TP is referred as "packet network". It= is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harrison= =20 pointed several times that a connection, transport path cannot have multipl= e=20 classes, otherwise it leads to significant increased complexity of OAM, whi= ch=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = <davari@broadcom.com> wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported in= =20 MPLS-TP. As we know traditional transport layers only have one CoS. Howev= er=20 E-LSP has multiple CoS, which can reorder packets (I know that the reorde= r=20 packets belong to different CoS). Additionally the definition of E-LSP OA= M and=20 performance and protection and availability, etc will be questionable (be= cause=20 of carrying multiple CoS).

Therefore I think E-LSP should not be= =20 supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]= On Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad h= oc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short=20 working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a sho= rt=20 working group last call on "A Framework
for MPLS in Transport Net= works"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last c= all=20 is limited to verify that comments
raised during the orevious working = group=20 last call and reviews have
been correctly addressed.

Please sen= =20 comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr=20 Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0+46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/pwe3


= _______________________________________________
mpls=20 mailing list
mpls@i= etf.org
https://www.ietf.org/mailman/listinfo/mpls


--0016e6460744b1ef110483bf158f-- From jdrake@juniper.net Thu Apr 8 12:58:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BBA3A68F3; Thu, 8 Apr 2010 12:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9413GO8kmBU6; Thu, 8 Apr 2010 12:58:17 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id B5C613A698D; Thu, 8 Apr 2010 12:58:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKS741SeVHa53qaHr1ZEXKocUGdAEDmCG5@postini.com; Thu, 08 Apr 2010 12:58:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Apr 2010 12:56:16 -0700 From: John E Drake To: Shahram Davari , Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , MPLS-TP ad hoc team , "pwe3@ietf.org" , CCAMP Date: Thu, 8 Apr 2010 12:56:14 -0700 Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQAAA2Kjg Message-ID: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:58:18 -0000 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Thursday, April 08, 2010 12:30 PM > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP > ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Hi John, >=20 > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP [JD]=20 I think that might be gilding the lily. Since, except for the buffer, queu= ing, and scheduling, the eight are tightly coupled, one CV/CC is probably f= ine. Performance monitoring by PHB is probably a good thing. > and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? >=20 > Thanks > SD >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS- > TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > mpls-tp-framework-11 >=20 > Sharam, >=20 > We have been through this at least twice before. The best way to think E= - > LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packe= t > re-ordering within each. >=20 > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team= ; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. > As > > we know traditional transport layers only have one CoS. However E-LSP > has > > multiple CoS, which can reorder packets (I know that the reorder packet= s > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org= ; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /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 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 From gregimirsky@gmail.com Thu Apr 8 13:09:53 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E743A6A7A; Thu, 8 Apr 2010 13:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUawCYmU+QEy; Thu, 8 Apr 2010 13:09:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9868E3A679C; Thu, 8 Apr 2010 13:09:51 -0700 (PDT) Received: by gyh4 with SMTP id 4so1376226gyh.31 for ; Thu, 08 Apr 2010 13:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=gNen0YeiOfXWMvok2hWTFyO71Ax2b1afONifWG2zA/E=; b=gCWYTUUB7zq0EgMaqpv3TXT4A4r65cjL2zd76BKe6PLWTdKBNhgBApavAOtgh608p5 cENN9w8DVorAMkqh3rNTnq2jI+U5fOEqgsMuS/fPgPU0r+GpZVYAbS6C0qpclf/ZMJRW u/T3bOoWr6Nw74epmaZvmpztI+f4AuG4NCg90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VmnIFCQdDzzYOS6x6qKnEgDsHP7J8pYUe0VQtukg346JHtNM0B1QL+AreYihLLudwP SpPuvvgHnkZXfvhWfXfx6blszTR/ckRnzHkagLb8/Gn1IleiN3IdC2sL6+y+Ku1ajM4j DLaV7sW7MHQyB91/xnIggtaSDYQojjLEmZJO0= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Thu, 8 Apr 2010 13:09:40 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> Date: Thu, 8 Apr 2010 13:09:40 -0700 Received: by 10.90.5.24 with SMTP id 24mr174060age.47.1270757380762; Thu, 08 Apr 2010 13:09:40 -0700 (PDT) Message-ID: From: Greg Mirsky To: John E Drake Content-Type: multipart/alternative; boundary=0016364d283f46ad530483bf4219 Cc: "mpls@ietf.org" , Shahram Davari , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] [mpls] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:09:53 -0000 --0016364d283f46ad530483bf4219 Content-Type: text/plain; charset=ISO-8859-1 Dear John, I think that especially because of all things you've mentioned "... except for the buffer, queuing, and scheduling, ..." even CV/CC will have to be ran per CoS. Otherwise, CV/CC be ignoring PHB. It might be unlikely situation unless operator oversubscribes resources. I'd "be prepared". Regards, Greg On Thu, Apr 8, 2010 at 12:56 PM, John E Drake wrote: > > > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, April 08, 2010 12:30 PM > > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP > > ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi John, > > > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP > [JD] > > I think that might be gilding the lily. Since, except for the buffer, > queuing, and scheduling, the eight are tightly coupled, one CV/CC is > probably fine. Performance monitoring by PHB is probably a good thing. > > > and if any of > > them fail do protection switching for all of them? What will be the > > definition of availability for such E-LSP? > > > > Thanks > > SD > > > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, April 08, 2010 12:21 PM > > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS- > > TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Sharam, > > > > We have been through this at least twice before. The best way to think > E- > > LSPs is that the former EXP bits in the header are part of an extended > > label. So you effectively have eight parallel LSPs and there is no > packet > > re-ordering within each. > > > > Dave said he would mention something about OAM per parallel LSP in the > > framework in response to a last call comment I made. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > > Shahram Davari > > > Sent: Thursday, April 08, 2010 12:00 PM > > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc > team; > > > pwe3@ietf.org; CCAMP > > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > > mpls-tp-framework-11 > > > > > > Hi Loa, > > > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. > > As > > > we know traditional transport layers only have one CoS. However E-LSP > > has > > > multiple CoS, which can reorder packets (I know that the reorder > packets > > > belong to different CoS). Additionally the definition of E-LSP OAM and > > > performance and protection and availability, etc will be questionable > > > (because of carrying multiple CoS). > > > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > > should be discouraged. > > > > > > Regards, > > > Shahram > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of > > > Loa Andersson > > > Sent: Saturday, April 03, 2010 2:31 AM > > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > pwe3@ietf.org; > > > CCAMP > > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > > framework-11 > > > > > > All, > > > > > > this is to start a short working group last call on "A Framework > > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > > > Please note that this wg last call is limited to verify that comments > > > raised during the orevious working group last call and reviews have > > > been correctly addressed. > > > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > > latest. > > > > > > /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 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --0016364d283f46ad530483bf4219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear John,
I think that especially because of all things you've ment= ioned "... except for the buffer, queuing, and scheduling, ..." e= ven CV/CC will have to be ran per CoS. Otherwise, CV/CC be ignoring PHB. It= might be unlikely situation unless operator oversubscribes resources. I= 9;d "be prepared".

Regards,
Greg

On Thu, Apr 8, 2010 = at 12:56 PM, John E Drake <jdrake@juniper.net> wrote:


> -----Original Message-----
> From: Shahram Davari [mailto:da= vari@broadcom.com]
> Sent: Thursday, April 08, 2010 12:30 PM
> To: John E Drake; Loa Andersson; m= pls-tp@ietf.org; mpls@ietf.org; MP= LS-TP
> ad hoc team; pwe3@ietf.org; CCAMP=
> Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi John,
>
> Thanks. Does that mean one needs to run 8 BFDs on that E-LSP
[JD]

I think that might be gilding the lily. =A0Since, except for the buffer, qu= euing, and scheduling, the eight are tightly coupled, one CV/CC is probably= fine. =A0Performance monitoring by PHB is probably a good thing.

> and if any of
> them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP?
>
> Thanks
> SD
>
> -----Original Message-----
> From: John E Drake [mailto:jdrak= e@juniper.net]
> Sent: Thursday, April 08, 2010 12:21 PM
> To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; = MPLS-
> TP ad hoc team; pwe3@ietf.org; CC= AMP
> Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Sharam,
>
> We have been through this at least twice before. =A0The best way to th= ink E-
> LSPs is that the former EXP bits in the header are part of an extended=
> label. =A0So you effectively have eight parallel LSPs and there is no = packet
> re-ordering within each.
>
> Dave said he would mention something about OAM per parallel LSP in the=
> framework in response to a last call comment I made.
>
> Thanks,
>
> John
>
> > -----Original Message-----
> > From: mpls-bounces@ietf.= org [mailto:mpls-bounces@ietf.= org] On Behalf Of
> > Shahram Davari
> > Sent: Thursday, April 08, 2010 12:00 PM
> > To: Loa Andersson; mpls-tp@ie= tf.org; mpls@ietf.org; MPLS-TP ad = hoc team;
> > pwe3@ietf.org; CCAMP
> > Subject: Re: [mpls] [PWE3] short working group last call on draft= -ietf-
> > mpls-tp-framework-11
> >
> > Hi Loa,
> >
> > The draft mentions that both L-LSP and E-LSP are supported in MPL= S-TP.
> As
> > we know traditional transport layers only have one CoS. However E= -LSP
> has
> > multiple CoS, which can reorder packets (I know that the reorder = packets
> > belong to different CoS). Additionally the definition of E-LSP OA= M and
> > performance and protection and availability, etc will be question= able
> > (because of carrying multiple CoS).
> >
> > Therefore I think E-LSP should not be supported in MPLS-TP or at = least
> > should be discouraged.
> >
> > Regards,
> > Shahram
> >
> > -----Original Message-----
> > From: pwe3-bounces@ietf.= org [mailto:pwe3-bounces@ietf.= org] On Behalf Of
> > Loa Andersson
> > Sent: Saturday, April 03, 2010 2:31 AM
> > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> > CCAMP
> > Subject: [PWE3] short working group last call on draft-ietf-mpls-= tp-
> > framework-11
> >
> > All,
> >
> > this is to start a short working group last call on "A Frame= work
> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framewor= k-11).
> >
> > Please note that this wg last call is limited to verify that comm= ents
> > raised during the orevious working group last call and reviews ha= ve
> > been correctly addressed.
> >
> > Please sen comments to the mpls-tp mailing list on April 17th, th= e
> > latest.
> >
> > /Loa
> > --
> >
> >
> > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ema= il: loa.andersson@ericsson.co= m
> > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
> > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p= hone: +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 =A0 +46 767 72 92 13
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www.ietf.org/mailman/listinfo/pwe3
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>

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

--0016364d283f46ad530483bf4219-- From david.i.allan@ericsson.com Thu Apr 8 13:11:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D9B3A6927; Thu, 8 Apr 2010 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ICH420bGoV2; Thu, 8 Apr 2010 13:11:28 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6206D3A697A; Thu, 8 Apr 2010 13:11:28 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o38KFRA4030623; Thu, 8 Apr 2010 15:15:28 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 8 Apr 2010 16:11:22 -0400 From: David Allan I To: Greg Mirsky Date: Thu, 8 Apr 2010 16:11:19 -0400 Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Thread-Index: AcrXVb8ATDKsAoqoQFinAoaIJUcPQAAAM6hw Message-ID: <60C093A41B5E45409A19D42CF7786DFD4F9953DC3B@EUSAACMS0703.eamcs.ericsson.se> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> 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_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , Shahram Davari , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:11:31 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg: yes there is a ying and yang to this. But "a" PST that could stunt double for many L-LSPs would have to be an E-L= SP itself. else an L-LSP matching the highest PHB of the set of L-LSPs carr= ied. The alternative being 'n' PSTs. So you end up with either undifferenti= ated treatment of the original set of L-LSPs or 2x'N' OAM flows no matter h= ow you cut it. .... I agree that for E-LSPs additional intelligence/configuration would be need= ed to only instrument the PHBs that were geninue bearers... Meanwhile, I believe this dialog started because both methods are already i= n packet transport, at least as being specified by this effort. That was be= ing questioned. cheers D ________________________________ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Thursday, April 08, 2010 3:57 PM To: David Allan I Cc: Shahram Davari; mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf= .org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear David, my understanding of pro-active CV/CC when applied to E-LSP is that all supp= orted CoS will be run at all time regardless whether a particular class eve= r used. Though that might be taken care of by a intelligent OAM implementat= ion. The protection of N L-LSPs might be done through PST to reduce the ban= g level. In my view both methods to do DiffServ in MPLS have proven itself. Both hav= e merits and drawbacks. Both are part of MPLS-TP. Will they be both part of= packet transport? Regards, Greg On Thu, Apr 8, 2010 at 12:45 PM, David Allan I > wrote: I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiat= e a number of L-LSPs, which is a significant amount of state at every hop, = or I can instantiate one E-LSP, which is an N:1 compression in the amount o= f state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was prot= ecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or anothe= r E-LSP, and if they were co-routed, the majority of failure cases (link cu= ts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched = (although there would be 'n' signal fail indications internally to contend = with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP tak= es 'n' times the flows to be instumented like 'n' L-LSPs so what???? I app= reciate that the ability to generate per PHB flows may be undesirable for s= ome, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable bene= fits. The analysis is flawed. my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-t= p@ietf.org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-i= etf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport n= etwork. Though the document is about the Transport Profile, references to M= PLS-TP as packet transport network technology been changed recently. Now MP= LS-TP is referred as "packet network". It is my understanding that applicab= ility of MPLS-TP functionality, features and capabilities to the packet tra= nsport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed severa= l times that a connection, transport path cannot have multiple classes, oth= erwise it leads to significant increased complexity of OAM, which has to be= (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari > wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As w= e know traditional transport layers only have one CoS. However E-LSP has mu= ltiple CoS, which can reorder packets (I know that the reorder packets belo= ng to different CoS). Additionally the definition of E-LSP OAM and performa= nce and protection and availability, etc will be questionable (because of c= arrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least shou= ld be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-boun= ces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framewo= rk-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Greg:
 
yes there is a ying and yang to this.
 
But "a" PST that could stunt double for many L-LSP= s would=20 have to be an E-LSP itself. else an L-LSP matching the highest PHB of the s= et of=20 L-LSPs carried. The alternative being 'n' PSTs. So you end up wit= h=20 either undifferentiated treatment of the original set of L-LSPs or 2x'N' OA= M=20 flows no matter how you cut it. ....
 
I agree that for E-LSPs additional=20 intelligence/configuration would be needed to only instrument the PHBs that= were=20 geninue bearers...
 
Meanwhile, I believe this dialog started because b= oth=20 methods are already in packet transport, at least as being specified by thi= s=20 effort. That was being questioned.
 
cheers
D

From: Greg Mirsky [mailto:gregimirsky@g= mail.com]=20
Sent: Thursday, April 08, 2010 3:57 PM
To: David Allan= =20 I
Cc: Shahram Davari; mpls@ietf.org; MPLS-TP ad hoc team; CCAMP;= =20 mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3= ]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear David,
my understanding of pro-active CV/CC when applied= to=20 E-LSP is that all supported CoS will be run at all time regardless whether = a=20 particular class ever used. Though that might be taken care of by a intelli= gent=20 OAM implementation. The protection of N L-LSPs might be done through PST to= =20 reduce the bang level.
In my view both methods to do DiffServ in MPLS ha= ve=20 proven itself. Both have merits and drawbacks. Both are part of MPLS-TP. Wi= ll=20 they be both part of packet transport?

Regards,
Greg

On Thu, Apr 8, 2010 at 12:45 PM, David Allan I <david.i.allan@ericsson.com&g= t;=20 wrote:
I'm not=20 quite following this argument....
 
If I have=20 a number of co-routed paths with different PHBs, I can instantiate a numb= er of=20 L-LSPs, which is a significant amount of state at every hop, or I can=20 instantiate one E-LSP, which is an N:1 compression in the amount of = state=20 in transit nodes.
 
The only=20 wrinkle is all PHBs of an E-LSP fate share. But then if I was=20 protecting the L-LSP or the E-LSP version I'd have another 'n'= =20 L-LSPs or another E-LSP, and if they were co-routed, the majority of fail= ure=20 cases (link cuts) would result in a loud clang as many L-LSPs vs. on= e=20 E-LSP was switched (although there would be 'n' signal fail indications=20 internally to contend with). Overall, it sounds to me like an E-LSP = may=20 be a bit faster there....
 
The actual=20 OAM load to instrument them equally is the same. If an E-LSP takes 'n' ti= mes=20 the flows to be instumented like 'n' L-LSPs so what????  I= =20 appreciate that the ability to generate per PHB flows may be undesirable = for=20 some, but that does not make it a bad idea.
 
IMO there=20 is no penalty for supporting E-LSPs and there are measurable benefits. Th= e=20 analysis is flawed.
 
my 2=20 cents
D

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf= .org]=20 On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 = 3:31=20 PM
To: Shahram Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org
Sub= ject:=20 Re: [CCAMP] [mpls] [PWE3] short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability = of=20 E-LSP in packet transport network. Though the document is about the Trans= port=20 Profile, references to MPLS-TP as packet transport network technology bee= n=20 changed recently. Now MPLS-TP is referred as "packet network". It is my=20 understanding that applicability of MPLS-TP functionality, features and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harris= on=20 pointed several times that a connection, transport path cannot have multi= ple=20 classes, otherwise it leads to significant increased complexity of OAM, w= hich=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = <davari@broadcom.com> wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported = in=20 MPLS-TP. As we know traditional transport layers only have one CoS. How= ever=20 E-LSP has multiple CoS, which can reorder packets (I know that the reor= der=20 packets belong to different CoS). Additionally the definition of E-LSP = OAM=20 and performance and protection and availability, etc will be questionab= le=20 (because of carrying multiple CoS).

Therefore I think E-LSP shou= ld=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf= .org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa AnderssonSent:=20 Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;=20 CCAMP
Subject: [PWE3] short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a s= hort=20 working group last call on "A Framework
for MPLS in Transport Networ= ks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= call=20 is limited to verify that comments
raised during the orevious workin= g=20 group last call and reviews have
been correctly addressed.

Pl= ease=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson    = =20                     e= mail:=20 loa.andersson@ericsson.com
Sr Strategy and Stand= ards=20 Manager            loa@pi.nu
Ericsson Inc       &nbs= p;=20                  phone: +4= 6 10=20 717 52 13
                &n= bsp;=20                     &= nbsp;=20      +46 767 72 92=20 13
_______________________________________________
pwe3 mailing=20 list
pwe3@ietf.org<= /A>
https://www.ietf.org/mailman/listinfo/pwe3

<= BR>
_______________________________________________
mpls=20 mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


--_000_60C093A41B5E45409A19D42CF7786DFD4F9953DC3BEUSAACMS0703e_-- From gregimirsky@gmail.com Thu Apr 8 18:38:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3B43A67C2; Thu, 8 Apr 2010 18:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hwcAhCtTnkW; Thu, 8 Apr 2010 18:38:26 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id D01043A659C; Thu, 8 Apr 2010 18:38:25 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so957084qwb.31 for ; Thu, 08 Apr 2010 18:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=J/swuOVojHLOLn5Pyzu/RSiwCjMaSXlN99ayrFLf7XM=; b=UaoHqsI7em5e76MPrVTxz4dp49SMDsIAJLhbm/QWKtlmwFaH8pxYlkf4Dg8jBDhcT1 2CdarROpSD5v8n0yRuWZqHrMIJlgySQ/HmGuH/4NVjuzoYdaJSJHYhDJ034fmGJCoo0p SKnAn4/DY6i7vCxSJPTlKbgGNqYInjHGbzzNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fS3lnnn9TfO8hzvj7DutbKgcDq4tQR/w+7wXOo7S8IBktieBjj0evnggHV84s1VD+8 QnrvkJo/9f1pmw/oWA7I3qNldMAMXyn468l/HpteVsCs6fb0V/Um8QP73akOEEQxYYBS N8Sq2T5bm/VHcUyy+yOzyvfFfE+VgHHavewaw= MIME-Version: 1.0 Received: by 10.224.28.129 with HTTP; Thu, 8 Apr 2010 18:38:19 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 8 Apr 2010 18:38:19 -0700 Received: by 10.224.49.77 with SMTP id u13mr372542qaf.363.1270777099528; Thu, 08 Apr 2010 18:38:19 -0700 (PDT) Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=001485e7c9469b2afe0483c3d9da Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] [mpls] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 01:38:27 -0000 --001485e7c9469b2afe0483c3d9da Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, I agree that defining criteria for E-LSP availability as function of per-CoS availability is not a trivial task. I would say that an operator should be given flexibility to weight differently availability of individual CoS of a particular E-LSP (or that could be per specified group, domain). That is implementation detail, but in a PM document we might say that it is a function of per-CoS measured availabilities. Regards, Greg On Thu, Apr 8, 2010 at 12:30 PM, Shahram Davari wrote: > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of > them fail do protection switching for all of them? What will be the > definition of availability for such E-LSP? > > Thanks > SD > > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Thursday, April 08, 2010 12:21 PM > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: RE: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Sharam, > > We have been through this at least twice before. The best way to think > E-LSPs is that the former EXP bits in the header are part of an extended > label. So you effectively have eight parallel LSPs and there is no packet > re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in the > framework in response to a last call comment I made. > > Thanks, > > John > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /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 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --001485e7c9469b2afe0483c3d9da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
I agree that defining criteria for E-LSP availability as f= unction of per-CoS availability is not a trivial task. I would say that an = operator should be given flexibility to weight differently availability of = individual CoS of a particular E-LSP (or that could be per specified group,= domain). That is implementation detail, but in a PM document we might say = that it is a function of per-CoS measured availabilities.

Regards,
Greg

On Thu, Apr 8, 2010 = at 12:30 PM, Shahram Davari <davari@broadcom.com> wrote:
Hi John,

Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if any of = them fail do protection switching for all of them? What will be the definit= ion of availability for such E-LSP?

Thanks
SD

-----Original Message-----
From: John E Drake [mailto:jdrake@jun= iper.net]
Sent: Thursday, April 08, 2010 12:21 PM
To: Shahram Davari; Loa Andersson; mpls= -tp@ietf.org; mpls@ietf.org; MPLS-= TP ad hoc team; pwe3@ietf.org; CCAMP Subject: RE: [mpls] [PWE3] short working group last call on draft-ietf-mpls= -tp-framework-11

Sharam,

We have been through this at least twice before. =A0The best way to think E= -LSPs is that the former EXP bits in the header are part of an extended lab= el. =A0So you effectively have eight parallel LSPs and there is no packet r= e-ordering within each.

Dave said he would mention something about OAM per parallel LSP in the fram= ework in response to a last call comment I made.

Thanks,

John

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Shahram Davari
> Sent: Thursday, April 08, 2010 12:00 PM
> To: Loa Andersson; mpls-tp@ietf.or= g; mpls@ietf.org; MPLS-TP ad hoc t= eam;
> pwe3@ietf.org; CCAMP
> Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf= -
> mpls-tp-framework-11
>
> Hi Loa,
>
> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP.= As
> we know traditional transport layers only have one CoS. However E-LSP = has
> multiple CoS, which can reorder packets (I know that the reorder packe= ts
> belong to different CoS). Additionally the definition of E-LSP OAM and=
> performance and protection and availability, etc will be questionable<= br> > (because of carrying multiple CoS).
>
> Therefore I think E-LSP should not be supported in MPLS-TP or at least=
> should be discouraged.
>
> Regards,
> Shahram
>
> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Loa Andersson
> Sent: Saturday, April 03, 2010 2:31 AM
> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org;
> CCAMP
> Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > framework-11
>
> All,
>
> this is to start a short working group last call on "A Framework<= br> > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11)= .
>
> Please note that this wg last call is limited to verify that comments<= br> > raised during the orevious working group last call and reviews have > been correctly addressed.
>
> Please sen comments to the mpls-tp mailing list on April 17th, the
> latest.
>
> /Loa
> --
>
>
> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: <= a href=3D"mailto:loa.andersson@ericsson.com">loa.andersson@ericsson.com=
> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@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 =A0 +46 767 72 92 13
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


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

--001485e7c9469b2afe0483c3d9da-- From curtis@occnc.com Thu Apr 8 21:18:48 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964283A67C1; Thu, 8 Apr 2010 21:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3WeiCr+fHHj; Thu, 8 Apr 2010 21:18:46 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 4D18828C0FE; Thu, 8 Apr 2010 21:18:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394ISEo090151; Fri, 9 Apr 2010 00:18:28 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090418.o394ISEo090151@harbor.orleans.occnc.com> To: John E Drake From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:20:36 PDT." <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> Date: Fri, 09 Apr 2010 00:18:28 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , Shahram Davari , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:18:48 -0000 In message <5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net> John E Drake writes: > > Sharam, > > We have been through this at least twice before. The best way to think E-LSPs is that the former EXP bits in the header are part of an extended label. So you effectively have eight parallel LSPs and there is no packet re-ordering within each. > > Dave said he would mention something about OAM per parallel LSP in > the framework in response to a last call comment I made. > > Thanks, > > John John, Anyone using AF service would be very mad at you if you reordered based on TC bits aka EXP. Groups of TC values remain ordered. For AF it is a group of 3. For the old IPprec (CS service) it is 8 discrete PHB and each remains ordered but the higher priorities can get queued first. But otherwise I agree. QoS is important. Curtis > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Shahram Davari > > Sent: Thursday, April 08, 2010 12:00 PM > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; > > pwe3@ietf.org; CCAMP > > Subject: Re: [mpls] [PWE3] short working group last call on draft-ietf- > > mpls-tp-framework-11 > > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on draft-ietf-mpls-tp- > > framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /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 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From curtis@occnc.com Thu Apr 8 21:30:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B8728C10F; Thu, 8 Apr 2010 21:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJHobEDn0ddi; Thu, 8 Apr 2010 21:30:16 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 03BA028C0FD; Thu, 8 Apr 2010 21:30:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394U91l090288; Fri, 9 Apr 2010 00:30:09 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090430.o394U91l090288@harbor.orleans.occnc.com> To: "Shahram Davari" From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:30:03 PDT." <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 09 Apr 2010 00:30:09 -0400 Sender: curtis@occnc.com Cc: MPLS-TP ad hoc team , "mpls@ietf.org" , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:30:17 -0000 In message <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> "Shahram Davari" writes: > > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > any of them fail do protection switching for all of them? What will be > the definition of availability for such E-LSP? > > Thanks > SD If there were multiple priorities on an LSP the OAM should be at a high priority. For example for CS service (the old IP prec) CS6 is normally used for control traffic. If OAM failed for CS6 the link is down. If OAM fails for CS0 the link may just be oversubscribed and contested but CS0 is defined as the best effort (BE) service. A provider may choose to do this. For example, if VOIP ran at CS4 and worked fine and web and email was runnig on CS0, phone would work and web would be slow. If a natural disaster took out 3/4 of the network capacity, then having working phone and slow web and maybe unworkable web streaming video might be better than prohibiting oversubscription and having no service at all. Curtis From curtis@occnc.com Thu Apr 8 21:44:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED953A692C for ; Thu, 8 Apr 2010 21:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrg9aa8Ypxui for ; Thu, 8 Apr 2010 21:44:46 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id E3DA13A67BD for ; Thu, 8 Apr 2010 21:44:45 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o394ifjd090514; Fri, 9 Apr 2010 00:44:41 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004090444.o394ifjd090514@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Thu, 08 Apr 2010 12:30:59 PDT." Date: Fri, 09 Apr 2010 00:44:41 -0400 Sender: curtis@occnc.com Cc: "mpls@ietf.org" , Shahram Davari , MPLS-TP ad hoc team , CCAMP , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 04:44:47 -0000 In message Greg Mirsky writes: > > > Dear Shahram, > > I share your concern regarding applicability of E-LSP in packet > transport network. Though the document is about the Transport Profile, > references to MPLS-TP as packet transport network technology been > changed recently. Now MPLS-TP is referred as "packet network". It is > my understanding that applicability of MPLS-TP functionality, features > and capabilities to the packet transport network will be decided > later, separately. Regarding classes of service in the > transport. Neil Harrison pointed several times that a connection, > transport path cannot have multiple classes, otherwise it leads to > significant increased complexity of OAM, which has to be (SHOULD) per > Class of Service per E-LSP. > > Regards, > Greg Greg, Reality check! MPLS-TP needs to: Provide an ability to deliver a service that has the characteristis of a transport network should anyone decide to use it that way. Also provide a solution that has certain important characteristis of a transport network but eliminates the characteristis of a transport network that make it not cost effective. Among the things that need to go is a hard guarentee on bandwidth for every service, including the lowest priority services. Otherwise we might as well just use circuits or allocate time slots to fixed sized MPLS packets. Curtis > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: > > > Hi Loa, > > > > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As > > we know traditional transport layers only have one CoS. However E-LSP has > > multiple CoS, which can reorder packets (I know that the reorder packets > > belong to different CoS). Additionally the definition of E-LSP OAM and > > performance and protection and availability, etc will be questionable > > (because of carrying multiple CoS). > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at least > > should be discouraged. > > > > Regards, > > Shahram > > > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Loa Andersson > > Sent: Saturday, April 03, 2010 2:31 AM > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > > CCAMP > > Subject: [PWE3] short working group last call on > > draft-ietf-mpls-tp-framework-11 > > > > All, > > > > this is to start a short working group last call on "A Framework > > for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > Please note that this wg last call is limited to verify that comments > > raised during the orevious working group last call and reviews have > > been correctly addressed. > > > > Please sen comments to the mpls-tp mailing list on April 17th, the > > latest. > > > > /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 From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:20:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DB13A68F3; Fri, 9 Apr 2010 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.915 X-Spam-Level: X-Spam-Status: No, score=-4.915 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGAaZOUhUC1G; Fri, 9 Apr 2010 00:20:56 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 099213A687E; Fri, 9 Apr 2010 00:20:55 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397KUpD011011; Fri, 9 Apr 2010 09:20:45 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:20:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:24:25 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAIPh/OA= References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> From: "BUSI ITALO" To: "Shahram Davari" , "Loa Andersson" , , , "MPLS-TP ad hoc team" , , "CCAMP" X-OriginalArrivalTime: 09 Apr 2010 07:20:44.0669 (UTC) FILETIME=[2B29C2D0:01CAD7B5] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:20:59 -0000 Shahram, > As we know traditional transport layers only have=20 > one CoS. This is no more the case after Ethernet transport layer has been = developed. > Additionally the definition of E-LSP OAM and=20 > performance and protection and availability, etc will be=20 > questionable (because of carrying multiple CoS). I agree that performance monitoring for multi-CoS connections (e.g., = E-LSP) is not trivial. We have exactly the same issue with Ethernet = performance monitoring. In principle I think that a solution can be defined but I am spending = too much time on mpls-tp standardization so I had not time to monitor = the status of this work within Q14/15. I do not see any issue with fault monitoring of multi-CoS connections as = faults are not per-CoS but per-connection. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Shahram Davari > Sent: gioved=EC 8 aprile 2010 21.00 > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP=20 > ad hoc team; pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on=20 > draft-ietf-mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in=20 > MPLS-TP. As we know traditional transport layers only have=20 > one CoS. However E-LSP has multiple CoS, which can reorder=20 > packets (I know that the reorder packets belong to different=20 > CoS). Additionally the definition of E-LSP OAM and=20 > performance and protection and availability, etc will be=20 > questionable (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or=20 > at least should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on=20 > draft-ietf-mpls-tp-framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A=20 > Framework for MPLS in Transport Networks"=20 > (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that=20 > comments raised during the orevious working group last call=20 > and reviews have been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April=20 > 17th, the latest. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:24:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF12E3A68D4; Fri, 9 Apr 2010 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSs65yjvXRn8; Fri, 9 Apr 2010 00:24:42 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 732083A687E; Fri, 9 Apr 2010 00:24:41 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397OR1I013143; Fri, 9 Apr 2010 09:24:32 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:24:31 +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_01CAD7B5.B219F6C3" Date: Fri, 9 Apr 2010 09:28:11 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 thread-index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwABjlfWA= References: <4BB70AE7.1020605@pi.nu><2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> From: "BUSI ITALO" To: "David Allan I" , "Greg Mirsky" , "Shahram Davari" X-OriginalArrivalTime: 09 Apr 2010 07:24:31.0542 (UTC) FILETIME=[B263D560:01CAD7B5] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:24:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD7B5.B219F6C3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that running OAM flows per-PHB, while very much appropriate for = PM tools (as already documented in the OAM frameworkd draft), is = actually an overdesign for FM tools. =20 Misconnections and failures are per-LSP and not per-PHB. =20 Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of David Allan I Sent: gioved=EC 8 aprile 2010 21.45 To: Greg Mirsky; Shahram Davari Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; = mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last callon = draft-ietf-mpls-tp-framework-11 =09 =09 I'm not quite following this argument.... =20 If I have a number of co-routed paths with different PHBs, I can = instantiate a number of L-LSPs, which is a significant amount of state = at every hop, or I can instantiate one E-LSP, which is an N:1 = compression in the amount of state in transit nodes. =20 The only wrinkle is all PHBs of an E-LSP fate share. But then if I was = protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or = another E-LSP, and if they were co-routed, the majority of failure cases = (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP = was switched (although there would be 'n' signal fail indications = internally to contend with). Overall, it sounds to me like an E-LSP may = be a bit faster there.... =20 The actual OAM load to instrument them equally is the same. If an E-LSP = takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I appreciate that the ability to generate per PHB flows may be = undesirable for some, but that does not make it a bad idea. =20 IMO there is no penalty for supporting E-LSPs and there are measurable = benefits. The analysis is flawed. =20 my 2 cents D ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; = pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on = draft-ietf-mpls-tp-framework-11 =09 =09 Dear Shahram, I share your concern regarding applicability of E-LSP in packet = transport network. Though the document is about the Transport Profile, = references to MPLS-TP as packet transport network technology been = changed recently. Now MPLS-TP is referred as "packet network". It is my = understanding that applicability of MPLS-TP functionality, features and = capabilities to the packet transport network will be decided later, = separately. Regarding classes of service in the transport. Neil Harrison pointed = several times that a connection, transport path cannot have multiple = classes, otherwise it leads to significant increased complexity of OAM, = which has to be (SHOULD) per Class of Service per E-LSP. =09 Regards, Greg =09 =09 On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari = wrote: =09 Hi Loa, =09 The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. = As we know traditional transport layers only have one CoS. However E-LSP = has multiple CoS, which can reorder packets (I know that the reorder = packets belong to different CoS). Additionally the definition of E-LSP = OAM and performance and protection and availability, etc will be = questionable (because of carrying multiple CoS). =09 Therefore I think E-LSP should not be supported in MPLS-TP or at least = should be discouraged. =09 Regards, Shahram =09 -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf = Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; = pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on = draft-ietf-mpls-tp-framework-11 =09 All, =09 this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). =09 Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. =09 Please sen comments to the mpls-tp mailing list on April 17th, the latest. =09 /Loa -- =09 =09 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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 =09 =09 =09 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =09 ------_=_NextPart_001_01CAD7B5.B219F6C3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think that running OAM flows per-PHB, while = very much=20 appropriate for PM tools (as already documented in the OAM frameworkd = draft), is=20 actually an overdesign for FM tools.
 
Misconnections and failures are per-LSP and not = per-PHB.
 
Italo

P.S. Please note my new email address,=20 Italo.Busi@alcatel-lucent.com, effective since 1 November = 2009.

 

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of David Allan=20 I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg = Mirsky;=20 Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc = team;=20 pwe3@ietf.org; mpls-tp@ietf.org
Subject: Re: [CCAMP] [mpls] = [PWE3]=20 short working group last callon=20 draft-ietf-mpls-tp-framework-11

I'm not quite following this=20 argument....
 
If I have a number of co-routed paths with = different=20 PHBs, I can instantiate a number of L-LSPs, which is a significant = amount of=20 state at every hop, or I can instantiate one E-LSP, which is an = N:1=20 compression in the amount of state in transit = nodes.
 
The only wrinkle is all PHBs of an E-LSP fate = share. But=20 then if I was protecting the L-LSP or the E-LSP version I'd = have=20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, the = majority=20 of failure cases (link cuts) would result in a loud clang as many=20 L-LSPs vs. one E-LSP was switched (although there would be 'n' = signal=20 fail indications internally to contend with). Overall, it sounds = to me=20 like an E-LSP may be a bit faster there....
 
The actual OAM load to instrument them = equally is the=20 same. If an E-LSP takes 'n' times the flows to be instumented like 'n' = L-LSPs=20 so what????  I appreciate that the ability to generate = per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
 
IMO there is no penalty for supporting E-LSPs = and there=20 are measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: = Shahram=20 Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] = [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding = applicability of=20 E-LSP in packet transport network. Though the document is about the = Transport=20 Profile, references to MPLS-TP as packet transport network technology = been=20 changed recently. Now MPLS-TP is referred as "packet network". It is = my=20 understanding that applicability of MPLS-TP functionality, features = and=20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil = Harrison=20 pointed several times that a connection, transport path cannot have = multiple=20 classes, otherwise it leads to significant increased complexity of = OAM, which=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram = Davari <davari@broadcom.com> = wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are = supported in=20 MPLS-TP. As we know traditional transport layers only have one CoS. = However=20 E-LSP has multiple CoS, which can reorder packets (I know that the = reorder=20 packets belong to different CoS). Additionally the definition of = E-LSP OAM=20 and performance and protection and availability, etc will be = questionable=20 (because of carrying multiple CoS).

Therefore I think E-LSP = should=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org = [mailto:pwe3-bounces@ietf.org] On = Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc = team; pwe3@ietf.org; CCAMP
Subject: = [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start = a short=20 working group last call on "A Framework
for MPLS in Transport = Networks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg = last call=20 is limited to verify that comments
raised during the orevious = working=20 group last call and reviews have
been correctly = addressed.

Please=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson   =  =20                   =   email:=20 loa.andersson@ericsson.com=
Sr=20 Strategy and Standards Manager           =  loa@pi.nu
Ericsson Inc   =    =20                   =  phone:=20 +46 10 717 52 13
              =  =20                   =    =20        +46 767 72 92=20 13
_______________________________________________
pwe3 = mailing=20 list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

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

------_=_NextPart_001_01CAD7B5.B219F6C3-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:33:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5ED3A69BE; Fri, 9 Apr 2010 00:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb2faq3ps8be; Fri, 9 Apr 2010 00:33:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 87F9D3A696A; Fri, 9 Apr 2010 00:33:35 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397Wsgl016014; Fri, 9 Apr 2010 09:33:23 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:33:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:36:47 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B2353@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAGqaWbAAAG/tQAAA2KjgABiYjaA= References: <4BB70AE7.1020605@pi.nu><2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com><5E893DB832F57341992548CDBB3331639806CF478E@EMBX01-HQ.jnpr.net><2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <5E893DB832F57341992548CDBB3331639806CF47F5@EMBX01-HQ.jnpr.net> From: "BUSI ITALO" To: "John E Drake" , "Shahram Davari" , "Loa Andersson" , , , "MPLS-TP ad hoc team" , , "CCAMP" X-OriginalArrivalTime: 09 Apr 2010 07:33:07.0589 (UTC) FILETIME=[E5FA5B50:01CAD7B6] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:33:38 -0000 > [JD]=20 >=20 > I think that might be gilding the lily. Since, except for=20 > the buffer, queuing, and scheduling, the eight are tightly=20 > coupled, one CV/CC is probably fine. Performance monitoring=20 > by PHB is probably a good thing. I cannot agree more. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of John E Drake > Sent: gioved=EC 8 aprile 2010 21.56 > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org;=20 > mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last=20 > call on draft-ietf-mpls-tp-framework-11 >=20 >=20 >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Thursday, April 08, 2010 12:30 PM > > To: John E Drake; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > > MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on=20 > > draft-ietf- > > mpls-tp-framework-11 > >=20 > > Hi John, > >=20 > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP > [JD]=20 >=20 > I think that might be gilding the lily. Since, except for=20 > the buffer, queuing, and scheduling, the eight are tightly=20 > coupled, one CV/CC is probably fine. Performance monitoring=20 > by PHB is probably a good thing. >=20 > > and if any of > > them fail do protection switching for all of them? What will be the=20 > > definition of availability for such E-LSP? > >=20 > > Thanks > > SD > >=20 > > -----Original Message----- > > From: John E Drake [mailto:jdrake@juniper.net] > > Sent: Thursday, April 08, 2010 12:21 PM > > To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > > MPLS- TP ad hoc team; pwe3@ietf.org; CCAMP > > Subject: RE: [mpls] [PWE3] short working group last call on=20 > > draft-ietf- > > mpls-tp-framework-11 > >=20 > > Sharam, > >=20 > > We have been through this at least twice before. The best way to=20 > > think E- LSPs is that the former EXP bits in the header are=20 > part of an=20 > > extended label. So you effectively have eight parallel=20 > LSPs and there=20 > > is no packet re-ordering within each. > >=20 > > Dave said he would mention something about OAM per parallel=20 > LSP in the=20 > > framework in response to a last call comment I made. > >=20 > > Thanks, > >=20 > > John > >=20 > > > -----Original Message----- > > > From: mpls-bounces@ietf.org=20 > [mailto:mpls-bounces@ietf.org] On Behalf=20 > > > Of Shahram Davari > > > Sent: Thursday, April 08, 2010 12:00 PM > > > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org;=20 > MPLS-TP ad hoc=20 > > > team; pwe3@ietf.org; CCAMP > > > Subject: Re: [mpls] [PWE3] short working group last call on=20 > > > draft-ietf- > > > mpls-tp-framework-11 > > > > > > Hi Loa, > > > > > > The draft mentions that both L-LSP and E-LSP are=20 > supported in MPLS-TP. > > As > > > we know traditional transport layers only have one CoS. However=20 > > > E-LSP > > has > > > multiple CoS, which can reorder packets (I know that the reorder=20 > > > packets belong to different CoS). Additionally the definition of=20 > > > E-LSP OAM and performance and protection and=20 > availability, etc will=20 > > > be questionable (because of carrying multiple CoS). > > > > > > Therefore I think E-LSP should not be supported in MPLS-TP or at=20 > > > least should be discouraged. > > > > > > Regards, > > > Shahram > > > > > > -----Original Message----- > > > From: pwe3-bounces@ietf.org=20 > [mailto:pwe3-bounces@ietf.org] On Behalf=20 > > > Of Loa Andersson > > > Sent: Saturday, April 03, 2010 2:31 AM > > > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > > > pwe3@ietf.org; CCAMP > > > Subject: [PWE3] short working group last call on=20 > draft-ietf-mpls-tp- > > > framework-11 > > > > > > All, > > > > > > this is to start a short working group last call on "A=20 > Framework for=20 > > > MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > > > > > > Please note that this wg last call is limited to verify that=20 > > > comments raised during the orevious working group last call and=20 > > > reviews have been correctly addressed. > > > > > > Please sen comments to the mpls-tp mailing list on April=20 > 17th, the=20 > > > latest. > > > > > > /Loa > > > -- > > > > > > > > > Loa Andersson email:=20 > 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 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From gregimirsky@gmail.com Fri Apr 9 00:34:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677EA3A696A; Fri, 9 Apr 2010 00:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfshHehyLqmh; Fri, 9 Apr 2010 00:34:06 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id E6BD628B56A; Fri, 9 Apr 2010 00:34:03 -0700 (PDT) Received: by yxe9 with SMTP id 9so1669502yxe.29 for ; Fri, 09 Apr 2010 00:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=6R+xw0B9ZEuTGaNusYdM/0yiA2JLNqVfG6D6FBcMTUA=; b=XZsE+qDgCkO/wUgt57hQ5BxZJmFTqagjqXuFoCWxh621t3cyO3Mlpex5LMeyyh2Z2P cCw3FlGU861RK1jz5wAIC5YHevpP5QfE58/sL7XrqugRal/oIfuN2M7AAB416d490jac 4qp4xY/8tj4bRVPlusMRQC81pb8Rnkd+jxw4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MSxm5eft+U/kFl/XvH2ff66nnIBd59nbGUaKaC5QxmBGQw35gdsKt1gsT0JONiJ8TG KEW0UzcCyejm9Uz9fxp5Vtc+qI2OAF5kA2lNDzPf4PTgEstsBh8488+NMEGjonse+tnU cONvqUs+E4IxqXxI3Cc8aHdBfBQTPhb8OyGnU= MIME-Version: 1.0 Received: by 10.90.55.3 with HTTP; Fri, 9 Apr 2010 00:33:56 -0700 (PDT) In-Reply-To: <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> <6FD21B53861BF44AA90A288402036AB4030B2346@FRVELSMBS21.ad2.ad.alcatel.com> Date: Fri, 9 Apr 2010 00:33:56 -0700 Received: by 10.91.20.23 with SMTP id x23mr507778agi.83.1270798436640; Fri, 09 Apr 2010 00:33:56 -0700 (PDT) Message-ID: From: Greg Mirsky To: BUSI ITALO Content-Type: multipart/alternative; boundary=0016e640918a65a9f00483c8d1cb Cc: mpls@ietf.org, Shahram Davari , MPLS-TP ad hoc team , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:34:07 -0000 --0016e640918a65a9f00483c8d1cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo, if we consider Link Bundle (RFC 4201) then it is possible that some CoS flows are being mapped to a different component links. In this case per Co= S FM is quite necessary. Regards, Greg On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO wrote: > I think that running OAM flows per-PHB, while very much appropriate for > PM tools (as already documented in the OAM frameworkd draft), is actually= an > overdesign for FM tools. > > Misconnections and failures are per-LSP and not per-PHB. > > Italo > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > effective since 1 November 2009. > > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *David Allan I > *Sent:* gioved=EC 8 aprile 2010 21.45 > *To:* Greg Mirsky; Shahram Davari > *Cc:* mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; > mpls-tp@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last callon > draft-ietf-mpls-tp-framework-11 > > I'm not quite following this argument.... > > If I have a number of co-routed paths with different PHBs, I can > instantiate a number of L-LSPs, which is a significant amount of state at > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > the amount of state in transit nodes. > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > another E-LSP, and if they were co-routed, the majority of failure cases > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > switched (although there would be 'n' signal fail indications internally = to > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > there.... > > The actual OAM load to instrument them equally is the same. If an E-LSP > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = I > appreciate that the ability to generate per PHB flows may be undesirable = for > some, but that does not make it a bad idea. > > IMO there is no penalty for supporting E-LSPs and there are measurable > benefits. The analysis is flawed. > > my 2 cents > D > > ------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *Greg Mirsky > *Sent:* Thursday, April 08, 2010 3:31 PM > *To:* Shahram Davari > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > pwe3@ietf.org > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 > > Dear Shahram, > I share your concern regarding applicability of E-LSP in packet transport > network. Though the document is about the Transport Profile, references t= o > MPLS-TP as packet transport network technology been changed recently. Now > MPLS-TP is referred as "packet network". It is my understanding that > applicability of MPLS-TP functionality, features and capabilities to the > packet transport network will be decided later, separately. > Regarding classes of service in the transport. Neil Harrison pointed > several times that a connection, transport path cannot have multiple > classes, otherwise it leads to significant increased complexity of OAM, > which has to be (SHOULD) per Class of Service per E-LSP. > > Regards, > Greg > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrot= e: > >> Hi Loa, >> >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. A= s >> we know traditional transport layers only have one CoS. However E-LSP ha= s >> multiple CoS, which can reorder packets (I know that the reorder packets >> belong to different CoS). Additionally the definition of E-LSP OAM and >> performance and protection and availability, etc will be questionable >> (because of carrying multiple CoS). >> >> Therefore I think E-LSP should not be supported in MPLS-TP or at least >> should be discouraged. >> >> Regards, >> Shahram >> >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of >> Loa Andersson >> Sent: Saturday, April 03, 2010 2:31 AM >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; >> CCAMP >> Subject: [PWE3] short working group last call on >> draft-ietf-mpls-tp-framework-11 >> >> All, >> >> this is to start a short working group last call on "A Framework >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). >> >> Please note that this wg last call is limited to verify that comments >> raised during the orevious working group last call and reviews have >> been correctly addressed. >> >> Please sen comments to the mpls-tp mailing list on April 17th, the >> latest. >> >> /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 >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --0016e640918a65a9f00483c8d1cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Italo,
if we consider Link Bundle (RFC 4201) then it is possible th= at some CoS flows are=A0 being mapped to a different component links. In th= is case per CoS FM is quite necessary.

Regards,
Greg

On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO <Italo.Busi@alcatel-lucent.com= > wrote:
I think that running OAM flows per-PHB, while very much=20 appropriate for PM tools (as already documented in the OAM frameworkd draft= ), is=20 actually an overdesign for FM tools.
=A0
Misconnections and failures are per-LSP and not=20 per-PHB.
=A0
Italo

P.S. Please note my new email address,=20 Italo.Bu= si@alcatel-lucent.com, effective since 1 November 2009.

=A0

From: ccamp-bounces@ietf.org=20 [mailto:ccamp= -bounces@ietf.org] On Behalf Of David Allan=20 I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg Mirsky= ;=20 Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team;=20 pwe3@ietf.org; mpls-tp@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3]=20 short working group last callon=20 draft-ietf-mpls-tp-framework-11

I'm not quite following this=20 argument....
=A0
If I have a number of co-routed paths with different=20 PHBs, I can instantiate a number of L-LSPs, which is a significant amount= of=20 state at every hop, or I can instantiate=A0one E-LSP, which is an N:1=20 compression in the amount of state in transit nodes.
=A0
The only wrinkle is all PHBs of an E-LSP fate share. But=20 then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have= =20 another 'n' L-LSPs or another E-LSP, and if they were co-routed, = the majority=20 of failure cases (link cuts) would result in a loud clang as many=20 L-LSPs=A0vs. one E-LSP was switched (although there would be 'n' = signal=20 fail indications internally to contend with).=A0Overall, it sounds to me= =20 like an E-LSP may be a bit faster there....
=A0
The actual OAM load to instrument them equally is the=20 same. If an E-LSP takes 'n' times the flows to be instumented lik= e 'n' L-LSPs=20 so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 flows may be undesirable for some, but that does not make it a bad=20 idea.
=A0
IMO there is no penalty for supporting E-LSPs and there=20 are measurable benefits. The analysis is flawed.
=A0
my 2 cents
D

From: ccamp-bounces@ietf.org=20 [mailto:ccamp= -bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Sha= hram=20 Davari
Cc: m= pls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 mpls-tp@ietf.org; pwe3@ietf.org
= Subject: Re: [CCAMP] [mpls] [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability = of=20 E-LSP in packet transport network. Though the document is about the Trans= port=20 Profile, references to MPLS-TP as packet transport network technology bee= n=20 changed recently. Now MPLS-TP is referred as "packet network". = It is my=20 understanding that applicability of MPLS-TP functionality, features and= =20 capabilities to the packet transport network will be decided later,=20 separately.
Regarding classes of service in the transport. Neil Harris= on=20 pointed several times that a connection, transport path cannot have multi= ple=20 classes, otherwise it leads to significant increased complexity of OAM, w= hich=20 has to be (SHOULD) per Class of Service per=20 E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davar= i <davari@broadcom.com>=20 wrote:
Hi=20 Loa,

The draft mentions that both L-LSP and E-LSP are supported = in=20 MPLS-TP. As we know traditional transport layers only have one CoS. How= ever=20 E-LSP has multiple CoS, which can reorder packets (I know that the reor= der=20 packets belong to different CoS). Additionally the definition of E-LSP = OAM=20 and performance and protection and availability, etc will be questionab= le=20 (because of carrying multiple CoS).

Therefore I think E-LSP shou= ld=20 not be supported in MPLS-TP or at least should be=20 discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of=20 Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad = hoc team; pwe3@ietf.org<= /a>; CCAMP
Subject: [PWE3]=20 short working group last call on=20 draft-ietf-mpls-tp-framework-11

All,

this is to start a s= hort=20 working group last call on "A Framework
for MPLS in Transport N= etworks"=20 (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= call=20 is limited to verify that comments
raised during the orevious workin= g=20 group last call and reviews have
been correctly addressed.

Pl= ease=20 sen comments to the mpls-tp mailing list on April 17th,=20 the
latest.

/Loa
--


Loa Andersson =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 loa.and= ersson@ericsson.com
Sr=20 Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0+46 767 72 92=20 13
_______________________________________________
pwe3 mailing= =20 list
pwe3@ietf.or= g
https://www.ietf.org/mailman/listinfo/pwe3


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


--0016e640918a65a9f00483c8d1cb-- From Italo.Busi@alcatel-lucent.com Fri Apr 9 00:36:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224EE3A67EB; Fri, 9 Apr 2010 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn+YGJLfrCQP; Fri, 9 Apr 2010 00:36:36 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3097B3A67D2; Fri, 9 Apr 2010 00:36:36 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o397ZRS8017896; Fri, 9 Apr 2010 09:36:28 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 09:36:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 09:39:52 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <201004090430.o394U91l090288@harbor.orleans.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 thread-index: AcrXnV1pDPvZNYnUTk2MVRfh6P5CAgAGldhQ References: Your message of "Thu, 08 Apr 2010 12:30:03 PDT."<2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <201004090430.o394U91l090288@harbor.orleans.occnc.com> From: "BUSI ITALO" To: , "Shahram Davari" X-OriginalArrivalTime: 09 Apr 2010 07:36:12.0110 (UTC) FILETIME=[53F606E0:01CAD7B7] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:36:38 -0000 Curtis, I agree that FM OAM must run at the highest priority within an LSP. However, PM OAM must run at the priority it is measuring. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, = effective since 1 November 2009. =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Curtis Villamizar > Sent: venerd=EC 9 aprile 2010 6.30 > To: Shahram Davari > Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP;=20 > mpls-tp@ietf.org; pwe3@ietf.org > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last=20 > call ondraft-ietf-mpls-tp-framework-11 >=20 >=20 > In message=20 > <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.a > d.broadcom.com> > "Shahram Davari" writes: > > =20 > > Hi John, > > =20 > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if=20 > > any of them fail do protection switching for all of them?=20 > What will be=20 > > the definition of availability for such E-LSP? > > =20 > > Thanks > > SD >=20 >=20 > If there were multiple priorities on an LSP the OAM should be=20 > at a high priority. For example for CS service (the old IP=20 > prec) CS6 is normally used for control traffic. If OAM=20 > failed for CS6 the link is down. If OAM fails for CS0 the=20 > link may just be oversubscribed and contested but CS0 is=20 > defined as the best effort (BE) service. >=20 > A provider may choose to do this. For example, if VOIP ran=20 > at CS4 and worked fine and web and email was runnig on CS0,=20 > phone would work and web would be slow. If a natural=20 > disaster took out 3/4 of the network capacity, then having=20 > working phone and slow web and maybe unworkable web streaming=20 > video might be better than prohibiting oversubscription and=20 > having no service at all. >=20 > Curtis > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From giomarti@cisco.com Fri Apr 9 05:35:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCF03A684A for ; Fri, 9 Apr 2010 05:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NZvGQPedm-2 for ; Fri, 9 Apr 2010 05:35:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5B46E3A67F0 for ; Fri, 9 Apr 2010 05:35:16 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoBAJa7vkuQ/uCWe2dsb2JhbACBPZl+FQEBCwsiBhyhBZkvhQkE X-IronPort-AV: E=Sophos;i="4.52,177,1270425600"; d="scan'208,217";a="59193273" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2010 12:35:11 +0000 Received: from [144.254.166.128] (mnza1-dhcp-vl301-144-254-166-128.cisco.com [144.254.166.128]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o39CZB8d020203; Fri, 9 Apr 2010 12:35:11 GMT Message-ID: <4BBF1F64.4090100@cisco.com> Date: Fri, 09 Apr 2010 14:36:52 +0200 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100305 Lightning/1.0b2pre Thunderbird/3.0.3 MIME-Version: 1.0 To: Young Lee References: <002201cad72b$78debfb0$4b0c7c0a@china.huawei.com> In-Reply-To: <002201cad72b$78debfb0$4b0c7c0a@china.huawei.com> Content-Type: multipart/alternative; boundary="------------040705090206030507080505" Cc: 'CCAMP' Subject: Re: [CCAMP] adjacent lambda constraint X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:35:22 -0000 This is a multi-part message in MIME format. --------------040705090206030507080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, On 04/08/2010 04:55 PM, Young Lee wrote: > > Hi CCAMPers, > > During the last CCAMP meeting in Anaheim, the adjacent lambda > constraint issue > (http://tools.ietf.org/html/draft-schroetter-wson-ospf-link-info-00) > was raised if this should be included in the WSON Framework. > > An Adjacent Lambda constraint is a particular example of an impairment > associated constraint, e.g., when there are 40G and 10G channels > coexist. Hence this is a bit advanced topic to be included in the > current WSON framework. How best to model this needs a bit more > thought, though this is one reasonable approach. For some DWDM systems > different polarization is used on adjacent channels and hence can > couple adjacent channel effects with PMD as well as simple cross talk > due to spectrum overlap. Hence we probably would want to bring this > issue up with ITU-T. As such we would want to address this in the > impairment framework document. > The impairment issue is one of three use case provided, other use cases are simply related to the RWA. My comment above is however independent from the fact that the wson-rwa framework have or have-not to include such considerations about link details. I mean, if not I have no issue about that. > We believe that the WSON Framework (06 version) is ready for WG LC. > The following is the summary of changes in 06 version: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-06 > > ­ We deleted research-oriented/background material: > > o Section 4.3 "Lightpath Temporal Characteristic" has been taken out > > o Section 6.1.4 RWA algorithm related information has been taken out. > > o Section 6.3.1 Lightpath duration/timeliness discussion has been > taken out. > > ­ Editorial: > > o Deleted section 6.4 summary (redundant info) > > o Defined translucent/transparent network in the terminology section > > Please let us know if there is any question on the updated version. > Thanks. > thx for incorporating my comments! Cheers G > Greg and Young > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --------------040705090206030507080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,


On 04/08/2010 04:55 PM, Young Lee wrote:

Hi CCAMPers,

 

During the last CCAMP meeting in Anaheim, the adjacent lambda constraint issue (http://tools.ietf.org/html/draft-schroetter-wson-ospf-link-info-00) was raised if this should be included in the WSON Framework.

 

An Adjacent Lambda constraint is a particular example of an impairment associated constraint, e.g., when there are 40G and 10G channels coexist. Hence this is a bit advanced topic to be included in the current WSON framework. How best to model this needs a bit more thought, though this is one reasonable approach. For some DWDM systems different polarization is used on adjacent channels and hence can couple adjacent channel effects with PMD as well as simple cross talk due to spectrum overlap. Hence we probably would want to bring this issue up with ITU-T. As such we would want to address this in the impairment framework document.

 

The impairment issue is one of three use case provided, other use cases are simply related to the RWA.
 
My comment above is however independent from the fact that the wson-rwa framework have or have-not to include such considerations about link details. I mean, if not I have no issue about that.


We believe that the WSON Framework (06 version) is ready for WG LC. The following is the summary of changes in 06 version: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-06

 

­        We deleted research-oriented/background material:

 

o     Section 4.3 "Lightpath Temporal Characteristic" has been taken out

o     Section 6.1.4 RWA algorithm related information has been taken out.

o     Section 6.3.1 Lightpath duration/timeliness discussion has been taken out.

 

­        Editorial:

o     Deleted section 6.4 summary (redundant info)

o     Defined translucent/transparent network in the terminology section

 

Please let us know if there is any question on the updated version. Thanks.


thx for incorporating my comments!

Cheers
G

 

Greg and Young


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--------------040705090206030507080505-- From maarten.vissers@huawei.com Fri Apr 9 00:35:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7501028C121; Fri, 9 Apr 2010 00:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dksEsXCAuISF; Fri, 9 Apr 2010 00:35:44 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CAD6228C0DC; Fri, 9 Apr 2010 00:35:43 -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 <0L0L00224MF5LM@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:35:29 +0800 (CST) Received: from 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 <0L0L00MJSMF524@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:35:29 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00JQFMEZA9@szxml04-in.huawei.com>; Fri, 09 Apr 2010 15:35:28 +0800 (CST) Date: Fri, 09 Apr 2010 09:35:27 +0200 From: Maarten Vissers In-reply-to: <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> To: 'David Allan I' , 'Greg Mirsky' , 'Shahram Davari' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw)" Thread-index: AcrXUhDmA913Y8gxSkSinQmgQfqgdAAACFZwABj+BOA= References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD4F9953DBF7@EUSAACMS0703.eamcs.ericsson.se> X-Mailman-Approved-At: Fri, 09 Apr 2010 06:34:54 -0700 Cc: mpls@ietf.org, 'CCAMP' , 'MPLS-TP ad hoc team' , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:35:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT E-LSPs (and E-PWs) seem to be more appreciated by customers then L-LSPs (L-PWs) I am told by an operator. If an E-LSP/E-PW breaks, then there is no connectivity for any of the CoS levels. Partial failure of a multi-CoS service (i.e. for one of the CoS levels) is considered to be bad. Main service these days is Ethernet and Ethernet VLANs are by default supporting multiple CoS levels. Most of the OAM checks if the transport path is present. Only the packet loss measurement and packet delay measurement OAM checks treatment of client flows. So only those two OAM types may need per CoS measurements. This is not different from Ethernet OAM. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of David Allan I Sent: donderdag 8 april 2010 21:45 To: Greg Mirsky; Shahram Davari Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 I'm not quite following this argument.... If I have a number of co-routed paths with different PHBs, I can instantiate a number of L-LSPs, which is a significant amount of state at every hop, or I can instantiate one E-LSP, which is an N:1 compression in the amount of state in transit nodes. The only wrinkle is all PHBs of an E-LSP fate share. But then if I was protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majority of failure cases (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched (although there would be 'n' signal fail indications internally to contend with). Overall, it sounds to me like an E-LSP may be a bit faster there.... The actual OAM load to instrument them equally is the same. If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? I appreciate that the ability to generate per PHB flows may be undesirable for some, but that does not make it a bad idea. IMO there is no penalty for supporting E-LSPs and there are measurable benefits. The analysis is flawed. my 2 cents D _____ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Thursday, April 08, 2010 3:31 PM To: Shahram Davari Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 Dear Shahram, I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately. Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP. Regards, Greg On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrote: Hi Loa, The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we know traditional transport layers only have one CoS. However E-LSP has multiple CoS, which can reorder packets (I know that the reorder packets belong to different CoS). Additionally the definition of E-LSP OAM and performance and protection and availability, etc will be questionable (because of carrying multiple CoS). Therefore I think E-LSP should not be supported in MPLS-TP or at least should be discouraged. Regards, Shahram -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 03, 2010 2:31 AM To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 All, this is to start a short working group last call on "A Framework for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). Please note that this wg last call is limited to verify that comments raised during the orevious working group last call and reviews have been correctly addressed. Please sen comments to the mpls-tp mailing list on April 17th, the latest. /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 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
E-LSPs (and E-PWs) seem to be more appreciated by customers then L-LSPs (L-PWs) I am told by an operator. If an E-LSP/E-PW breaks, then there is no connectivity for any of the CoS levels. Partial failure of a multi-CoS service (i.e. for one of the CoS levels) is considered to be bad.
 
Main service these days is Ethernet and Ethernet VLANs are by default supporting multiple CoS levels.
 
Most of the OAM checks if the transport path is present. Only the packet loss measurement and packet delay measurement OAM checks treatment of client flows. So only those two OAM types may need per CoS measurements. This is not different from Ethernet OAM.
 
Regards,
Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of David Allan I
Sent: donderdag 8 april 2010 21:45
To: Greg Mirsky; Shahram Davari
Cc: mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11

I'm not quite following this argument....
 
If I have a number of co-routed paths with different PHBs, I can instantiate a number of L-LSPs, which is a significant amount of state at every hop, or I can instantiate one E-LSP, which is an N:1 compression in the amount of state in transit nodes.
 
The only wrinkle is all PHBs of an E-LSP fate share. But then if I was protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or another E-LSP, and if they were co-routed, the majority of failure cases (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was switched (although there would be 'n' signal fail indications internally to contend with). Overall, it sounds to me like an E-LSP may be a bit faster there....
 
The actual OAM load to instrument them equally is the same. If an E-LSP takes 'n' times the flows to be instumented like 'n' L-LSPs so what????  I appreciate that the ability to generate per PHB flows may be undesirable for some, but that does not make it a bad idea.
 
IMO there is no penalty for supporting E-LSPs and there are measurable benefits. The analysis is flawed.
 
my 2 cents
D

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Shahram Davari
Cc: mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org
Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

Dear Shahram,
I share your concern regarding applicability of E-LSP in packet transport network. Though the document is about the Transport Profile, references to MPLS-TP as packet transport network technology been changed recently. Now MPLS-TP is referred as "packet network". It is my understanding that applicability of MPLS-TP functionality, features and capabilities to the packet transport network will be decided later, separately.
Regarding classes of service in the transport. Neil Harrison pointed several times that a connection, transport path cannot have multiple classes, otherwise it leads to significant increased complexity of OAM, which has to be (SHOULD) per Class of Service per E-LSP.

Regards,
Greg

On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari <davari@broadcom.com> wrote:
Hi Loa,

The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. As we know traditional transport layers only have one CoS. However E-LSP has multiple CoS, which can reorder packets (I know that the reorder packets belong to different CoS). Additionally the definition of E-LSP OAM and performance and protection and availability, etc will be questionable (because of carrying multiple CoS).

Therefore I think E-LSP should not be supported in MPLS-TP or at least should be discouraged.

Regards,
Shahram

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP
Subject: [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11

All,

this is to start a short working group last call on "A Framework
for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11).

Please note that this wg last call is limited to verify that comments
raised during the orevious working group last call and reviews have
been correctly addressed.

Please sen comments to the mpls-tp mailing list on April 17th, the
latest.

/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
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3


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

--Boundary_(ID_YtqB4KMQtXNh8D+Uz/bdkw)-- From maarten.vissers@huawei.com Fri Apr 9 00:59:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF74A3A69CE; Fri, 9 Apr 2010 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o8w7ACn4knG; Fri, 9 Apr 2010 00:59:19 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D90A53A6876; Fri, 9 Apr 2010 00:59:18 -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 <0L0L00LQWNIGWF@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:59:05 +0800 (CST) Received: from 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 <0L0L0081FNIG24@szxga03-in.huawei.com>; Fri, 09 Apr 2010 15:59:04 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00JEDNICAC@szxml04-in.huawei.com>; Fri, 09 Apr 2010 15:59:04 +0800 (CST) Date: Fri, 09 Apr 2010 09:59:04 +0200 From: Maarten Vissers In-reply-to: <201004090430.o394U91l090288@harbor.orleans.occnc.com> To: curtis@occnc.com, 'Shahram Davari' Message-id: <4AA9A83DBDBF4EC2AFFCAA143B40681D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrXngttOj8FJAlyR4ixCguypTcc0AAHGZhg References: "Your message of Thu, 08 Apr 2010 12:30:03 PDT." <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com> <201004090430.o394U91l090288@harbor.orleans.occnc.com> X-Mailman-Approved-At: Fri, 09 Apr 2010 06:34:54 -0700 Cc: mpls@ietf.org, 'CCAMP' , 'MPLS-TP ad hoc team' , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:59:19 -0000 Curtis, > If there were multiple priorities on an LSP the OAM should be at a high priority. This is the approach taken in Y.1731 for Ethernet OAM. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Curtis Villamizar Sent: vrijdag 9 april 2010 6:30 To: Shahram Davari Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP; mpls-tp@ietf.org; pwe3@ietf.org Subject: Re: [mpls-tp] [CCAMP] [mpls] [PWE3] short working group last call on draft-ietf-mpls-tp-framework-11 In message <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.ad.broadcom.com > "Shahram Davari" writes: > > Hi John, > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > any of them fail do protection switching for all of them? What will be > the definition of availability for such E-LSP? > > Thanks > SD If there were multiple priorities on an LSP the OAM should be at a high priority. For example for CS service (the old IP prec) CS6 is normally used for control traffic. If OAM failed for CS6 the link is down. If OAM fails for CS0 the link may just be oversubscribed and contested but CS0 is defined as the best effort (BE) service. A provider may choose to do this. For example, if VOIP ran at CS4 and worked fine and web and email was runnig on CS0, phone would work and web would be slow. If a natural disaster took out 3/4 of the network capacity, then having working phone and slow web and maybe unworkable web streaming video might be better than prohibiting oversubscription and having no service at all. Curtis _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Fri Apr 9 01:51:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A68B3A69C1; Fri, 9 Apr 2010 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c-qqoaYxJ+K; Fri, 9 Apr 2010 01:51:02 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CA46D3A69B7; Fri, 9 Apr 2010 01:50:46 -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 <0L0L007JGPW8TD@szxga04-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Received: from 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 <0L0L00HAAPW8K0@szxga04-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00H2MPW4HW@szxml06-in.huawei.com>; Fri, 09 Apr 2010 16:50:32 +0800 (CST) Date: Fri, 09 Apr 2010 10:50:32 +0200 From: Maarten Vissers In-reply-to: <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> To: 'BUSI ITALO' , mpls-tp@ietf.org, mpls@ietf.org, 'MPLS-TP ad hoc team' , pwe3@ietf.org, 'CCAMP' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcrTES3cEA/AlqzZSZyKD24mAjMz3wClELFgAIPh/OAAAYBBEA== References: <4BB70AE7.1020605@pi.nu> <2C2F1EBA8050E74EA81502D5740B4BD693F018977F@SJEXCHCCR02.corp.ad.broadcom.com> <6FD21B53861BF44AA90A288402036AB4030B233D@FRVELSMBS21.ad2.ad.alcatel.com> X-Mailman-Approved-At: Fri, 09 Apr 2010 06:34:54 -0700 Subject: Re: [CCAMP] [mpls-tp] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 08:51:03 -0000 Performance monitoring for multiple CoS connections has been specified = in Y.1731 as follows: 1) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for=20 **one (default: highest)** CoS level in the connection [also Degraded (DEG) defect has been defined for this highest CoS = level] 2) on-demand frame loss monitoring and frame delay (delay variation) monitoring for any CoS level; this on-demand monitoring does not provide ES/SES/BBE/UAT results, it provides just an event result MEF has requested to extend the Y.1731 performance monitoring with: A) pro-active PM (i.e. 15 minute/24 hour ES/SES/BBE and UAT) for=20 **every** CoS level in the connection B) pro-active PM (i.e. 15 minute/24 hour reports) for frame delay (delay variation) monitoring for **every** CoS level in the = connection C) introduce pro-active and on-demand synthetic frame loss monitoring = for=20 mp2mp/rmp connections for every CoS level in the connection Q.9/15 and Q.10/15 are analysing the complexity of this extension at the moment. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of BUSI ITALO Sent: vrijdag 9 april 2010 9:24 To: Shahram Davari; Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; = MPLS-TP ad hoc team; pwe3@ietf.org; CCAMP Subject: Re: [mpls-tp] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 Shahram, > As we know traditional transport layers only have one CoS. This is no more the case after Ethernet transport layer has been = developed. > Additionally the definition of E-LSP OAM and performance and=20 > protection and availability, etc will be questionable (because of=20 > carrying multiple CoS). I agree that performance monitoring for multi-CoS connections (e.g., = E-LSP) is not trivial. We have exactly the same issue with Ethernet performance monitoring. In principle I think that a solution can be defined but I am spending = too much time on mpls-tp standardization so I had not time to monitor the = status of this work within Q14/15. I do not see any issue with fault monitoring of multi-CoS connections as faults are not per-CoS but per-connection. Italo P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. =20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Shahram Davari > Sent: gioved=EC 8 aprile 2010 21.00 > To: Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc=20 > team; pwe3@ietf.org; CCAMP > Subject: Re: [mpls] [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 >=20 > Hi Loa, >=20 > The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. = > As we know traditional transport layers only have one CoS. However=20 > E-LSP has multiple CoS, which can reorder packets (I know that the=20 > reorder packets belong to different CoS). Additionally the definition=20 > of E-LSP OAM and performance and protection and availability, etc will = > be questionable (because of carrying multiple CoS). >=20 > Therefore I think E-LSP should not be supported in MPLS-TP or at least = > should be discouraged. >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf=20 > Of Loa Andersson > Sent: Saturday, April 03, 2010 2:31 AM > To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; CCAMP > Subject: [PWE3] short working group last call on > draft-ietf-mpls-tp-framework-11 >=20 > All, >=20 > this is to start a short working group last call on "A Framework for=20 > MPLS in Transport Networks" > (draft-ietf-mpls-tp-framework-11). >=20 > Please note that this wg last call is limited to verify that comments=20 > raised during the orevious working group last call and reviews have=20 > been correctly addressed. >=20 > Please sen comments to the mpls-tp mailing list on April 17th, the=20 > latest. >=20 > /Loa > -- >=20 >=20 > Loa Andersson email:=20 > 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 _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From zhangfatai@huawei.com Fri Apr 9 08:31:08 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6498A3A6874 for ; Fri, 9 Apr 2010 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K8tpKrW7OPo for ; Fri, 9 Apr 2010 08:31:07 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 5AD133A683A for ; Fri, 9 Apr 2010 08:31:07 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0M007M38FRPH@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 09 Apr 2010 10:31:03 -0500 (CDT) Received: from zhang ([119.123.83.254]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0M00FBK8FOTP@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 09 Apr 2010 10:31:03 -0500 (CDT) Date: Fri, 09 Apr 2010 23:30:54 +0800 From: Fatai Zhang To: "BRUNGARD, DEBORAH A (ATTLABS)" , CCAMP Message-id: <00e301cad7f9$aa07b1e0$84cbfea9@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 15:31:08 -0000 Yes/Support! as an author of this draft. Best Regards Fatai ----- Original Message ----- From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Sent: Wednesday, April 07, 2010 3:17 AM Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Fri Apr 9 08:59:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAE63A67A7 for ; Fri, 9 Apr 2010 08:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.129 X-Spam-Level: **** X-Spam-Status: No, score=4.129 tagged_above=-999 required=5 tests=[AWL=-4.869, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDF2ygITXyI2 for ; Fri, 9 Apr 2010 08:59:42 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 550C33A6917 for ; Fri, 9 Apr 2010 08:59:18 -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 <0L0M00JQS9QG7G@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 09 Apr 2010 23:59:04 +0800 (CST) Received: from 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 <0L0M006QO9QG5Q@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 09 Apr 2010 23:59:04 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [119.123.83.254]) by szxmc03-in.huawei.com (mshttpd); Fri, 09 Apr 2010 23:59:04 +0800 Date: Fri, 09 Apr 2010 23:59:04 +0800 From: zhangfatai 41162 In-reply-to: To: "BRUNGARD, DEBORAH A (ATTLABS)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: Cc: CCAMP Subject: [CCAMP] =?gb2312?b?u9i4tCA6IHBvbGwgb24gZHJhZnQtemhhbmctY2NhbXAt?= =?gb2312?b?Z21wbHMtZzcwOS1mcmFtZXdvcmstMDI=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 15:59:42 -0000 Yes/Support! as an author of this draft=2E Best Regards Fatai *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained here in any way (incl= uding=2C but not limited to=2C total or partial disclosure=2C reproductio= n=2C or dissemination) by persons other than the intended recipient(s) is= prohibited=2E If you receive this email in error=2C please notify the se= nder by phone or email immediately and delete it! ************************************************************************= ***************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22BRUNGARD=2C DEBORAH A (ATTLABS)=22 =3Cdb3546=40a= tt=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CB=C4=D4=C2 7=C8=D5=2C 2010 =C9=CF= =CE=E73=3A20 =D6=F7=CC=E2=3A =5BCCAMP=5D poll on draft-zhang-ccamp-gmpls-g709-framewor= k-02 =CA=D5=BC=FE=C8=CB=3A CCAMP =3Cccamp=40ietf=2Eorg=3E =3E All=2C =3E = =3E This is to start a two week poll on making =3E draft-zhang-ccamp-gmpls-g709-framework-02=2Etxt a ccamp working group= =3E document=2E Send a mail to the mailing list indicating =22yes/support= =22 or =3E =22no/do not support=22=2E =3E = =3E The poll ends Tuesday=2C April 20th=2E =3E = =3E Deborah =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E CCAMP mailing list =3E CCAMP=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/ccamp =3E From tochio@jp.fujitsu.com Sat Apr 10 17:41:21 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DB63A683F for ; Sat, 10 Apr 2010 17:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVjCGeegph5O for ; Sat, 10 Apr 2010 17:41:19 -0700 (PDT) Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by core3.amsl.com (Postfix) with ESMTP id 8A2F53A680D for ; Sat, 10 Apr 2010 17:41:19 -0700 (PDT) Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o3B0fE2E010660 for (envelope-from tochio@jp.fujitsu.com); Sun, 11 Apr 2010 09:41:14 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id E01482C6A73 for ; Sun, 11 Apr 2010 09:41:13 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id C74E61EF081 for ; Sun, 11 Apr 2010 09:41:13 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id ACAF01DB8012 for ; Sun, 11 Apr 2010 09:41:13 +0900 (JST) Received: from sw12.gw.fujitsu.co.jp (sw12.gw.fujitsu.co.jp [10.0.76.52]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 52C991DB8014 for ; Sun, 11 Apr 2010 09:41:13 +0900 (JST) Received: from [127.0.0.1] ([172.31.140.248]) by sw12.gw.fujitsu.co.jp with ESMTP id o3B0fApH027303 for ; Sun, 11 Apr 2010 09:41:12 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v0.15.3 Received: from Tochio_FMVS8360[172.31.140.248] by Tochio_FMVS8360 (FujitsuOutboundMailChecker v0.15.3/9992[172.31.140.248]); Sun, 11 Apr 2010 09:40:58 GMT Message-ID: <4BC11A8F.4070402@jp.fujitsu.com> Date: Sun, 11 Apr 2010 09:40:47 +0900 From: Yuji Tochio User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: CCAMP References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:41:21 -0000 Support Regards, Yuji BRUNGARD, DEBORAH A (ATTLABS) wrote: > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From curtis@occnc.com Sat Apr 10 20:43:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59E23A6816; Sat, 10 Apr 2010 20:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wed+fsjwIQi; Sat, 10 Apr 2010 20:43:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 36A113A6781; Sat, 10 Apr 2010 20:43:25 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o3B3hEAv095631; Sat, 10 Apr 2010 23:43:14 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004110343.o3B3hEAv095631@harbor.orleans.occnc.com> To: "BUSI ITALO" From: Curtis Villamizar In-reply-to: Your message of "Fri, 09 Apr 2010 09:39:52 +0200." <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> Date: Sat, 10 Apr 2010 23:43:14 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, Shahram Davari , MPLS-TP ad hoc team , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [CCAMP] [mpls] [PWE3] short working group last call ondraft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:43:26 -0000 In message <6FD21B53861BF44AA90A288402036AB4030B235B@FRVELSMBS21.ad2.ad.alcatel.com> "BUSI ITALO" writes: > > Curtis, > > I agree that FM OAM must run at the highest priority within an LSP. > > However, PM OAM must run at the priority it is measuring. > > Italo Italo, It would be best if the documents allowed FM to be run at one priority. This should be constrained (at least with a SHOULD) to be the lowest priority for which congestion cannot occur by virtue of the SLA, the resource reservations, and policing, or a priority higher than traffic if all traffic is not policed. PM should be allowed to be run at any priority, including run at multiple priorities. Curtis > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, effective since 1 November 2009. > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > > On Behalf Of Curtis Villamizar > > Sent: venerdμ 9 aprile 2010 6.30 > > To: Shahram Davari > > Cc: MPLS-TP ad hoc team; mpls@ietf.org; CCAMP; > > mpls-tp@ietf.org; pwe3@ietf.org > > Subject: Re: [CCAMP] [mpls] [PWE3] short working group last > > call ondraft-ietf-mpls-tp-framework-11 > > > > > > In message > > <2C2F1EBA8050E74EA81502D5740B4BD693F018978E@SJEXCHCCR02.corp.a > > d.broadcom.com> > > "Shahram Davari" writes: > > > > > > Hi John, > > > > > > Thanks. Does that mean one needs to run 8 BFDs on that E-LSP and if > > > any of them fail do protection switching for all of them? > > What will be > > > the definition of availability for such E-LSP? > > > > > > Thanks > > > SD > > > > > > If there were multiple priorities on an LSP the OAM should be > > at a high priority. For example for CS service (the old IP > > prec) CS6 is normally used for control traffic. If OAM > > failed for CS6 the link is down. If OAM fails for CS0 the > > link may just be oversubscribed and contested but CS0 is > > defined as the best effort (BE) service. > > > > A provider may choose to do this. For example, if VOIP ran > > at CS4 and worked fine and web and email was runnig on CS0, > > phone would work and web would be slow. If a natural > > disaster took out 3/4 of the network capacity, then having > > working phone and slow web and maybe unworkable web streaming > > video might be better than prohibiting oversubscription and > > having no service at all. > > > > Curtis From curtis@occnc.com Sat Apr 10 21:50:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F88D3A6934 for ; Sat, 10 Apr 2010 21:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[AWL=-2.971, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, MANGLED_PLEASE=2.3, MANGLED_WORKNG=2.3, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRqLVZJX7Q8Y for ; Sat, 10 Apr 2010 21:50:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 344353A67F7 for ; Sat, 10 Apr 2010 21:50:06 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o3B4o1Ou096475; Sun, 11 Apr 2010 00:50:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> To: Greg Mirsky From: Curtis Villamizar In-reply-to: Your message of "Fri, 09 Apr 2010 00:33:56 PDT." Date: Sun, 11 Apr 2010 00:50:01 -0400 Sender: curtis@occnc.com Cc: mpls@ietf.org, MPLS-TP ad hoc team , BUSI ITALO , CCAMP , mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [CCAMP] [mpls-tp] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 04:50:10 -0000 In message Greg Mirsky writes: > > > Dear Italo, if we consider Link Bundle (RFC 4201) then it is possible > that some CoS flows are being mapped to a different component > links. In this case per CoS FM is quite necessary. > > Regards, > Greg Greg, That would be a broken implementation. The AF service occupies 3 TC values and is supposed to remain in order. There is no document that suggests this behaviour. Curtis > On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO > wrote: > > > I think that running OAM flows per-PHB, while very much appropriate for > > PM tools (as already documented in the OAM frameworkd draft), is actually= > an > > overdesign for FM tools. > > > > Misconnections and failures are per-LSP and not per-PHB. > > > > Italo > > > > P.S. Please note my new email address, Italo.Busi@alcatel-lucent.com, > > effective since 1 November 2009. > > > > > > ------------------------------ > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > > Of *David Allan I > > *Sent:* gioved=EC 8 aprile 2010 21.45 > > *To:* Greg Mirsky; Shahram Davari > > *Cc:* mpls@ietf.org; CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org; > > mpls-tp@ietf.org > > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last callon > > draft-ietf-mpls-tp-framework-11 > > > > I'm not quite following this argument.... > > > > If I have a number of co-routed paths with different PHBs, I can > > instantiate a number of L-LSPs, which is a significant amount of state at > > every hop, or I can instantiate one E-LSP, which is an N:1 compression in > > the amount of state in transit nodes. > > > > The only wrinkle is all PHBs of an E-LSP fate share. But then if I was > > protecting the L-LSP or the E-LSP version I'd have another 'n' L-LSPs or > > another E-LSP, and if they were co-routed, the majority of failure cases > > (link cuts) would result in a loud clang as many L-LSPs vs. one E-LSP was > > switched (although there would be 'n' signal fail indications internally = > to > > contend with). Overall, it sounds to me like an E-LSP may be a bit faster > > there.... > > > > The actual OAM load to instrument them equally is the same. If an E-LSP > > takes 'n' times the flows to be instumented like 'n' L-LSPs so what???? = > I > > appreciate that the ability to generate per PHB flows may be undesirable = > for > > some, but that does not make it a bad idea. > > > > IMO there is no penalty for supporting E-LSPs and there are measurable > > benefits. The analysis is flawed. > > > > my 2 cents > > D > > > > ------------------------------ > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > > Of *Greg Mirsky > > *Sent:* Thursday, April 08, 2010 3:31 PM > > *To:* Shahram Davari > > *Cc:* mpls@ietf.org; MPLS-TP ad hoc team; CCAMP; mpls-tp@ietf.org; > > pwe3@ietf.org > > *Subject:* Re: [CCAMP] [mpls] [PWE3] short working group last call on > > draft-ietf-mpls-tp-framework-11 > > > > Dear Shahram, > > I share your concern regarding applicability of E-LSP in packet transport > > network. Though the document is about the Transport Profile, references t= > o > > MPLS-TP as packet transport network technology been changed recently. Now > > MPLS-TP is referred as "packet network". It is my understanding that > > applicability of MPLS-TP functionality, features and capabilities to the > > packet transport network will be decided later, separately. > > Regarding classes of service in the transport. Neil Harrison pointed > > several times that a connection, transport path cannot have multiple > > classes, otherwise it leads to significant increased complexity of OAM, > > which has to be (SHOULD) per Class of Service per E-LSP. > > > > Regards, > > Greg > > > > On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davari wrot= > e: > > > >> Hi Loa, > >> > >> The draft mentions that both L-LSP and E-LSP are supported in MPLS-TP. A= > s > >> we know traditional transport layers only have one CoS. However E-LSP ha= > s > >> multiple CoS, which can reorder packets (I know that the reorder packets > >> belong to different CoS). Additionally the definition of E-LSP OAM and > >> performance and protection and availability, etc will be questionable > >> (because of carrying multiple CoS). > >> > >> Therefore I think E-LSP should not be supported in MPLS-TP or at least > >> should be discouraged. > >> > >> Regards, > >> Shahram > >> > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > >> Loa Andersson > >> Sent: Saturday, April 03, 2010 2:31 AM > >> To: mpls-tp@ietf.org; mpls@ietf.org; MPLS-TP ad hoc team; pwe3@ietf.org; > >> CCAMP > >> Subject: [PWE3] short working group last call on > >> draft-ietf-mpls-tp-framework-11 > >> > >> All, > >> > >> this is to start a short working group last call on "A Framework > >> for MPLS in Transport Networks" (draft-ietf-mpls-tp-framework-11). > >> > >> Please note that this wg last call is limited to verify that comments > >> raised during the orevious working group last call and reviews have > >> been correctly addressed. > >> > >> Please sen comments to the mpls-tp mailing list on April 17th, the > >> latest. > >> > >> /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 > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > > > > > --0016e640918a65a9f00483c8d1cb > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Dear Italo,
if we consider Link Bundle (RFC 4201) then it is possible th= > at some CoS flows are=A0 being mapped to a different component links. In th= > is case per CoS FM is quite necessary.

Regards,
Greg

class=3D"gmail_quote"> > On Fri, Apr 9, 2010 at 12:28 AM, BUSI ITALO < =3D"mailto:Italo.Busi@alcatel-lucent.com">Italo.Busi@alcatel-lucent.com= > > wrote:
t 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1= > ex;"> > > > > >
>
ce=3D"Arial">I think that running OAM flows per-PHB, while very much=20 > appropriate for PM tools (as already documented in the OAM frameworkd draft= > ), is=20 > actually an overdesign for FM tools.
>
ce=3D"Arial">=A0
>
ce=3D"Arial">Misconnections and failures are per-LSP and not=20 > per-PHB.
>
ce=3D"Arial">=A0
>
ce=3D"Arial">Italo

>

P.S. Please note my new email address,=20 > Italo.Bu= > si@alcatel-lucent.com, effective since 1 November 2009.

>
=A0

>
: 2px solid rgb(0, 0, 255); margin-right: 0px;"> >
>
> From: nces@ietf.org" target=3D"_blank">ccamp-bounces@ietf.org=20 > [mailto:ccamp= > -bounces@ietf.org] On Behalf Of David Allan=20 > I
Sent: gioved=EC 8 aprile 2010 21.45
To: Greg Mirsky= > ;=20 > Shahram Davari
Cc: blank">mpls@ietf.org; CCAMP; MPLS-TP ad hoc team;=20 > pwe3@ietf.org; href=3D"mailto:mpls-tp@ietf.org" target=3D"_blank">mpls-tp@ietf.org
= > Subject: Re: [CCAMP] [mpls] [PWE3]=20 > short working group last callon=20 > draft-ietf-mpls-tp-framework-11

class=3D"h5"> >
>
face=3D"Arial">I'm not quite following this=20 > argument....
>
face=3D"Arial">=A0
>
face=3D"Arial">If I have a number of co-routed paths with different=20 > PHBs, I can instantiate a number of L-LSPs, which is a significant amount= > of=20 > state at every hop, or I can instantiate=A0one E-LSP, which is an N:1=20 > compression in the amount of state in transit nodes.
>
face=3D"Arial">=A0
>
face=3D"Arial">The only wrinkle is all PHBs of an E-LSP fate share. But=20 > then if I was protecting=A0the L-LSP or the E-LSP version=A0I'd have= > =20 > another 'n' L-LSPs or another E-LSP, and if they were co-routed, = > the majority=20 > of failure cases (link cuts) would result in a loud clang as many=20 > L-LSPs=A0vs. one E-LSP was switched (although there would be 'n' = > signal=20 > fail indications internally to contend with).=A0Overall, it sounds to me= > =20 > like an E-LSP may be a bit faster there....
>
face=3D"Arial">=A0
>
face=3D"Arial">The actual OAM load to instrument them equally is the=20 > same. If an E-LSP takes 'n' times the flows to be instumented lik= > e 'n' L-LSPs=20 > so=A0what????=A0=A0I appreciate that the ability to generate per PHB=20 > flows may be undesirable for some, but that does not make it a bad=20 > idea.
>
face=3D"Arial">=A0
>
face=3D"Arial">IMO there is no penalty for supporting E-LSPs and there=20 > are measurable benefits. The analysis is flawed.
>
face=3D"Arial">=A0
>
face=3D"Arial">my 2 cents
>
face=3D"Arial">D

>
>
> From: nces@ietf.org" target=3D"_blank">ccamp-bounces@ietf.org=20 > [mailto:ccamp= > -bounces@ietf.org] On Behalf Of Greg=20 > Mirsky
Sent: Thursday, April 08, 2010 3:31 PM
To: Sha= > hram=20 > Davari
Cc: m= > pls@ietf.org; MPLS-TP ad hoc team; CCAMP;=20 > mpls-tp@ietf.org >; pwe3@ietf.org
= > Subject: Re: [CCAMP] [mpls] [PWE3]=20 > short working group last call on=20 > draft-ietf-mpls-tp-framework-11

>
Dear Shahram,
I share your concern regarding applicability = > of=20 > E-LSP in packet transport network. Though the document is about the Trans= > port=20 > Profile, references to MPLS-TP as packet transport network technology bee= > n=20 > changed recently. Now MPLS-TP is referred as "packet network". = > It is my=20 > understanding that applicability of MPLS-TP functionality, features and= > =20 > capabilities to the packet transport network will be decided later,=20 > separately.
Regarding classes of service in the transport. Neil Harris= > on=20 > pointed several times that a connection, transport path cannot have multi= > ple=20 > classes, otherwise it leads to significant increased complexity of OAM, w= > hich=20 > has to be (SHOULD) per Class of Service per=20 > E-LSP.

Regards,
Greg

>
On Thu, Apr 8, 2010 at 11:59 AM, Shahram Davar= > i < lank">davari@broadcom.com>=20 > wrote:
>
0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);">Hi=20 > Loa,

The draft mentions that both L-LSP and E-LSP are supported = > in=20 > MPLS-TP. As we know traditional transport layers only have one CoS. How= > ever=20 > E-LSP has multiple CoS, which can reorder packets (I know that the reor= > der=20 > packets belong to different CoS). Additionally the definition of E-LSP = > OAM=20 > and performance and protection and availability, etc will be questionab= > le=20 > (because of carrying multiple CoS).

Therefore I think E-LSP shou= > ld=20 > not be supported in MPLS-TP or at least should be=20 > discouraged.

Regards,
Shahram
>
>
>

-----Original Message-----
From: nces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org [mailto: =3D"mailto:pwe3-bounces@ietf.org" target=3D"_blank">pwe3-bounces@ietf.org a>] On Behalf Of=20 > Loa Andersson
Sent: Saturday, April 03, 2010 2:31 AM
To: =3D"mailto:mpls-tp@ietf.org" target=3D"_blank">mpls-tp@ietf.org; f=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; MPLS-TP ad = > hoc team; pwe3@ietf.org<= > /a>; CCAMP
> Subject: [PWE3]=20 > short working group last call on=20 > draft-ietf-mpls-tp-framework-11

All,

this is to start a s= > hort=20 > working group last call on "A Framework
for MPLS in Transport N= > etworks"=20 > (draft-ietf-mpls-tp-framework-11).

Please note that this wg last= > call=20 > is limited to verify that comments
raised during the orevious workin= > g=20 > group last call and reviews have
been correctly addressed.

Pl= > ease=20 > sen comments to the mpls-tp mailing list on April 17th,=20 > the
latest.

/Loa
--


Loa Andersson =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email:=20 > loa.and= > ersson@ericsson.com
Sr=20 > Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0 :loa@pi.nu" target=3D"_blank">loa@pi.nu
Ericsson Inc =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone:=20 > +46 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 > =A0 =A0 =A0 =A0+46 767 72 92=20 > 13
_______________________________________________
pwe3 mailing= > =20 > list
pwe3@ietf.or= > g
blank">https://www.ietf.org/mailman/listinfo/pwe3


v>_______________________________________________
> mpls=20 > mailing list
mpls= > @ietf.org
get=3D"_blank">https://www.ietf.org/mailman/listinfo/mpls
te> >

>

> > --0016e640918a65a9f00483c8d1cb-- > > --===============1523831359== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > --===============1523831359==-- From stbryant@cisco.com Sun Apr 11 01:04:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFC53A68DF; Sun, 11 Apr 2010 01:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.767 X-Spam-Level: X-Spam-Status: No, score=-9.767 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpFaXmBIijqH; Sun, 11 Apr 2010 01:03:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6D0073A6767; Sun, 11 Apr 2010 01:03:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0LABQfwUtAaMHG/2dsb2JhbACPOYtDSHGdPIFRCgGWQYUMBA X-IronPort-AV: E=Sophos;i="4.52,184,1270425600"; d="scan'208";a="113525099" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 11 Apr 2010 08:03:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3B83lNd028379; Sun, 11 Apr 2010 08:03:48 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o3B83jX29504; Sun, 11 Apr 2010 09:03:45 +0100 (BST) Message-ID: <4BC18261.1010800@cisco.com> Date: Sun, 11 Apr 2010 09:03:45 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 References: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> In-Reply-To: <201004110450.o3B4o1Ou096475@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] [mpls] [PWE3] short working group last callon draft-ietf-mpls-tp-framework-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 08:04:00 -0000 In Loa's original mail he says "Please send comments to the mpls-tp mailing list..." Please can we continue this discussion on ONLY that list (mpls-tp@ietf.org). Thanks Stewart From wwwrun@rfc-editor.org Mon Apr 12 07:00:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2895B3A68A9 for ; Mon, 12 Apr 2010 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePb+1RlXfQjg for ; Mon, 12 Apr 2010 07:00:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6B4933A67E3 for ; Mon, 12 Apr 2010 07:00:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB180E07AC; Mon, 12 Apr 2010 07:00:02 -0700 (PDT) To: lberger@movaz.com, stbryant@cisco.com, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20100412140002.BB180E07AC@rfc-editor.org> Date: Mon, 12 Apr 2010 07:00:02 -0700 (PDT) Cc: turners@ieca.com, ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC3473 (2159) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:00:11 -0000 The following errata report has been submitted for RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3473&eid=2159 -------------------------------------- Type: Editorial Reported by: Sean Turner Section: 12 Original Text ------------- Alternatively, the sending of no-hop-by-hop Notify messages can be disabled. Corrected Text -------------- Alternatively, the sending of non-hop-by-hop Notify messages can be disabled. Notes ----- r/no-hop-by-hop/non-hop-by-hop 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. -------------------------------------- RFC3473 (draft-ietf-mpls-generalized-rsvp-te-09) -------------------------------------- Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions Publication Date : January 2003 Author(s) : L. Berger, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Apr 12 07:03:09 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2450F3A6A46 for ; Mon, 12 Apr 2010 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dcitnx8ot9cm for ; Mon, 12 Apr 2010 07:03:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3DB673A68A9 for ; Mon, 12 Apr 2010 07:03:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 974A2E07AD; Mon, 12 Apr 2010 07:03:01 -0700 (PDT) To: lberger@movaz.com, stbryant@cisco.com, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20100412140301.974A2E07AD@rfc-editor.org> Date: Mon, 12 Apr 2010 07:03:01 -0700 (PDT) Cc: turners@ieca.com, ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Select One Errata Reported] RFC3473 (2160) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:03:09 -0000 The following errata report has been submitted for RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3473&eid=2160 -------------------------------------- Type: Select One Reported by: Sean Turner Section: 12 Original Text ------------- Configured keys MAY be used. Corrected Text -------------- Manually configured keys MAY be used. Notes ----- Assumed that this sentence is talking about the opposite of an automated key management system, which is manually configured keys. 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. -------------------------------------- RFC3473 (draft-ietf-mpls-generalized-rsvp-te-09) -------------------------------------- Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions Publication Date : January 2003 Author(s) : L. Berger, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From ahagens@amsl.com Mon Apr 12 07:32:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E3C28C0E1 for ; Mon, 12 Apr 2010 07:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bypTv4nK3rZG for ; Mon, 12 Apr 2010 07:32:25 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 11ECF28C0E8 for ; Mon, 12 Apr 2010 07:31:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 5EC90E0602; Mon, 12 Apr 2010 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvLfvLPKmUBR; Mon, 12 Apr 2010 07:31:22 -0700 (PDT) Received: from rfc2.home (pool-173-73-54-24.washdc.fios.verizon.net [173.73.54.24]) by c1a.amsl.com (Postfix) with ESMTPSA id 5BFD5E0952; Mon, 12 Apr 2010 07:31:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <20100412140301.974A2E07AD@rfc-editor.org> Date: Mon, 12 Apr 2010 10:31:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8973E6-EE3F-4E11-9B2E-37CCF11E04B2@amsl.com> References: <20100412140301.974A2E07AD@rfc-editor.org> To: lberger@movaz.com, Adrian Farrel , stbryant@cisco.com, Lou Berger , Deborah Brungard X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 12 Apr 2010 07:36:34 -0700 Cc: Sean Turner , ccamp@ietf.org, RFC Errata System Subject: [CCAMP] [Editorial Errata Reported] RFC3473 (2160) was: Re: [Select One Errata Reported] RFC3473 (2160) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:32:26 -0000 FYI, the Type of this errata report has been set to Editorial per Sean's = request: http://www.rfc-editor.org/errata_search.php?rfc=3D3473&eid=3D2160 (Apologies for the error; we're working on preventing this in the = future.) Thank you. RFC Editor/ah On Apr 12, 2010, at 10:03 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC3473, > "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource = ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3473&eid=3D2160 >=20 > -------------------------------------- >>=20 Type: Editorial > Reported by: Sean Turner >=20 > Section: 12 >=20 > Original Text > ------------- > Configured keys MAY be used. >=20 > Corrected Text > -------------- > Manually configured keys MAY be used. >=20 > Notes > ----- > Assumed that this sentence is talking about the opposite of an = automated key management system, which is manually configured keys. >=20 > 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.=20 >=20 > -------------------------------------- > RFC3473 (draft-ietf-mpls-generalized-rsvp-te-09) > -------------------------------------- > Title : Generalized Multi-Protocol Label Switching = (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering = (RSVP-TE) Extensions > Publication Date : January 2003 > Author(s) : L. Berger, Ed. > Category : PROPOSED STANDARD > Source : Common Control and Measurement Plane > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From wwwrun@core3.amsl.com Mon Apr 12 11:07:31 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4208A3A6AB4; Mon, 12 Apr 2010 11:07:31 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100412180731.4208A3A6AB4@core3.amsl.com> Date: Mon, 12 Apr 2010 11:07:31 -0700 (PDT) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 18:07:31 -0000 The IESG has approved the following document: - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-03.txt Technical Summary This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. Working Group Summary Nothing to report. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD RFC Editor Note RFC Editor - we suggest that you treat this I-D as part of a cluster including the following five documents. draft-ietf-ccamp-ethernet-traffic-parameters draft-ietf-ccamp-gmpls-dcsc-channel-ext draft-ietf-ccamp-gmpls-ether-svcs draft-ietf-ccamp-gmpls-mef-uni draft-ietf-ccamp-gmpls-mln-extensions --- Section 1 OLD LSPs NEW Label Switched Paths (LSPs) --- Section 4 OLD There is one additional UNI specific requirements for signaling LSPs supporting an EVPL type service. NEW There is one additional UNI specific requirement for signaling LSPs supporting an EVPL type service as described in section 4.1. --- Section 6 s/takes occurs/occurs/ From hhelvoort@chello.nl Mon Apr 12 14:01:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB623A6AD2; Mon, 12 Apr 2010 14:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bogJtyCKuqCx; Mon, 12 Apr 2010 14:01:55 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 5408A3A67B4; Mon, 12 Apr 2010 14:01:51 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20100412210145.VEDK14855.viefep12-int.chello.at@edge05.upcmail.net>; Mon, 12 Apr 2010 23:01:45 +0200 Received: from viefep13 ([192.168.14.250]) by edge05.upcmail.net with edge id 4l1j1e00b5PiXJQ05l1jXt; Mon, 12 Apr 2010 23:01:45 +0200 X-SourceIP: 192.168.14.250 Message-ID: <818048.1271106105040.JavaMail.root@viefep13> Date: Mon, 12 Apr 2010 21:01:43 +0000 From: To: IETF-Announce , The IESG MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal X-Originating-IP: from 81.229.83.21 by web-edge.chello.com; Mon, 12 Apr 2010 23:01:42 +0200 X-Cloudmark-Analysis: v=1.1 cv=SLkC287PFWo6d7eSEiSBB9255DBOWQ3bwOwHXJiyZoo= c=1 sm=0 a=s2ZjbxoLbqoA:10 a=QDFhbiTwE_kA:10 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=89Pdu4fVW1LWk2RtQsgA:9 a=Y-x-d_ZsXTM5ZxWFU2cfTjJkc_UA:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: ccamp mailing list , ccamp chair , Internet Architecture Board , RFC Editor Subject: Re: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support ForMetro Ethernet Forum and G.8011 User-Network Interface (UNI)'to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 21:01:57 -0000 Hello, On 12-04-10 20:07, The IESG wrote: > The IESG has approved the following document: > > - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 > User-Network Interface (UNI) ' > as a Proposed Standard > > > This document is the product of the Common Control and Measurement Plane Working Group. > > The IESG contact persons are Adrian Farrel and Stewart Bryant. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-03.txt The date on this document is October 14 2009, expiry April 2010. It still refers to: = G.8011 (08/2004) = G.8011.1 (08/2004) = G.8011.2 (09/2005) These recommendations have been superseded by: = G.8011 (01/2009) = G.8011.1 (01/2009) = G.8011.2 (01/2009) That are currently in force. Why the reference to superseded recommendations. FYI: there since 02/2010 there are also in force: G.8011.3 Ethernet virtual private LAN service G.8011.4 Ethernet virtual private rooted multipoint service G.8011.5 Ethernet private LAN service Shouldn't these have been included as well? Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... From Manuel.Paul@telekom.de Tue Apr 13 07:44:31 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30FFA28C1BC for ; Tue, 13 Apr 2010 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxAyJKfKcSz8 for ; Tue, 13 Apr 2010 07:44:30 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id E407928C0F2 for ; Tue, 13 Apr 2010 07:44:29 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 13 Apr 2010 16:44:17 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 16:44:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 16:44:17 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00429A726@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQFWeBMQ References: From: To: X-OriginalArrivalTime: 13 Apr 2010 14:44:17.0407 (UTC) FILETIME=[CB3E50F0:01CADB17] Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:44:31 -0000 yes/support Best regards, Manuel=20 =20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: Tuesday, April 06, 2010 9:17 PM > To: CCAMP > Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 >=20 > All, >=20 > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". >=20 > The poll ends Tuesday, April 20th. >=20 > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From lberger@labn.net Tue Apr 13 08:04:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24403A68CF for ; Tue, 13 Apr 2010 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgzFqIED9LQH for ; Tue, 13 Apr 2010 08:04:33 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id ABD803A6A4E for ; Tue, 13 Apr 2010 08:04:32 -0700 (PDT) Received: (qmail 28361 invoked by uid 0); 13 Apr 2010 15:04:25 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 13 Apr 2010 15:04:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=vY0o1+uKmzIzvZromSECjvKWGJFscntgtdDZKYTv7gduOoT1eSqzgYUUAuxzblbQPexp2L86YbyXH5OPdbtCKO/Rw4zgYhXY0oL3HDfy+lzqUxzYe8T4R5QQnjTQSH6q; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O1hf7-0000ik-PJ; Tue, 13 Apr 2010 09:04:25 -0600 Message-ID: <4BC487F9.1000502@labn.net> Date: Tue, 13 Apr 2010 11:04:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: hhelvoort@chello.nl References: <818048.1271106105040.JavaMail.root@viefep13> In-Reply-To: <818048.1271106105040.JavaMail.root@viefep13> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp chair , ccamp mailing list , Internet Architecture Board , The IESG , IETF-Announce , RFC Editor Subject: Re: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support ForMetro Ethernet Forum and G.8011 User-Network Interface (UNI)'to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:04:34 -0000 Huub, Sometimes our process takes longer than we'd like. The last substantive technical change by the WG was in August 2008, with WG LC in January 2009. In order to make the changes to the references, the WG would need to ensure that there was no technical changes as a result of the 2009/2010 versions of the G.8011 documents. As this review has not been done, I don't think changes to the references are appropriate. Lou (as co-author) On 4/12/2010 5:01 PM, hhelvoort@chello.nl wrote: > Hello, > > On 12-04-10 20:07, The IESG wrote: >> The IESG has approved the following document: >> >> - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 >> User-Network Interface (UNI) ' >> as a Proposed Standard >> >> >> This document is the product of the Common Control and Measurement Plane Working Group. >> >> The IESG contact persons are Adrian Farrel and Stewart Bryant. >> >> A URL of this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-03.txt > > The date on this document is October 14 2009, expiry April 2010. > > It still refers to: > = G.8011 (08/2004) > = G.8011.1 (08/2004) > = G.8011.2 (09/2005) > > These recommendations have been superseded by: > = G.8011 (01/2009) > = G.8011.1 (01/2009) > = G.8011.2 (01/2009) > That are currently in force. > Why the reference to superseded recommendations. > > FYI: there since 02/2010 there are also in force: > G.8011.3 Ethernet virtual private LAN service > G.8011.4 Ethernet virtual private rooted multipoint service > G.8011.5 Ethernet private LAN service > Shouldn't these have been included as well? > > Regards, Huub. > From wwwrun@core3.amsl.com Tue Apr 13 16:11:08 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 873AA3A694F; Tue, 13 Apr 2010 16:11:08 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100413231108.873AA3A694F@core3.amsl.com> Date: Tue, 13 Apr 2010 16:11:08 -0700 (PDT) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 23:11:08 -0000 The IESG has approved the following document: - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-04.txt Technical Summary This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF and ITU defined parameters is also covered. Working Group Summary Nothing to report. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD RFC Editor Note RFC Editor - we suggest that you treat this I-D as part of a cluster including the following five documents. draft-ietf-ccamp-ethernet-traffic-parameters draft-ietf-ccamp-gmpls-dcsc-channel-ext draft-ietf-ccamp-gmpls-ether-svcs draft-ietf-ccamp-gmpls-mef-uni draft-ietf-ccamp-gmpls-mln-extensions --- Section 2.1 OLD supports the Ethernet endpoint identifier similar to [RFC4974] supports the long call ID. NEW supports the Ethernet endpoint identifier similar to how [RFC4974] supports the long call ID. --- Section 8 OLD This document introduces no new security considerations to either [RFC3473]. NEW This document introduces no new security considerations to [RFC3473]. IANA Note IANA - Please note that this I-D uses a registry created by draft-ietf-ccamp-gmpls-mln-extensions which is also in the pipeline. From zhangguoying2010@gmail.com Tue Apr 13 20:43:06 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10FB28C1DD for ; Tue, 13 Apr 2010 20:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.233 X-Spam-Level: *** X-Spam-Status: No, score=3.233 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, FR_IMPORT_CSS=1.889, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVjQcmsJPaWm for ; Tue, 13 Apr 2010 20:43:06 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id E7D0B28C1A9 for ; Tue, 13 Apr 2010 20:43:05 -0700 (PDT) Received: by iwn27 with SMTP id 27so6133140iwn.5 for ; Tue, 13 Apr 2010 20:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:references :subject:message-id:x-mailer:mime-version:content-type; bh=+377y8FckR2EQccoZukDAb1vQRNvwpnhNabTP6B+zwY=; b=uG2yGWt7408cbA4KCHhtqNNrHQNvMj+4SNnqLBTecwVDnL+obW1xnmQJvX+ATbYGzy Pc4c5FQPQFKtiTSF/G/55zDb6PJxqwHKWVhz+Exi3Jza4bhBdcrn+U7NEGaCIN9E9sAp pgkI6wLZQDjQ4CgcfyRfIaDJhFFJPBPnriM8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:references:subject:message-id:x-mailer:mime-version :content-type; b=sW5p+qRaUG6nIluUqF0YZhtsywccBLhjgC76D6tPfwGKDZXDCkH490kwWM0wXZephb 6iNyG4aNF5Q7RDTPiG//u7O8mK5S9czcGkkvG01XezHza7afI+m8LDrK+EUha2/Px79L jl2xI99t7h93KsUAHjlhz51tHttNSYjtLZYoI= Received: by 10.231.190.197 with SMTP id dj5mr3042089ibb.58.1271216577177; Tue, 13 Apr 2010 20:42:57 -0700 (PDT) Received: from gyzhang ([114.255.163.12]) by mx.google.com with ESMTPS id co35sm3532360ibb.20.2010.04.13.20.42.55 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 20:42:56 -0700 (PDT) Date: Wed, 14 Apr 2010 11:43:20 -0700 From: "zhangguoying" To: "ccamp@ietf.org" References: Message-ID: <201004141143168437164@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon307381653155_=====" Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 03:43:06 -0000 This is a multi-part message in MIME format. --=====003_Dragon307381653155_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Yes/Support. 2010-04-14 zhangguoying [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=====003_Dragon307381653155_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+QGltcG9ydCB1cmwoIEM6 XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcemhhbmdndW95aW5nXExvY2FsIFNldHRpbmdzXFRlbXBv cmFyeSBJbnRlcm5ldCBGaWxlc1xzY3JvbGxiYXIuY3NzICk7DQo8L1NUWUxFPg0KDQo8TUVUQSBo dHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9R0IyMzEy Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjYwMDAuMTY5ODEiIG5hbWU9R0VORVJBVE9S Pg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFj ZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWls eTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJn aW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0K UC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElG WTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9 DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1T SVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3 IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsg VEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xP UjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09M T1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJs aW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5l DQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdp bmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQt REVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJ Vi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTog MTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAw cHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1C T1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4 DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4 MCBzaXplPTI+WWVzL1N1cHBvcnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRh bmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAxMC0wNC0xNCA8L0ZP TlQ+PC9ESVY+PEZPTlQgDQpmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFIg c3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIGFsaWduPWxlZnQgU0laRT0yPg0KPC9G T05UPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2MwYzBjMCBzaXplPTI+PFNQQU4+ emhhbmdndW95aW5nPC9TUEFOPiANCjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s b3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBzaXplPTI+W0NDQU1QXSBwb2xsIG9uIA0KZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1m cmFtZXdvcmstMDIgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxESVY+QWxs LDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhpcyZuYnNwO2lzJm5ic3A7dG8mbmJzcDtzdGFy dCZuYnNwO2EmbmJzcDt0d28mbmJzcDt3ZWVrJm5ic3A7cG9sbCZuYnNwO29uJm5ic3A7bWFraW5n PC9ESVY+DQo8RElWPmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAyLnR4 dCZuYnNwO2EmbmJzcDtjY2FtcCZuYnNwO3dvcmtpbmcmbmJzcDtncm91cDwvRElWPg0KPERJVj5k b2N1bWVudC4mbmJzcDtTZW5kJm5ic3A7YSZuYnNwO21haWwmbmJzcDt0byZuYnNwO3RoZSZuYnNw O21haWxpbmcmbmJzcDtsaXN0Jm5ic3A7aW5kaWNhdGluZyZuYnNwOyJ5ZXMvc3VwcG9ydCImbmJz cDtvcjwvRElWPg0KPERJVj4ibm8vZG8mbmJzcDtub3QmbmJzcDtzdXBwb3J0Ii48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO3BvbGwmbmJzcDtlbmRzJm5ic3A7VHVlc2RheSwmbmJz cDtBcHJpbCZuYnNwOzIwdGguPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5EZWJvcmFoPC9ESVY+ DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9E SVY+DQo8RElWPkNDQU1QJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+Q0NBTVBA aWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcDwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon307381653155_=====-- From Adrian.Farrel@huawei.com Wed Apr 14 03:41:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCB73A68C1; Wed, 14 Apr 2010 03:41:57 -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, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU1JUl+CG4Sy; Wed, 14 Apr 2010 03:41:56 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 780293A6989; Wed, 14 Apr 2010 03:41:48 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0V00MYJ4DISJ@usaga03-in.huawei.com>; Wed, 14 Apr 2010 05:41:42 -0500 (CDT) Received: from your029b8cecfe (static-213-115-148-132.sme.bredbandsbolaget.se [213.115.148.132]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0V00BND4DF7P@usaga03-in.huawei.com>; Wed, 14 Apr 2010 05:41:42 -0500 (CDT) Date: Wed, 14 Apr 2010 09:38:40 +0100 From: Adrian Farrel To: hhelvoort@chello.nl Message-id: <334ECFE521EA4B47BC6F4EC023780C45@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <818048.1271106105040.JavaMail.root@viefep13> Cc: ccamp mailing list , ccamp chair , iesg@ietf.org, RFC Editor Subject: Re: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support ForMetro Ethernet Forum and G.8011 User-Network Interface (UNI)'to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 10:41:57 -0000 Hello Huub, [Recipient list massaged] As I understand it, the CCAMP working group decided to work on MEF 6 first (in the knowledge that there may be value in returning to work on MEF 6.1 in the future). The Recommendations that you list are the revisions that co-existed with MEF 6. At such time as the working group decides to synchronise with MEF 6.1 (contributions are welcome!) the work will also need to synchronise with the revisions of the Recommendations that are in the same timeframe. Therefore, at this stage, no changes to this RFC-to-be are needed. Does that make sense? Cheers, Adrian ----- Original Message ----- From: To: "IETF-Announce" ; "The IESG" Cc: "ccamp mailing list" ; "ccamp chair" ; "Internet Architecture Board" ; "RFC Editor" Sent: Monday, April 12, 2010 10:01 PM Subject: Re: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Support ForMetro Ethernet Forum and G.8011 User-Network Interface (UNI)'to Proposed Standard > Hello, > > On 12-04-10 20:07, The IESG wrote: >> The IESG has approved the following document: >> >> - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 >> User-Network Interface (UNI) ' >> as a Proposed Standard >> >> >> This document is the product of the Common Control and Measurement Plane >> Working Group. >> >> The IESG contact persons are Adrian Farrel and Stewart Bryant. >> >> A URL of this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-03.txt > > The date on this document is October 14 2009, expiry April 2010. > > It still refers to: > = G.8011 (08/2004) > = G.8011.1 (08/2004) > = G.8011.2 (09/2005) > > These recommendations have been superseded by: > = G.8011 (01/2009) > = G.8011.1 (01/2009) > = G.8011.2 (01/2009) > That are currently in force. > Why the reference to superseded recommendations. > > FYI: there since 02/2010 there are also in force: > G.8011.3 Ethernet virtual private LAN service > G.8011.4 Ethernet virtual private rooted multipoint service > G.8011.5 Ethernet private LAN service > Shouldn't these have been included as well? > > Regards, Huub. > > -- > ================================================================ > Always remember that you are unique...just like everyone else... > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From giomarti@cisco.com Wed Apr 14 04:28:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE4228C191 for ; Wed, 14 Apr 2010 04:28:12 -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=-4.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4GrEExJ6+Tv for ; Wed, 14 Apr 2010 04:28:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 28C2828C1AA for ; Wed, 14 Apr 2010 04:25:13 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0BACZDxUuQ/uCWe2dsb2JhbACbWBUBAQsLIgYco0aZcYUNBA X-IronPort-AV: E=Sophos;i="4.52,204,1270425600"; d="scan'208,217";a="5564593" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 14 Apr 2010 10:49:15 +0000 Received: from [10.61.84.7] (ams3-vpn-dhcp5128.cisco.com [10.61.84.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3EBP5P2021249; Wed, 14 Apr 2010 11:25:05 GMT Message-ID: <4BC5A679.6010104@cisco.com> Date: Wed, 14 Apr 2010 13:26:49 +0200 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100305 Lightning/1.0b2pre Thunderbird/3.0.3 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A (ATTLABS)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080509040808050009050408" Cc: CCAMP Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 11:28:12 -0000 This is a multi-part message in MIME format. --------------080509040808050009050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes/support On 04/06/2010 09:17 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote: > All, > > This is to start a two week poll on making > draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Tuesday, April 20th. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --------------080509040808050009050408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes/support

On 04/06/2010 09:17 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote: 
All,

This is to start a two week poll on making
draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Tuesday, April 20th.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--------------080509040808050009050408-- From swallow@cisco.com Fri Apr 16 09:45:40 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DDB028C108; Fri, 16 Apr 2010 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVxLE3fUYBD6; Fri, 16 Apr 2010 09:45:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6C1C528C11F; Fri, 16 Apr 2010 09:45:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOowyEutJV2Y/2dsb2JhbACbc3GlQJodAoJXgjUE X-IronPort-AV: E=Sophos;i="4.52,220,1270425600"; d="scan'208";a="102431787" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2010 16:45:27 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o3GGjRsc007266; Fri, 16 Apr 2010 16:45:27 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 11:45:27 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Apr 2010 16:45:27 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 16 Apr 2010 12:45:25 -0400 From: George Swallow To: Attila Takacs , Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtc= In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Apr 2010 16:45:27.0723 (UTC) FILETIME=[37EDBFB0:01CADD84] Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 16:45:40 -0000 On 4/2/10 2:53 AM, "Attila Takacs" wrote: > Hi Matthew and George, > > Please find some comments/questions below. > > -In Section 5.1 you have: > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? Existing implementations of RSVP-TE have used the tunnel space as global to the node. It is difficult if not impossible to coordinate such spaces between nodes. In RSVP-TE the coordination does not matter, since the tail end of the tunnel doesn't have a real interface - it only receives and usually with a PHP of the tunnel label, so the packets only belong to the physical interface. In a bidirectional world, separate tunnel spaces at the two ends becomes useful. If this independence is not need is some environments then one can configure just one value and use it in both fields. > Is it there to support associated unidirectional Tunnels/LSPs? If so it should > be called out in the text. That was not my original intent, but you are quite correct that this would be very useful. Particularly if the associated tunnels pass through a share mid-point somewhere along the path. > Same applies to the globally unique case. Of course. > -In Section 5.2 you simply append one LSP_Num to the above. This is a bit > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would be > needed too, wouldn't it? Once, you have independent tunnel-ids, coordination of the LSP numbers becomes easy. It also could be used to allow the two ends to readily identify which is working and which is protection. > -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Num. So > this means that we may have two different tunnels identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, > e.g., the associated unidirectional case? For the associated unidirectional, this works perfectly. For bidirectional, I was thinking of two options. 1) Strict binding - both ends are configure with the full identifier and will only accept the connection if everything matches. 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV message would carry back the destination's tunnel_num. Note that both ends need both pieces for some of the OAM to work. > This should be clarified. I'll see what I can do. But this is not supposed to the MPLS-TP signaling draft. > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. I'm planning to keep it. > -Section 7 has a note saying to be aligned with the OAM fwk, is this still to > be done? Yes. That draft is also being updated. We appear to be converging. > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel level > and not at the LSP level? > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? I had been told early on that MEGs were needed for tunnels. Now getting comments that they are not (same comment is in the ITU liaison). So I planning to remove it, unless I hear other opinions. > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. See above. > -Section 8 talks about open issues? When will these be addressed? Before it is re-issued. Goal is end of next week. ...George > Thanks, > Attila > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Friday, March 12, 2010 12:33 AM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >> >> All, >> >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >> >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >> >> >> Please send your comments to the mpls-tp@ietf.org mailing list. >> >> The working group last ends eob April 2nd. >> >> /Loa >> >> -- >> >> Loa Andersson >> >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> email: loa.andersson@ericsson.com >> loa@pi.nu >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lberger@labn.net Mon Apr 19 09:43:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327CD3A6B2F for ; Mon, 19 Apr 2010 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swc79ue+m5ij for ; Mon, 19 Apr 2010 09:43:28 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 1636928C23B for ; Mon, 19 Apr 2010 09:25:03 -0700 (PDT) Received: (qmail 9730 invoked by uid 0); 19 Apr 2010 16:24:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 19 Apr 2010 16:24:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=rKqaCRlVobPqIxTEIN7z5BG41s4nLJlW6AMEjO9xbDNQROtdbbs5JI3sw7hQm+0IauZ24iXiJ9yAf8u5jW4zW/tj0uZWJb29iP6ShvDfAkful0dQMdyv7oB1Whv/jfYA; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O3tmI-00070C-DV for ccamp@ietf.org; Mon, 19 Apr 2010 10:24:54 -0600 Message-ID: <4BCC83E0.1000001@labn.net> Date: Mon, 19 Apr 2010 12:25:04 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Working group last call: draft-ietf-ccamp-rwa-wson-framework-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 16:43:29 -0000 This email begins a two week working group last call on draft-ietf-ccamp-rwa-wson-framework-06. http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-06 Please send your comments to the list or the authors&chairs before the last call closes in two weeks, on May 3rd. Thank you, Lou (and Deborah) From maarten.vissers@huawei.com Wed Apr 21 00:12:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FFF3A6A40; Wed, 21 Apr 2010 00:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.403 X-Spam-Level: X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bw12F2QPETi8; Wed, 21 Apr 2010 00:12:16 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0C3F03A6A3C; Wed, 21 Apr 2010 00:12:16 -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 <0L1700C1LTACA9@szxga04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Received: from 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 <0L1700L0OTACIZ@szxga04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L17000G9TA8ZQ@szxml04-in.huawei.com>; Wed, 21 Apr 2010 15:11:00 +0800 (CST) Date: Wed, 21 Apr 2010 09:11:02 +0200 From: Maarten Vissers In-reply-to: To: 'George Swallow' , mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, ccamp@ietf.org Message-id: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwA== References: <79F41BA1E9BF3C489375521EF8DDE23C12B1B1A5BB@ESESSCMS0355.eemea.ericsson.se> Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:12:18 -0000 George, It is a bad practice to identify a connection (e.g. LSP) within the scope of their server layer trail (e.g. tunnel LSP). Reason is that a connection (e.g. LSP) is typically carried by multiple server layer trails (e.g. tunnel LSPs). Example: a service-LSP X is carried over three transport-LSPs A,B,C: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| It is possible to reroute this service-LSP and change it as follows: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| or as follows: |<----------------service-LSP_X------------------->| |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| The service-LSP X is still the same service-LSP with the same service-LSP MEP functions, only the path through the MPLS-TP network has been changed. Identification with respect to the server layer trail (e.g. tunnel LSP) is appropriate for a link connection (e.g. LSP segment). The service-LSP X has three service-LSP segments. Those segments are identified with respect to their tunnel; i.e. with respect to the transport-LSP in this example. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow Sent: vrijdag 16 april 2010 18:45 To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: Re: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 On 4/2/10 2:53 AM, "Attila Takacs" wrote: > Hi Matthew and George, > > Please find some comments/questions below. > > -In Section 5.1 you have: > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? Existing implementations of RSVP-TE have used the tunnel space as global to the node. It is difficult if not impossible to coordinate such spaces between nodes. In RSVP-TE the coordination does not matter, since the tail end of the tunnel doesn't have a real interface - it only receives and usually with a PHP of the tunnel label, so the packets only belong to the physical interface. In a bidirectional world, separate tunnel spaces at the two ends becomes useful. If this independence is not need is some environments then one can configure just one value and use it in both fields. > Is it there to support associated unidirectional Tunnels/LSPs? If so > it should be called out in the text. That was not my original intent, but you are quite correct that this would be very useful. Particularly if the associated tunnels pass through a share mid-point somewhere along the path. > Same applies to the globally unique case. Of course. > -In Section 5.2 you simply append one LSP_Num to the above. This is a > bit confusing to me, if there are Src/Dst Tunnel_Nums then two > LSP_Nums would be needed too, wouldn't it? Once, you have independent tunnel-ids, coordination of the LSP numbers becomes easy. It also could be used to allow the two ends to readily identify which is working and which is protection. > -In Section 5.3 Mapping to GMPLS signaling does not use the > Dst-Tunnel_Num. So this means that we may have two different tunnels > identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intentional, e.g., the associated unidirectional case? For the associated unidirectional, this works perfectly. For bidirectional, I was thinking of two options. 1) Strict binding - both ends are configure with the full identifier and will only accept the connection if everything matches. 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV message would carry back the destination's tunnel_num. Note that both ends need both pieces for some of the OAM to work. > This should be clarified. I'll see what I can do. But this is not supposed to the MPLS-TP signaling draft. > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. I'm planning to keep it. > -Section 7 has a note saying to be aligned with the OAM fwk, is this > still to be done? Yes. That draft is also being updated. We appear to be converging. > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the > Tunnel level and not at the LSP level? > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? I had been told early on that MEGs were needed for tunnels. Now getting comments that they are not (same comment is in the ITU liaison). So I planning to remove it, unless I hear other opinions. > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. See above. > -Section 8 talks about open issues? When will these be addressed? Before it is re-issued. Goal is end of next week. ...George > Thanks, > Attila From neil.2.harrison@bt.com Wed Apr 21 00:37:58 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8219B3A688D; Wed, 21 Apr 2010 00:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0gCVyMW0XGR; Wed, 21 Apr 2010 00:37:57 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B6FCC3A6A0F; Wed, 21 Apr 2010 00:37:56 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 08:37:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 08:37:43 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5Q From: To: , , , , , X-OriginalArrivalTime: 21 Apr 2010 07:37:46.0771 (UTC) FILETIME=[89572630:01CAE125] Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:37:58 -0000 Maarten...agreed...but there is also a worrying addressing problem in all this IMO that does not seem to be recognised/understood. In summary, a layer network (any mode/technology, not just co-ps/MPLS-TP say) is most essentially characterised by its access point addressing scheme...screw this up on day 1 and it is very hard to change later. MPLS originally never had proper addressing allocated to it...largely due to is binding with the cl-ps mode IP layer network it could never be seen as a layer network in its own right (part of the common control-plane flaw - I come back on this later). Further, each LSP here was a *sublayer* and part of the same hybrid/MPLS/IP layer network. Moreover, each LSP (label distribution) signalling type created its own form of addressing for how it wanted to identify its type of access points. PWs made the situation significantly worse when they became multi-hop. These suddenly jumped from an adaptation role to a full blown layer network in their own right. So they needed their own addressing scheme (and OAM, LDP signalling, etc),...which is what all the AII stuff is. Not a great addressing structure I should add, we should have used v4 or v6 but the problem dogging this stuff was that we were still claiming this was all part of the same IP/MPLS layer network =3D> can also read = as same instance of routing.....something we should know now is a flawed notion for MPLS-T based on lessons learnt from GMPLS (I originally pointed this 'common CP nonsense' out at 2000 San Diego IETF mtg). Now MPLS-TP is supposed to be a transport network. So each LSP in a nested case should be in its own layer network....this is essentially what you shown below. MPLS-TP therefore does not need sublayering as per the old type of MPLS...and it for sure should not be generating a PW layer network, that simply indicates a failure to deliver a transport network and just propagates the error made in MPLS. However, because some folks want to retain the S bit notion and the old type of sublayering in MPLS-TP, we have no way of knowing whether a set of nested LSPs belong to different layer networks or are sublayers in some arbitary layer network grouping. The DP looks the same in all cases. I can see all sorts of problems brewing here in correctly identify which layer network a given LSP belongs to...esp if there are multiple parties involved in both client/server and peer-partition sense.=20 regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 21 April 2010 08:11 > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org;=20 > pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on=20 > draft-ietf-mpls-tp-identifiers-01 >=20 > George, >=20 > It is a bad practice to identify a connection (e.g. LSP)=20 > within the scope of their server layer trail (e.g. tunnel=20 > LSP). Reason is that a connection (e.g. LSP) is typically=20 > carried by multiple server layer trails (e.g. tunnel LSPs).=20 > Example: a service-LSP X is carried over three transport-LSPs A,B,C: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| >=20 > It is possible to reroute this service-LSP and change it as follows: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| >=20 > or as follows: >=20 > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| >=20 > The service-LSP X is still the same service-LSP with the same=20 > service-LSP MEP functions, only the path through the MPLS-TP=20 > network has been changed. >=20 > Identification with respect to the server layer trail (e.g.=20 > tunnel LSP) is appropriate for a link connection (e.g. LSP=20 > segment). The service-LSP X has three service-LSP segments.=20 > Those segments are identified with respect to their tunnel;=20 > i.e. with respect to the transport-LSP in this example. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > Sent: vrijdag 16 april 2010 18:45 > To: Attila Takacs; Loa Andersson; mpls@ietf.org;=20 > mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 >=20 >=20 >=20 >=20 > On 4/2/10 2:53 AM, "Attila Takacs" wrote: >=20 > > Hi Matthew and George, > >=20 > > Please find some comments/questions below. > >=20 > > -In Section 5.1 you have: > >=20 > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > >=20 > > What is the reason of having a Dst-Tunnel_Num besides the=20 > Src-Tunnel_Num? >=20 > Existing implementations of RSVP-TE have used the tunnel=20 > space as global to the node. It is difficult if not=20 > impossible to coordinate such spaces between nodes. In=20 > RSVP-TE the coordination does not matter, since the tail end=20 > of the tunnel doesn't have a real interface - it only=20 > receives and usually with a PHP of the tunnel label, so the=20 > packets only belong to the physical interface. >=20 > In a bidirectional world, separate tunnel spaces at the two=20 > ends becomes useful. =20 >=20 > If this independence is not need is some environments then=20 > one can configure just one value and use it in both fields. >=20 > > Is it there to support associated unidirectional=20 > Tunnels/LSPs? If so=20 > > it should be called out in the text. >=20 > That was not my original intent, but you are quite correct=20 > that this would be very useful. Particularly if the=20 > associated tunnels pass through a share mid-point somewhere=20 > along the path. >=20 > > Same applies to the globally unique case. >=20 > Of course. >=20 > > -In Section 5.2 you simply append one LSP_Num to the above.=20 > This is a=20 > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two=20 > > LSP_Nums would be needed too, wouldn't it? >=20 > Once, you have independent tunnel-ids, coordination of the=20 > LSP numbers becomes easy. It also could be used to allow the=20 > two ends to readily identify which is working and which is protection. >=20 > > -In Section 5.3 Mapping to GMPLS signaling does not use the=20 > > Dst-Tunnel_Num. So this means that we may have two=20 > different tunnels=20 > > identified with=20 > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > intentional, e.g., the associated unidirectional case? >=20 > For the associated unidirectional, this works perfectly. For=20 > bidirectional, I was thinking of two options. >=20 > 1) Strict binding - both ends are configure with the full=20 > identifier and will only accept the connection if everything matches. >=20 > 2) Dynamic binding - Source signals with just its=20 > Tunnel_Num. RESV message would carry back the destination's=20 > tunnel_num. Note that both ends need both pieces for some of=20 > the OAM to work. >=20 > > This should be clarified. >=20 > I'll see what I can do. But this is not supposed to the=20 > MPLS-TP signaling draft. > =20 > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. >=20 > I'm planning to keep it. > =20 > > -Section 7 has a note saying to be aligned with the OAM=20 > fwk, is this=20 > > still to be done? >=20 > Yes. That draft is also being updated. We appear to be converging. >=20 > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > How would Tunnel and LSP MEGs be used? What OAM would run at the=20 > > Tunnel level and not at the LSP level? > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? >=20 > I had been told early on that MEGs were needed for tunnels. =20 > Now getting comments that they are not (same comment is in=20 > the ITU liaison). So I planning to remove it, unless I hear=20 > other opinions. >=20 > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. >=20 > See above. >=20 > > -Section 8 talks about open issues? When will these be addressed? >=20 > Before it is re-issued. Goal is end of next week. >=20 > ...George >=20 > > Thanks, > > Attila >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From maarten.vissers@huawei.com Wed Apr 21 02:06:33 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B2F3A677D; Wed, 21 Apr 2010 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsidvSCI9VWH; Wed, 21 Apr 2010 02:06:32 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C543A3A684A; Wed, 21 Apr 2010 02:06:30 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700FTXYM7LC@szxga02-in.huawei.com>; Wed, 21 Apr 2010 17:06:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700DF7YM69G@szxga02-in.huawei.com>; Wed, 21 Apr 2010 17:06:06 +0800 (CST) Received: from M00900002 ([10.202.112.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L17000X3YM2ZN@szxml04-in.huawei.com>; Wed, 21 Apr 2010 17:06:06 +0800 (CST) Date: Wed, 21 Apr 2010 11:06:07 +0200 From: Maarten Vissers In-reply-to: <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> To: neil.2.harrison@bt.com, swallow@cisco.com, mpls@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, ccamp@ietf.org Message-id: <98ED265C742D4598AAAD6B8CC7C2DB81@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5QAAJ4WtA= References: <69994A6066394E90B25BB721C3CA3BFF@china.huawei.com> <2ECAA42C79676B42AEBAC11229CA7D0C05D5072C@E03MVB2-UKBR.domain1.systemhost.net> Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:06:34 -0000 Neil, There are three MPLS-TP layer netowrks defined: 1) Transport Service layer network (including MS-PWs, Service-LSPs, PST-LSPs) 2) Transport Path layer network (including Transport-LSPs, PST-LSPs) 3) Section layer network (including Section-LSPs, PST-LSPs). Each of those three MPLS-TP layer networks has two types of sub-layers defined: A) TCM sub-layer with a 1:1 relation (for admin domain monitoring and SNC/S protection switching applications) B) TCM sub-layer with a n:1 relation (for some protection switching applciations) which are supported by PST-LSPs. The three layer networks have Access Points, and those APs are identified by means of an Access Point Identifier. The sub-layers have sub-layer Access Points, and those sub-layer APs are identified by means of a sub-layer Access Point Identifier. [Note - We need to understand what the IETF equivalent of the ITU-T Access Point is... See below the '-----' for my view on this based on a question I received on what the equivalent ITU-T construct would be for an IETF 'interface'.] The MPLS-TP data plane does not demarc the boundary between those layer networks or between a layer and its sublayers. This is a clear difference with similar layer/sublayer structures in OTN ODU and Ethernet ETH layers; in those two technologies there is a clear demarcation between layer networks and between the layer network signal and its sublayers. But we have to ask ourselves the question if this would be an issue... Most likely not because of the following: Transport Service, Transport Path and Section layer names represent roles in a domain. A Transport-LSP in domain A can be passed through a domain B in which it is considered to be a Service-LSP. Similarly, a Section-LSP in domain A can be passed through a domain B in which it is considered to be a Service-LSP. And it is even possible to have a Section-LSP in domain A which is passed through a domain B as Service-LSP and is then handed of to domain C as a Transport-LSP. This role variability is also present in the OTN ODU and Ethernet ETH layers, so there is commonality between those three technologies at this point. The implication is that the Access Point in e.g. a MPLS-TP Section layer or Ethernet Virtual Section layer could be connected with an Access Point in a MPLS-TP Transport Path or Ethernet Virtual Path layer. This capability is of course a feature and not a bug, and the implication is that the access point identification scheme should be agnostic to the operational role names of the layer networks in each domain. ----------- I was asked the question what the ITU-T equivalent of the IETF 'interface' would be. It could be that this equivalent is the 'access point'. The access points demark a trail in a layer network and access points are identified by means of their 'access point identifier (APId)'. If you look at clause 8.6.1 in G.7710 http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find in figure 23 a description of how the APId is used to identify the other reference points (termination connection point, connection point). In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you find the following features of the access points: ---------- The features of Access Point Identifiers (APIs) are: - each access point identifier must be globally unique in its layer network; - where it may be expected that the access point may be required for path set-up across an inter-operator boundary, the access point identifier must be available to other network operators; - the access point identifier should not change while the access point remains in existence; - the access point identifier should be able to identify the country and network operator which is responsible for routing to and from the access point; - the set of all access point identifiers belonging to a single administrative layer network should form a single access point identification scheme; - the scheme of access point identifiers for each administrative layer network can be independent from the scheme in any other administrative layer network. The API shall begin with either the country code as defined in ITU-T E.164 (one, two or three numeric characters) or, the three alphabetic character country code as defined in ISO 3166. The remainder of the API characters that follow the country code shall be a matter for the organization to whom the country code has been assigned, provided that uniqueness is guaranteed. These characters may be any alphanumeric characters as defined in ITU-T T.50 (International Reference Version - 7-bit coded character set for information interchange). The alphanumeric character set consists of the characters "a" to "z", "A" to "Z", and "0" to "9". In the case where the API uses less than fifteen characters, the API will be padded (extended) with the T.50 "NUL" character to get a fifteen byte character string. ------------ Applying this AP, CP and TCP identification in MPLS-TP you would get the following: - PW access points demark the PW trail - PW termination connection points demark the PW network connection - LSP access points demark the LSP trail - LSP termination connection points demark the LSP network connection A PW trail and network connection are identified (PW_TID, PW_NCID) by means of their PW APId set for a p2p PW and for a p2mp PW. A LSP trail and network connection are identified (LSP_TID, LSP_NCID) by means of their LSP APId set for a p2p LSP and for a p2mp LSP. - a LSP carries one or more client LSPs and/or PWs and/or VPLSs. The client LSP connection points are identified by means of the LSP APId plus the client_LSP label value. The client PW connection points are identified by means of the LSP APId plus the client_PW label value. The client VPLS (i.e. ETH) flow points are identified by means of the LSP APId plus the client_VPLS (i.e. PW) label value. - a PW may carry one or more client LSPs. The client LSP connection points are identified by means of the PW APId plus the client_LSP label value. - a PW may carry one or more client VLANs. The client VLAN (i.e. ETH) flow points are identified by means of the PW APId plus the client_VLAN VLAN ID (VID) or Service instance ID (SID) value. The client connection/flow points demark a client link connection. A client_LSP or _VLAN link connection supported by a PW trail is then identified by the PW trail identifier (i.e. plus the client label or VID/SID value. A client_LSP/PW/VPLS link connection supported by a LSP trail is then identified by the LSP trail identifier (i.e. plus the client LSP or PW label value (LSP__LCID, PW_LCID, VPLS_LCID). A PW (or LSP) trail contains of one or more PW (or LSP) link connections with unique identifiers. This implies that one PW (or LSP) trail/network connection identifier is related to a set of PW (or LSP) link connection identifiers; e.g. PW_TID/PW_NCID <=> {PW_LCID_a,PW_LCID_b, ...} ------------ PWs and LSPs represent layer network trails and sublayer network trails in the MPLS-TP Transport Service, Transport Path and Section layer networks. An overview: Transport Service layer network: - MPLS-TP PW trail - MPLS-TP service-LSP trail [- ETH VPLS connectionless trail] - MPLS-TP PST-LSP sublayer trail Transport Path layer network: - MPLS-TP transport-LSP trail - MPLS-TP PST-LSP sublayer trail Section layer network: - MPLS-TP section-LSP trail - MPLS-TP PST-LSP sublayer trail Note that the PST-LSP sublayer trails performing a TCM function are dependent on the layer trails. If a layer trail is deleted all associated PST-LSP sublayer trails have to be deleted as well. In MPLS-TP these sublayer trails perform a complete encapsulation of the layer trail and/or client-sublayer trail. This is different from sublayer trails in SDH, OTN, ATM and Ethernet networks. In those latter network technologies a sublayer trail just adds an additional level of OAM without further encapsulating the incoming signal. As a consequence in those latter networks the addition or removal of a sublayer does not change the set of link connections in the trail/network connection. In MPLS-TP we have to decide if we follow the same model, or if we consider that the addition of a sublayer (i.e. a PST-LSP) changes the number of link connections in the layer trail/network connection. Regards, Maarten -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: woensdag 21 april 2010 9:38 To: maarten.vissers@huawei.com; swallow@cisco.com; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: RE: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Maarten...agreed...but there is also a worrying addressing problem in all this IMO that does not seem to be recognised/understood. In summary, a layer network (any mode/technology, not just co-ps/MPLS-TP say) is most essentially characterised by its access point addressing scheme...screw this up on day 1 and it is very hard to change later. MPLS originally never had proper addressing allocated to it...largely due to is binding with the cl-ps mode IP layer network it could never be seen as a layer network in its own right (part of the common control-plane flaw - I come back on this later). Further, each LSP here was a *sublayer* and part of the same hybrid/MPLS/IP layer network. Moreover, each LSP (label distribution) signalling type created its own form of addressing for how it wanted to identify its type of access points. PWs made the situation significantly worse when they became multi-hop. These suddenly jumped from an adaptation role to a full blown layer network in their own right. So they needed their own addressing scheme (and OAM, LDP signalling, etc),...which is what all the AII stuff is. Not a great addressing structure I should add, we should have used v4 or v6 but the problem dogging this stuff was that we were still claiming this was all part of the same IP/MPLS layer network => can also read as same instance of routing.....something we should know now is a flawed notion for MPLS-T based on lessons learnt from GMPLS (I originally pointed this 'common CP nonsense' out at 2000 San Diego IETF mtg). Now MPLS-TP is supposed to be a transport network. So each LSP in a nested case should be in its own layer network....this is essentially what you shown below. MPLS-TP therefore does not need sublayering as per the old type of MPLS...and it for sure should not be generating a PW layer network, that simply indicates a failure to deliver a transport network and just propagates the error made in MPLS. However, because some folks want to retain the S bit notion and the old type of sublayering in MPLS-TP, we have no way of knowing whether a set of nested LSPs belong to different layer networks or are sublayers in some arbitary layer network grouping. The DP looks the same in all cases. I can see all sorts of problems brewing here in correctly identify which layer network a given LSP belongs to...esp if there are multiple parties involved in both client/server and peer-partition sense. regards, Neil > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > Sent: 21 April 2010 08:11 > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; > ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 > > George, > > It is a bad practice to identify a connection (e.g. LSP) within the > scope of their server layer trail (e.g. tunnel LSP). Reason is that a > connection (e.g. LSP) is typically carried by multiple server layer > trails (e.g. tunnel LSPs). > Example: a service-LSP X is carried over three transport-LSPs A,B,C: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| > > It is possible to reroute this service-LSP and change it as follows: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| > > or as follows: > > |<----------------service-LSP_X------------------->| > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| > > The service-LSP X is still the same service-LSP with the same > service-LSP MEP functions, only the path through the MPLS-TP network > has been changed. > > Identification with respect to the server layer trail (e.g. > tunnel LSP) is appropriate for a link connection (e.g. LSP segment). > The service-LSP X has three service-LSP segments. > Those segments are identified with respect to their tunnel; i.e. with > respect to the transport-LSP in this example. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > Sent: vrijdag 16 april 2010 18:45 > To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; > pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 > > > > > On 4/2/10 2:53 AM, "Attila Takacs" wrote: > > > Hi Matthew and George, > > > > Please find some comments/questions below. > > > > -In Section 5.1 you have: > > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > > > What is the reason of having a Dst-Tunnel_Num besides the > Src-Tunnel_Num? > > Existing implementations of RSVP-TE have used the tunnel space as > global to the node. It is difficult if not impossible to coordinate > such spaces between nodes. In RSVP-TE the coordination does not > matter, since the tail end of the tunnel doesn't have a real interface > - it only receives and usually with a PHP of the tunnel label, so the > packets only belong to the physical interface. > > In a bidirectional world, separate tunnel spaces at the two ends > becomes useful. > > If this independence is not need is some environments then one can > configure just one value and use it in both fields. > > > Is it there to support associated unidirectional > Tunnels/LSPs? If so > > it should be called out in the text. > > That was not my original intent, but you are quite correct that this > would be very useful. Particularly if the associated tunnels pass > through a share mid-point somewhere along the path. > > > Same applies to the globally unique case. > > Of course. > > > -In Section 5.2 you simply append one LSP_Num to the above. > This is a > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two > > LSP_Nums would be needed too, wouldn't it? > > Once, you have independent tunnel-ids, coordination of the LSP numbers > becomes easy. It also could be used to allow the two ends to readily > identify which is working and which is protection. > > > -In Section 5.3 Mapping to GMPLS signaling does not use the > > Dst-Tunnel_Num. So this means that we may have two > different tunnels > > identified with > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > intentional, e.g., the associated unidirectional case? > > For the associated unidirectional, this works perfectly. For > bidirectional, I was thinking of two options. > > 1) Strict binding - both ends are configure with the full > identifier and will only accept the connection if everything matches. > > 2) Dynamic binding - Source signals with just its Tunnel_Num. RESV > message would carry back the destination's tunnel_num. Note that both > ends need both pieces for some of the OAM to work. > > > This should be clarified. > > I'll see what I can do. But this is not supposed to the MPLS-TP > signaling draft. > > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. > > I'm planning to keep it. > > > -Section 7 has a note saying to be aligned with the OAM > fwk, is this > > still to be done? > > Yes. That draft is also being updated. We appear to be converging. > > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > How would Tunnel and LSP MEGs be used? What OAM would run at the > > Tunnel level and not at the LSP level? > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? > > I had been told early on that MEGs were needed for tunnels. > Now getting comments that they are not (same comment is in the ITU > liaison). So I planning to remove it, unless I hear other opinions. > > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. > > See above. > > > -Section 8 talks about open issues? When will these be addressed? > > Before it is re-issued. Goal is end of next week. > > ...George > > > Thanks, > > Attila > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From neil.2.harrison@bt.com Wed Apr 21 03:49:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767EB3A6B4F; Wed, 21 Apr 2010 03:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO9h2EW66y5h; Wed, 21 Apr 2010 03:49:45 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A9D6F3A694C; Wed, 21 Apr 2010 03:49:44 -0700 (PDT) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 11:49:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 11:49:32 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05D5080B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <98ED265C742D4598AAAD6B8CC7C2DB81@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAtTXPtcA5wPYwAAAfU5QAAJ4WtAABQTnwA== From: To: , , , , , X-OriginalArrivalTime: 21 Apr 2010 10:49:34.0743 (UTC) FILETIME=[54A05270:01CAE140] Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:49:47 -0000 Thanks Maarten.....have IETF agreed to all this? regards, neil=20 > -----Original Message----- > From: Maarten Vissers [mailto:maarten.vissers@huawei.com]=20 > Sent: 21 April 2010 10:06 > To: Harrison,N,Neil,DKQ7 R; swallow@cisco.com; mpls@ietf.org;=20 > mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: RE: [mpls-tp] [mpls] mpls wg last call on=20 > draft-ietf-mpls-tp-identifiers-01 >=20 > Neil, >=20 > There are three MPLS-TP layer netowrks defined: > 1) Transport Service layer network > (including MS-PWs, Service-LSPs, PST-LSPs) > 2) Transport Path layer network > (including Transport-LSPs, PST-LSPs) > 3) Section layer network > (including Section-LSPs, PST-LSPs). >=20 > Each of those three MPLS-TP layer networks has two types of sub-layers > defined: > A) TCM sub-layer with a 1:1 relation (for admin domain monitoring > and SNC/S protection switching applications) > B) TCM sub-layer with a n:1 relation (for some protection switching > applciations) > which are supported by PST-LSPs. >=20 > The three layer networks have Access Points, and those APs=20 > are identified by means of an Access Point Identifier.=20 >=20 > The sub-layers have sub-layer Access Points, and those=20 > sub-layer APs are identified by means of a sub-layer Access=20 > Point Identifier. >=20 > [Note - We need to understand what the IETF equivalent=20 > of the ITU-T Access Point > is... See below the '-----' for my view on this based=20 > on a question I received > on what the equivalent ITU-T construct would be for an=20 > IETF 'interface'.] >=20 > The MPLS-TP data plane does not demarc the boundary between=20 > those layer networks or between a layer and its sublayers.=20 > This is a clear difference with similar layer/sublayer=20 > structures in OTN ODU and Ethernet ETH layers; in those two=20 > technologies there is a clear demarcation between layer=20 > networks and between the layer network signal and its=20 > sublayers. But we have to ask ourselves the question if this=20 > would be an issue... Most likely not because of the following: >=20 > Transport Service, Transport Path and Section layer names=20 > represent roles in a domain. A Transport-LSP in domain A can=20 > be passed through a domain B in which it is considered to be=20 > a Service-LSP. Similarly, a Section-LSP in domain A can be=20 > passed through a domain B in which it is considered to be a=20 > Service-LSP. And it is even possible to have a Section-LSP in=20 > domain A which is passed through a domain B as Service-LSP=20 > and is then handed of to domain C as a Transport-LSP. >=20 > This role variability is also present in the OTN ODU and=20 > Ethernet ETH layers, so there is commonality between those=20 > three technologies at this point. >=20 > The implication is that the Access Point in e.g. a MPLS-TP=20 > Section layer or Ethernet Virtual Section layer could be=20 > connected with an Access Point in a MPLS-TP Transport Path or=20 > Ethernet Virtual Path layer. This capability is of course a=20 > feature and not a bug, and the implication is that the access=20 > point identification scheme should be agnostic to the=20 > operational role names of the layer networks in each domain. >=20 > ----------- >=20 > I was asked the question what the ITU-T equivalent of the=20 > IETF 'interface' > would be. > It could be that this equivalent is the 'access point'. The=20 > access points demark a trail in a layer network and access=20 > points are identified by means of their 'access point=20 > identifier (APId)'. If you look at clause 8.6.1 in G.7710=20 > http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find=20 > in figure 23 a description of how the APId is used to=20 > identify the other reference points (termination connection=20 > point, connection point). >=20 > In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you=20 > find the following features of the access points: > ---------- > The features of Access Point Identifiers (APIs) are: > - each access point identifier must be globally unique in its=20 > layer network; > - where it may be expected that the access point may be=20 > required for path set-up across an inter-operator boundary,=20 > the access point identifier must be available to other=20 > network operators; - the access point identifier should not=20 > change while the access point remains in existence; - the=20 > access point identifier should be able to identify the=20 > country and network operator which is responsible for routing=20 > to and from the access point; - the set of all access point=20 > identifiers belonging to a single administrative layer=20 > network should form a single access point identification=20 > scheme; - the scheme of access point identifiers for each=20 > administrative layer network can be independent from the=20 > scheme in any other administrative layer network. >=20 > The API shall begin with either the country code as defined=20 > in ITU-T E.164 (one, two or three numeric characters) or, the=20 > three alphabetic character country code as defined in ISO 3166. > The remainder of the API characters that follow the country=20 > code shall be a matter for the organization to whom the=20 > country code has been assigned, provided that uniqueness is=20 > guaranteed. > These characters may be any alphanumeric characters as=20 > defined in ITU-T T.50 (International Reference Version -=20 > 7-bit coded character set for information interchange). > The alphanumeric character set consists of the characters "a"=20 > to "z", "A" to "Z", and "0" to "9". > In the case where the API uses less than fifteen characters,=20 > the API will be padded (extended) with the T.50 "NUL"=20 > character to get a fifteen byte character string. > ------------ >=20 >=20 > Applying this AP, CP and TCP identification in MPLS-TP you=20 > would get the > following: >=20 > - PW access points demark the PW trail > - PW termination connection points demark the PW network connection >=20 > - LSP access points demark the LSP trail > - LSP termination connection points demark the LSP network connection >=20 > A PW trail and network connection are identified (PW_TID,=20 > PW_NCID) by means of their PW APId set =20 > for a p2p PW and for a p2mp PW. >=20 > A LSP trail and network connection are identified (LSP_TID,=20 > LSP_NCID) by means of their LSP APId set LSP_APId_2> for a p2p LSP and LSP_APId_n> for a p2mp LSP. >=20 >=20 > - a LSP carries one or more client LSPs and/or PWs and/or VPLSs.=20 > The client LSP connection points are identified by means of=20 > the LSP APId plus the client_LSP label value.=20 > The client PW connection points are identified by means of=20 > the LSP APId plus the client_PW label value.=20 > The client VPLS (i.e. ETH) flow points are identified by=20 > means of the LSP APId plus the client_VPLS (i.e. PW) label value. >=20 > - a PW may carry one or more client LSPs.=20 > The client LSP connection points are identified by means of=20 > the PW APId plus the client_LSP label value.=20 >=20 > - a PW may carry one or more client VLANs.=20 > The client VLAN (i.e. ETH) flow points are identified by=20 > means of the PW APId plus the client_VLAN VLAN ID (VID) or=20 > Service instance ID (SID) value.=20 >=20 > The client connection/flow points demark a client link connection. > A client_LSP or _VLAN link connection supported by a PW trail=20 > is then identified by the PW trail identifier (i.e. > plus the client label=20 > or VID/SID value. > A client_LSP/PW/VPLS link connection supported by a LSP trail=20 > is then identified by the LSP trail identifier (i.e. > plus the client LSP=20 > or PW label value (LSP__LCID, PW_LCID, VPLS_LCID). >=20 > A PW (or LSP) trail contains of one or more PW (or LSP) link=20 > connections with unique identifiers. This implies that one PW=20 > (or LSP) trail/network connection identifier is related to a=20 > set of PW (or LSP) link connection identifiers; e.g.=20 > PW_TID/PW_NCID <=3D> {PW_LCID_a,PW_LCID_b, ...} >=20 > ------------ >=20 > PWs and LSPs represent layer network trails and sublayer=20 > network trails in the MPLS-TP Transport Service, Transport=20 > Path and Section layer networks. An > overview: >=20 > Transport Service layer network: > - MPLS-TP PW trail > - MPLS-TP service-LSP trail > [- ETH VPLS connectionless trail] > - MPLS-TP PST-LSP sublayer trail >=20 > Transport Path layer network: > - MPLS-TP transport-LSP trail > - MPLS-TP PST-LSP sublayer trail >=20 > Section layer network: > - MPLS-TP section-LSP trail > - MPLS-TP PST-LSP sublayer trail >=20 > Note that the PST-LSP sublayer trails performing a TCM=20 > function are dependent on the layer trails. If a layer trail=20 > is deleted all associated PST-LSP sublayer trails have to be=20 > deleted as well. >=20 > In MPLS-TP these sublayer trails perform a complete=20 > encapsulation of the layer trail and/or client-sublayer=20 > trail. This is different from sublayer trails in SDH, OTN,=20 > ATM and Ethernet networks. In those latter network=20 > technologies a sublayer trail just adds an additional level=20 > of OAM without further encapsulating the incoming signal. As=20 > a consequence in those latter networks the addition or=20 > removal of a sublayer does not change the set of link=20 > connections in the trail/network connection. In MPLS-TP we=20 > have to decide if we follow the same model, or if we consider=20 > that the addition of a sublayer (i.e. a PST-LSP) changes the=20 > number of link connections in the layer trail/network connection.=20 >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: woensdag 21 april 2010 9:38 > To: maarten.vissers@huawei.com; swallow@cisco.com;=20 > mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: RE: [mpls-tp] [mpls] mpls wg last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > Maarten...agreed...but there is also a worrying addressing=20 > problem in all this IMO that does not seem to be=20 > recognised/understood. In summary, a layer network (any=20 > mode/technology, not just co-ps/MPLS-TP > say) is most essentially characterised by its access point=20 > addressing scheme...screw this up on day 1 and it is very=20 > hard to change later. >=20 > MPLS originally never had proper addressing allocated to=20 > it...largely due to is binding with the cl-ps mode IP layer=20 > network it could never be seen as a layer network in its own=20 > right (part of the common control-plane flaw - I come back on=20 > this later). Further, each LSP here was a *sublayer* and=20 > part of the same hybrid/MPLS/IP layer network. > Moreover, each LSP (label distribution) signalling type=20 > created its own form of addressing for how it wanted to=20 > identify its type of access points. >=20 > PWs made the situation significantly worse when they became multi-hop. > These suddenly jumped from an adaptation role to a full blown=20 > layer network in their own right. So they needed their own=20 > addressing scheme (and OAM, LDP signalling, etc),...which is=20 > what all the AII stuff is. > Not a great addressing structure I should add, we should have=20 > used v4 or > v6 but the problem dogging this stuff was that we were still=20 > claiming this was all part of the same IP/MPLS layer network=20 > =3D> can also read as same instance of routing.....something we=20 > should know now is a flawed notion for MPLS-T based on=20 > lessons learnt from GMPLS (I originally pointed this 'common=20 > CP nonsense' out at 2000 San Diego IETF mtg). >=20 > Now MPLS-TP is supposed to be a transport network. So each=20 > LSP in a nested case should be in its own layer=20 > network....this is essentially what you shown below. MPLS-TP=20 > therefore does not need sublayering as per the old type of=20 > MPLS...and it for sure should not be generating a PW layer=20 > network, that simply indicates a failure to deliver a=20 > transport network and just propagates the error made in MPLS. >=20 > However, because some folks want to retain the S bit notion=20 > and the old type of sublayering in MPLS-TP, we have no way of=20 > knowing whether a set of nested LSPs belong to different=20 > layer networks or are sublayers in some arbitary layer=20 > network grouping. The DP looks the same in all cases. >=20 > I can see all sorts of problems brewing here in correctly=20 > identify which layer network a given LSP belongs to...esp if=20 > there are multiple parties involved in both client/server and=20 > peer-partition sense.=20 >=20 > regards, Neil =20 >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers > > Sent: 21 April 2010 08:11 > > To: 'George Swallow'; mpls@ietf.org; mpls-tp@ietf.org;=20 > pwe3@ietf.org;=20 > > ccamp@ietf.org > > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > > draft-ietf-mpls-tp-identifiers-01 > >=20 > > George, > >=20 > > It is a bad practice to identify a connection (e.g. LSP) within the=20 > > scope of their server layer trail (e.g. tunnel LSP). Reason=20 > is that a=20 > > connection (e.g. LSP) is typically carried by multiple server layer=20 > > trails (e.g. tunnel LSPs). > > Example: a service-LSP X is carried over three transport-LSPs A,B,C: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->| > >=20 > > It is possible to reroute this service-LSP and change it as follows: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->| > >=20 > > or as follows: > >=20 > > |<----------------service-LSP_X------------------->| > > |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->| > >=20 > > The service-LSP X is still the same service-LSP with the same=20 > > service-LSP MEP functions, only the path through the=20 > MPLS-TP network=20 > > has been changed. > >=20 > > Identification with respect to the server layer trail (e.g.=20 > > tunnel LSP) is appropriate for a link connection (e.g. LSP=20 > segment).=20 > > The service-LSP X has three service-LSP segments. > > Those segments are identified with respect to their tunnel;=20 > i.e. with=20 > > respect to the transport-LSP in this example. > >=20 > > Regards, > > Maarten > >=20 > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of George Swallow > > Sent: vrijdag 16 april 2010 18:45 > > To: Attila Takacs; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org;=20 > > pwe3@ietf.org; ccamp@ietf.org > > Subject: Re: [mpls-tp] [mpls] mpls wg last call on > > draft-ietf-mpls-tp-identifiers-01 > >=20 > >=20 > >=20 > >=20 > > On 4/2/10 2:53 AM, "Attila Takacs"=20 > wrote: > >=20 > > > Hi Matthew and George, > > >=20 > > > Please find some comments/questions below. > > >=20 > > > -In Section 5.1 you have: > > >=20 > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num > > >=20 > > > What is the reason of having a Dst-Tunnel_Num besides the > > Src-Tunnel_Num? > >=20 > > Existing implementations of RSVP-TE have used the tunnel space as=20 > > global to the node. It is difficult if not impossible to=20 > coordinate=20 > > such spaces between nodes. In RSVP-TE the coordination does not=20 > > matter, since the tail end of the tunnel doesn't have a=20 > real interface > > - it only receives and usually with a PHP of the tunnel=20 > label, so the=20 > > packets only belong to the physical interface. > >=20 > > In a bidirectional world, separate tunnel spaces at the two ends=20 > > becomes useful. > >=20 > > If this independence is not need is some environments then one can=20 > > configure just one value and use it in both fields. > >=20 > > > Is it there to support associated unidirectional > > Tunnels/LSPs? If so > > > it should be called out in the text. > >=20 > > That was not my original intent, but you are quite correct=20 > that this=20 > > would be very useful. Particularly if the associated tunnels pass=20 > > through a share mid-point somewhere along the path. > >=20 > > > Same applies to the globally unique case. > >=20 > > Of course. > >=20 > > > -In Section 5.2 you simply append one LSP_Num to the above.=20 > > This is a > > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two=20 > > > LSP_Nums would be needed too, wouldn't it? > >=20 > > Once, you have independent tunnel-ids, coordination of the=20 > LSP numbers=20 > > becomes easy. It also could be used to allow the two ends=20 > to readily=20 > > identify which is working and which is protection. > >=20 > > > -In Section 5.3 Mapping to GMPLS signaling does not use the=20 > > > Dst-Tunnel_Num. So this means that we may have two > > different tunnels > > > identified with > > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this > > intentional, e.g., the associated unidirectional case? > >=20 > > For the associated unidirectional, this works perfectly. For=20 > > bidirectional, I was thinking of two options. > >=20 > > 1) Strict binding - both ends are configure with the full=20 > > identifier and will only accept the connection if=20 > everything matches. > >=20 > > 2) Dynamic binding - Source signals with just its=20 > Tunnel_Num. RESV=20 > > message would carry back the destination's tunnel_num. =20 > Note that both=20 > > ends need both pieces for some of the OAM to work. > >=20 > > > This should be clarified. > >=20 > > I'll see what I can do. But this is not supposed to the MPLS-TP=20 > > signaling draft. > > =20 > > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. > >=20 > > I'm planning to keep it. > > =20 > > > -Section 7 has a note saying to be aligned with the OAM > > fwk, is this > > > still to be done? > >=20 > > Yes. That draft is also being updated. We appear to be converging. > >=20 > > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > > > How would Tunnel and LSP MEGs be used? What OAM would run at the=20 > > > Tunnel level and not at the LSP level? > > > > > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? > >=20 > > I had been told early on that MEGs were needed for tunnels. =20 > > Now getting comments that they are not (same comment is in the ITU=20 > > liaison). So I planning to remove it, unless I hear other opinions. > >=20 > > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. > >=20 > > See above. > >=20 > > > -Section 8 talks about open issues? When will these be addressed? > >=20 > > Before it is re-issued. Goal is end of next week. > >=20 > > ...George > >=20 > > > Thanks, > > > Attila > >=20 > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > >=20 >=20 >=20 From db3546@att.com Wed Apr 21 09:30:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64DCF3A677E for ; Wed, 21 Apr 2010 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf12zeYgsKbz for ; Wed, 21 Apr 2010 09:30:36 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 6C1DD3A6C82 for ; Wed, 21 Apr 2010 09:02:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-161.messagelabs.com!1271865744!30268617!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27923 invoked from network); 21 Apr 2010 16:02:25 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Apr 2010 16:02:25 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3LG29eG002498 for ; Wed, 21 Apr 2010 12:02:09 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3LG28dX002484 for ; Wed, 21 Apr 2010 12:02:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 12:02:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 Thread-Index: AcrVvck4CgEU4tkhSDOKrzkLdLKQKQLrdn5g References: From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: Re: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:30:37 -0000 Hi, We have good support for this document. Authors, please submit the document as a wg document: draft-ietf-ccamp-gmpls-g709-framework-00.txt Thanks, Deborah and Lou -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Tuesday, April 06, 2010 3:17 PM To: CCAMP Subject: [CCAMP] poll on draft-zhang-ccamp-gmpls-g709-framework-02 All, This is to start a two week poll on making draft-zhang-ccamp-gmpls-g709-framework-02.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Tuesday, April 20th. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From loa@pi.nu Wed Apr 21 07:28:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE22E28C3C6; Wed, 21 Apr 2010 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKpSaC62WN8h; Wed, 21 Apr 2010 07:28:47 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 5057C28C3CC; Wed, 21 Apr 2010 06:58:47 -0700 (PDT) Received: from [79.138.133.61] (79.138.133.61.bredband.tre.se [79.138.133.61]) (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 3CDDDD4058; Wed, 21 Apr 2010 15:58:34 +0200 (CEST) Message-ID: <4BCF04D9.8050401@pi.nu> Date: Wed, 21 Apr 2010 15:59:53 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Apr 2010 13:05:00 -0700 Subject: [CCAMP] Final wg last call on draft-ietf-mpls-tp-survive-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:28:47 -0000 All, this is to start a two week final working group last call on draft-ietf-mpls-tp-survive-fwk-05. Please note that the final working group last call is started only to verify that comments from the previous working group last call has been correctly addressed. Please send your comments to the mpls-tp@ietf.org mailing list. This working group last call ends May 5th. /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 From loa@pi.nu Thu Apr 22 02:41:23 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCF73A67DB; Thu, 22 Apr 2010 02:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjpOd3vip+1o; Thu, 22 Apr 2010 02:41:22 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 379653A68F5; Thu, 22 Apr 2010 02:41:21 -0700 (PDT) Received: from [95.209.191.123] (95.209.191.123.bredband.tre.se [95.209.191.123]) (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 CB637D404F; Thu, 22 Apr 2010 11:41:08 +0200 (CEST) Message-ID: <4BD01A04.10901@pi.nu> Date: Thu, 22 Apr 2010 11:42:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Apr 2010 03:52:27 -0700 Subject: [CCAMP] Final wg last call on MPLS-TP OAM Framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:41:23 -0000 All, this is to start a two week final working group last call on draft-ietf-mpls-tp-oam-framework-06.txt Please note that the final working group last call is started only to verify that comments from the previous working group last call has been correctly addressed. Please send your comments to the mpls-tp@ietf.org mailing list. This working group last call ends May 6th. /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 From root@core3.amsl.com Thu Apr 22 04:00:01 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BB0EF3A68CD; Thu, 22 Apr 2010 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100422110001.BB0EF3A68CD@core3.amsl.com> Date: Thu, 22 Apr 2010 04:00:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of G.709 Optical Transport Networks Author(s) : F. Zhang, et al. Filename : draft-ietf-ccamp-gmpls-g709-framework-00.txt Pages : 24 Date : 2010-04-21 This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. Zhang, et al Expires October 2010 [page 1] draft-ietf-ccamp-gmpls-g709-framework-00.txt April 2010 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-g709-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-22035342.I-D@ietf.org> --NextPart-- From loa@pi.nu Thu Apr 22 08:53:58 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABA83A6B70; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf-2OtQmw1Ai; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 11B213A6BB1; Thu, 22 Apr 2010 08:53:58 -0700 (PDT) Received: from [95.209.68.102] (95.209.68.102.bredband.tre.se [95.209.68.102]) (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 074C9D404F; Thu, 22 Apr 2010 17:53:44 +0200 (CEST) Message-ID: <4BD07159.2040209@pi.nu> Date: Thu, 22 Apr 2010 17:55:05 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: MPLS-TP ad hoc team , mpls@ietf.org, "mpls-tp@ietf.org" , CCAMP WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Finalk wg lst call on MPLS Transport Profile Data Plane Architecture X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:53:59 -0000 All, this is to start a two week final working group last call on draft-ietf-mpls-tp-data-plane-02.txt Please note that the final working group last call is started only to verify that comments from the previous working group last call has been correctly addressed. Please send your comments to the mpls-tp@ietf.org mailing list. This working group last call ends May 6th. /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 From db3546@att.com Fri Apr 23 11:07:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69A13A6A3E; Fri, 23 Apr 2010 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piTZIqJ5T2R8; Fri, 23 Apr 2010 11:07:18 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 417463A6A00; Fri, 23 Apr 2010 11:07:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-167.messagelabs.com!1272046026!28719199!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24888 invoked from network); 23 Apr 2010 18:07:07 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Apr 2010 18:07:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3NI6o9t008618; Fri, 23 Apr 2010 14:06:50 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3NI6i0Q008321; Fri, 23 Apr 2010 14:06:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 14:06:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re. MPLS 2010 Conference - Call for Presentation Abstracts Extended Thread-Index: AcrjDL+SiZqfI//FQ8WKrxj3F1gDPgAAlMiQ From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" , Subject: [CCAMP] Re. MPLS 2010 Conference - Call for Presentation Abstracts Extended X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:07:19 -0000 FYI -=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis Sent: Friday, April 23, 2010 1:45 PM To: mpls@ietf.org Subject: [mpls] MPLS 2010 Conference - Call for Presentation AbstractsExtended Note that the deadline for abstract submissions has been extended to April 30. Cheers, Andy ---------- Forwarded message ---------- From: Andrew G. Malis Date: Mon, Mar 22, 2010 at 7:39 PM Subject: MPLS 2010 Conference - Call for Presentation Abstracts To: mpls@ietf.org The MPLS 2010 International Conference, the 13th Annual International Conference on MPLS and Related Technologies, will be held October 24 - 27, 2010, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 23, 2010. If you want further information on MPLS 2010 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2010/call_for_papers/cfp.htm Many of these topics have been of interest to members of the MPLS WG in the past, and several people active in the working group have been presenters at past events. Regards and thanks, Andy Malis Co-chair, Technical Program Committee - MPLS 2010 Conference From vishwas.ietf@gmail.com Sun Apr 25 16:45:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9F93A68BF for ; Sun, 25 Apr 2010 16:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q102BseDkMAg for ; Sun, 25 Apr 2010 16:45:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 099823A68B3 for ; Sun, 25 Apr 2010 16:45:50 -0700 (PDT) Received: by gyh4 with SMTP id 4so6135752gyh.31 for ; Sun, 25 Apr 2010 16:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=0P4xJOaSZtVV4dzA22Msx9s0hSIcuzC5r9V9dq9Siww=; b=F6WMvx0COf9BOdXrjJIOly0xQiQwHK2tswddXtsGFVrGYKymewcCDG5o/JlS1ngH2n j6LwHieSrWjirx7gvDCYnJd2uMg1G0rBzZJ6IzSAR5VNER0E8QzBdgnSSrlqOCV39+UL 4ZJ+p0+sdBKgIO+u68LMfCXlfnaDpADU3Yuao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=q3qo1JSYKlsO8ynhA+EjTWa6P31LpiqpiznVKiNwHewcY7FZ8XSqVtRZvJcQq/bNCy 6Nt1pMylBel9RvaCX4o7w2i3x6fLvYPyeLIly8XjWX+n6n/xj/ZxVg/pg2YygoCBEvQs SJvuXRrdmZdFm8CIL0NIoJTp4CN2pQZSH53b8= MIME-Version: 1.0 Received: by 10.150.235.9 with SMTP id i9mr3375592ybh.239.1272239136614; Sun, 25 Apr 2010 16:45:36 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Sun, 25 Apr 2010 16:45:36 -0700 (PDT) Date: Sun, 25 Apr 2010 16:45:36 -0700 Message-ID: From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 23:45:51 -0000 Hi, While working on the document for RSVP-TE for IPv6 I noticed that RFC3209 specifies that the Hello Message TTL should be set to 1, however RFC3473 does not change the behavior. Shouldn't the TTL in the case of GMPLS be set to more than one as a control channel to he data plane nexthop could be multiple hops away? I think we should reccomend the use of the TTL value of 255. Besides for IPv6 it would be the Hop Limit field. Thanks, Vishwas From rrahman@cisco.com Sun Apr 25 17:11:47 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F84F28C0F9 for ; Sun, 25 Apr 2010 17:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ge8yjt8tRKb for ; Sun, 25 Apr 2010 17:11:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0FB903A6AA6 for ; Sun, 25 Apr 2010 17:11:42 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP121EutJV2d/2dsb2JhbACcM3GmBphshQwEgzk X-IronPort-AV: E=Sophos;i="4.52,271,1270425600"; d="scan'208";a="104939807" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 00:11:30 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o3Q0BT6w003843; Mon, 26 Apr 2010 00:11:29 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 19:11:29 -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: Sun, 25 Apr 2010 19:11:24 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Hello Message Thread-Index: Acrk0W9csCmdQoaTRtecskH26u1mvgAA3ahA References: From: "Reshad Rahman (rrahman)" To: "Vishwas Manral" , X-OriginalArrivalTime: 26 Apr 2010 00:11:29.0855 (UTC) FILETIME=[051EC4F0:01CAE4D5] Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 00:11:47 -0000 Hi, I believe that TTL 1 is only for immediate neighbors. Regads, Reshad. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Sunday, April 25, 2010 7:46 PM To: ccamp@ietf.org Subject: [CCAMP] Hello Message Hi, While working on the document for RSVP-TE for IPv6 I noticed that RFC3209 specifies that the Hello Message TTL should be set to 1, however RFC3473 does not change the behavior. Shouldn't the TTL in the case of GMPLS be set to more than one as a control channel to he data plane nexthop could be multiple hops away? I think we should reccomend the use of the TTL value of 255. Besides for IPv6 it would be the Hop Limit field. Thanks, Vishwas _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From vishwas.ietf@gmail.com Sun Apr 25 17:14:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B957F3A6A68 for ; Sun, 25 Apr 2010 17:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaRES8Jt3xkB for ; Sun, 25 Apr 2010 17:14:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 5133E3A6A0F for ; Sun, 25 Apr 2010 17:13:57 -0700 (PDT) Received: by gyh4 with SMTP id 4so6144698gyh.31 for ; Sun, 25 Apr 2010 17:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lN6PM9sCfSFSky/l88k8xI9UNAV6iVsxJrI66q8sNVM=; b=X6eN369mOGXLPl+5oWX/IPKvc9oH80FdbxGs4iPKKmHXpySM8v+Ixx5I3UJ/nYUshF nmJtvPjON9emrmgJL7WzMEJZ6MsjEyFI4TShRFKgJmkhm3XrXqs/RbE3IcB87fvSK3Ub lytouow1To+3RJdUoaPTQ1RpqSvaGO5PYMsN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o+yrRgUykF7QB+nxH1xBdjWRTZyPjeNbiQCrIgC/WAYMolYY85/A3K/ZT3gE4VHUNP m/Nxj/+i4Ac6B8Jwi7TA3swsshVAqBhlOQ7bXFJG3HVf8M32/sEIV3lQR4tQzwoD31bl Zb9qQUN+bh6MlhEyfR7hYXxPzXvazMKNSezjs= MIME-Version: 1.0 Received: by 10.151.117.16 with SMTP id u16mr3290308ybm.302.1272240821698; Sun, 25 Apr 2010 17:13:41 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Sun, 25 Apr 2010 17:13:41 -0700 (PDT) In-Reply-To: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> Date: Sun, 25 Apr 2010 17:13:41 -0700 Message-ID: From: Vishwas Manral To: "Reshad Rahman (rrahman)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 00:14:35 -0000 Hi Reshad, In GMPLS in the control plane the immediate neighbors may be more than one IP Hop away. Thanks, Vishwas On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) wrote: > Hi, > > I believe that TTL 1 is only for immediate neighbors. > > Regads, > Reshad. > > =A0 When HELLO messages are being the exchanged between immediate > =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be > =A0 set to 1. > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Vishwas Manral > Sent: Sunday, April 25, 2010 7:46 PM > To: ccamp@ietf.org > Subject: [CCAMP] Hello Message > > Hi, > > While working on the document for RSVP-TE for IPv6 I noticed that > RFC3209 specifies that the Hello Message TTL should be set to 1, > however RFC3473 does not change the behavior. > > Shouldn't the TTL in the case of GMPLS be set to more than one as a > control channel to he data plane nexthop could be multiple hops away? > I think we should reccomend the use of the TTL value of 255. Besides > for IPv6 it would be the Hop Limit field. > > Thanks, > Vishwas > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From rrahman@cisco.com Sun Apr 25 17:23:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CB83A6A0F for ; Sun, 25 Apr 2010 17:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY5dCIHZjj+H for ; Sun, 25 Apr 2010 17:23:56 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0A9583A6A1D for ; Sun, 25 Apr 2010 17:23:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEt51EutJV2Z/2dsb2JhbACcM3GmC5hshQwEgzk X-IronPort-AV: E=Sophos;i="4.52,271,1270425600"; d="scan'208";a="104940830" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2010 00:23:27 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o3Q0NQ9H023095; Mon, 26 Apr 2010 00:23:26 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 19:23:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Apr 2010 19:23:23 -0500 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Hello Message Thread-Index: Acrk1VTONWBSsMBUSWOyodWIs5K2uAAARbIQ References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> From: "Reshad Rahman (rrahman)" To: "Vishwas Manral" X-OriginalArrivalTime: 26 Apr 2010 00:23:26.0721 (UTC) FILETIME=[B067D710:01CAE4D6] Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 00:23:58 -0000 Hi Vishwas, You're right I guess there's ambiguity as to whether immediate is = referring to data-plane or control-plane. Regards, Reshad. -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Sunday, April 25, 2010 8:14 PM To: Reshad Rahman (rrahman) Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message Hi Reshad, In GMPLS in the control plane the immediate neighbors may be more than one IP Hop away. Thanks, Vishwas On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) wrote: > Hi, > > I believe that TTL 1 is only for immediate neighbors. > > Regads, > Reshad. > > =A0 When HELLO messages are being the exchanged between immediate > =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD = be > =A0 set to 1. > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Vishwas Manral > Sent: Sunday, April 25, 2010 7:46 PM > To: ccamp@ietf.org > Subject: [CCAMP] Hello Message > > Hi, > > While working on the document for RSVP-TE for IPv6 I noticed that > RFC3209 specifies that the Hello Message TTL should be set to 1, > however RFC3473 does not change the behavior. > > Shouldn't the TTL in the case of GMPLS be set to more than one as a > control channel to he data plane nexthop could be multiple hops away? > I think we should reccomend the use of the TTL value of 255. Besides > for IPv6 it would be the Hop Limit field. > > Thanks, > Vishwas > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From vishwas.ietf@gmail.com Sun Apr 25 17:50:19 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBB528C0F9 for ; Sun, 25 Apr 2010 17:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKaxoto2i7QU for ; Sun, 25 Apr 2010 17:50:18 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7996F3A6A1D for ; Sun, 25 Apr 2010 17:50:18 -0700 (PDT) Received: by gwaa12 with SMTP id a12so2690697gwa.31 for ; Sun, 25 Apr 2010 17:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4NaImW0gZgBQ792ef4Z/azyegq3/Qmj+GrmHFpPgwJ0=; b=PIk7O21PL59jErN5nYqibHvK6nk65VOBG2TS3IT32Gu9Z1dY3WBfn1/IAoGBNDMKlz Py0zmecwt/n2Jn3Kw44d3ZMOCKLV75zGyJj+YCTqrejtUj8Bn1EfPLuQw489dFHRItCO s0pSyR8LaBXeTLHgWO7wyjzp17IKr+9F5vngI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pdcaJv4R4Q+Hp7z7E4GL/2kNGQrH9CP9HxL4UMribw4R9A+L5EzPRpsYs4EJiQDGVl rO5UGNTEPUXVMCAhvxbdLqO16urh2r1qcmyIBHoErpfuCjR/qc8g9Y1hwK1hdK0NXdZW UZ+eISuh+SXgUdZi/uDDN0EfDMNhi5zbn2Tgk= MIME-Version: 1.0 Received: by 10.150.251.17 with SMTP id y17mr3550251ybh.283.1272243001795; Sun, 25 Apr 2010 17:50:01 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Sun, 25 Apr 2010 17:50:01 -0700 (PDT) In-Reply-To: <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> Date: Sun, 25 Apr 2010 17:50:01 -0700 Message-ID: From: Vishwas Manral To: "Reshad Rahman (rrahman)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 00:50:20 -0000 Hi Reshad, That is correct. All messages except the OAM and LMP test message are sent over the control plane. So immediate neighbors in the control plane too should not set the TTL to 1, unless they are sure the neighbor is directly connected in the IP layer. In my view, it is more than an ambiguity its not been taken care of at all in the spec. Thanks, Vishwas On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) wrote: > Hi Vishwas, > > You're right I guess there's ambiguity as to whether immediate is referri= ng to data-plane or control-plane. > > Regards, > Reshad. > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Sunday, April 25, 2010 8:14 PM > To: Reshad Rahman (rrahman) > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Hello Message > > Hi Reshad, > > In GMPLS in the control plane the immediate neighbors may be more than > one IP Hop away. > > Thanks, > Vishwas > > On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) > wrote: >> Hi, >> >> I believe that TTL 1 is only for immediate neighbors. >> >> Regads, >> Reshad. >> >> =A0 When HELLO messages are being the exchanged between immediate >> =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >> =A0 set to 1. >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Vishwas Manral >> Sent: Sunday, April 25, 2010 7:46 PM >> To: ccamp@ietf.org >> Subject: [CCAMP] Hello Message >> >> Hi, >> >> While working on the document for RSVP-TE for IPv6 I noticed that >> RFC3209 specifies that the Hello Message TTL should be set to 1, >> however RFC3473 does not change the behavior. >> >> Shouldn't the TTL in the case of GMPLS be set to more than one as a >> control channel to he data plane nexthop could be multiple hops away? >> I think we should reccomend the use of the TTL value of 255. Besides >> for IPv6 it would be the Hop Limit field. >> >> Thanks, >> Vishwas >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > From wwwrun@rfc-editor.org Sun Apr 25 20:29:16 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF2B03A6A84 for ; Sun, 25 Apr 2010 20:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUKp1RjQQcpq for ; Sun, 25 Apr 2010 20:29:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C60363A6783 for ; Sun, 25 Apr 2010 20:29:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9E531E07CA; Sun, 25 Apr 2010 20:29:04 -0700 (PDT) To: lberger@movaz.com, stbryant@cisco.com, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20100426032904.9E531E07CA@rfc-editor.org> Date: Sun, 25 Apr 2010 20:29:04 -0700 (PDT) Cc: ccamp@ietf.org, vishwas@ipinfusion.com, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC3473 (2173) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 03:29:16 -0000 The following errata report has been submitted for RFC3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3473&eid=2173 -------------------------------------- Type: Editorial Reported by: Vishwas Manral Section: TOC Original Text ------------- 10. RSVP Message Formats and Handling ......................... 30 10.1 RSVP Message Formats ................................... 30 10.2 Addressing Path and PathTear Messages ................. 32 Corrected Text -------------- 10. RSVP Message Formats and Handling ......................... 30 10.1 RSVP Message Formats ................................... 30 10.2 Addressing Path, PathTear and ResvConf Messages ....... 32 Notes ----- The section is called "Addressing Path, PathTear and ResvConf Messages" while the TOC does not talk about ResvConf Message 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. -------------------------------------- RFC3473 (draft-ietf-mpls-generalized-rsvp-te-09) -------------------------------------- Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions Publication Date : January 2003 Author(s) : L. Berger, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From lberger@labn.net Mon Apr 26 06:13:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8A828C0DB for ; Mon, 26 Apr 2010 06:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6jo8GO8BTHI for ; Mon, 26 Apr 2010 06:13:37 -0700 (PDT) Received: from outbound-mail-01.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id BFE9228C146 for ; Mon, 26 Apr 2010 06:12:45 -0700 (PDT) Received: (qmail 23202 invoked by uid 0); 26 Apr 2010 13:12:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 26 Apr 2010 13:12:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=1XxpDRUpbodu25xL+uJeO9nfEck4diXXgLwts6GwMR/3LL21O5fHyQ7mPWgbxDbdNyexoMUXzcL8PCOjCm2yV4cNKln1l37cY4mRd7NaciHKFX50/unjlx9lp1HUPs4s; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6O6z-0006n9-Ej; Mon, 26 Apr 2010 07:12:33 -0600 Message-ID: <4BD5914F.10708@labn.net> Date: Mon, 26 Apr 2010 09:12:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Vishwas Manral References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 13:13:38 -0000 Vishwas, I have to say, I really don't see an issue here. Recall that in 3209 DP and CP adjacencies are congruent, so there is no ambiguity. In the cases where hellos are exchanged between non-immediate neighbors (GMPLS or MPLS), TTL shouldn't be set to 1. I think this case is fairly clearly covered too. To be specific, how would you like to see the text changed? For example, do you want the text to read: Current 3209: When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1. Add Additionally, when HELLO messages are not being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD NOT be set to 1. Seems a bit redundant and obvious. Don't you think? Am I missing something? Lou On 4/25/2010 8:50 PM, Vishwas Manral wrote: > Hi Reshad, > > That is correct. > > All messages except the OAM and LMP test message are sent over the > control plane. So immediate neighbors in the control plane too should > not set the TTL to 1, unless they are sure the neighbor is directly > connected in the IP layer. > > In my view, it is more than an ambiguity its not been taken care of at > all in the spec. > > Thanks, > Vishwas > > On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) > wrote: >> Hi Vishwas, >> >> You're right I guess there's ambiguity as to whether immediate is referring to data-plane or control-plane. >> >> Regards, >> Reshad. >> >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Sunday, April 25, 2010 8:14 PM >> To: Reshad Rahman (rrahman) >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] Hello Message >> >> Hi Reshad, >> >> In GMPLS in the control plane the immediate neighbors may be more than >> one IP Hop away. >> >> Thanks, >> Vishwas >> >> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >> wrote: >>> Hi, >>> >>> I believe that TTL 1 is only for immediate neighbors. >>> >>> Regads, >>> Reshad. >>> >>> When HELLO messages are being the exchanged between immediate >>> neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >>> set to 1. >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of Vishwas Manral >>> Sent: Sunday, April 25, 2010 7:46 PM >>> To: ccamp@ietf.org >>> Subject: [CCAMP] Hello Message >>> >>> Hi, >>> >>> While working on the document for RSVP-TE for IPv6 I noticed that >>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>> however RFC3473 does not change the behavior. >>> >>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>> control channel to he data plane nexthop could be multiple hops away? >>> I think we should reccomend the use of the TTL value of 255. Besides >>> for IPv6 it would be the Hop Limit field. >>> >>> Thanks, >>> Vishwas >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From vishwas.ietf@gmail.com Mon Apr 26 07:48:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A66228C177 for ; Mon, 26 Apr 2010 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrbLE9AfpVce for ; Mon, 26 Apr 2010 07:48:12 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id BAFA328C253 for ; Mon, 26 Apr 2010 07:26:52 -0700 (PDT) Received: by pxi19 with SMTP id 19so1771743pxi.31 for ; Mon, 26 Apr 2010 07:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GPv/iOEvZvd4+nU3rWN8Nc1bK4Cpzvj+DB9yqhyMZu0=; b=aDf+YS00ZXXf04lCQ+Dw4i4yJzxbWI+TDWWVFNGi3COlrPlrdEonPMg7YU1GGu2RDI KqU3Iw8Q1RbNt8fRPMqPw+HRd+YNfLyoRj4eHhyxt7dugeMVtXM7moaNMn8h5dYMlACP +NVWUjJU4JU1/i+pncXrZec2v15mEvExlbH/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qtnITbGFE3U8wSD55o8dLqTXcg7bHuP0llVBoeHu380i7wJYnL7I/rgbuwAzy4DkZT TZDdV7PxaRSP3S6xW3kvW4wGM3np3RWt5Vw1j8KUhIGxE/gvTHPr3iY9iexfp4Svzetz 1O2/b/uNqiEjDKirvoNCy8KRWDmAXq4fDPvWE= MIME-Version: 1.0 Received: by 10.114.33.33 with SMTP id g33mr4280557wag.104.1272291996268; Mon, 26 Apr 2010 07:26:36 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 07:26:36 -0700 (PDT) In-Reply-To: <4BD5914F.10708@labn.net> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> Date: Mon, 26 Apr 2010 07:26:36 -0700 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:48:13 -0000 Hi Lou, I think if you read the sentence just before the one we have mentioned it becomes clear: The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1. What this seems to mean to me, is that HELLO's always use TTL 1. The text we need to have in GMPLS RFC is: The HELLO mechanism is intended for use between immediate neighbors. In the GMPLS case the immediate neighbors can be more than one IP Hop away. HELLO messages exchanged in GMPLS between immediate neighbors SHOULD have the IP TTL field of all outgoing HELLO messages set to 1. Without this the HELLO mechanism does not work. Thanks, Vishwas On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: > Vishwas, > > I have to say, I really don't see an issue here. Recall that in 3209 DP > and CP adjacencies are congruent, so there is no ambiguity. =A0In the > cases where hellos are exchanged between non-immediate neighbors (GMPLS > or MPLS), TTL shouldn't be set to 1. =A0I think this case is fairly > clearly covered too. =A0To be specific, how would you like to see the tex= t > changed? For example, do you want the text to read: > > Current 3209: > =A0 When HELLO messages are being the exchanged between immediate > =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be > =A0 set to 1. > Add > =A0 Additionally, when HELLO messages are not being the exchanged > =A0 between immediate neighbors, the IP TTL field of all outgoing HELLO > =A0 messages SHOULD NOT be set to 1. > > Seems a bit redundant and obvious. =A0Don't you think? > > Am I missing something? > > Lou > > On 4/25/2010 8:50 PM, Vishwas Manral wrote: >> Hi Reshad, >> >> That is correct. >> >> All messages except the OAM and LMP test message are sent over the >> control plane. So immediate neighbors in the control plane too should >> not set the TTL to 1, unless they are sure the neighbor is directly >> connected in the IP layer. >> >> In my view, it is more than an ambiguity its not been taken care of at >> all in the spec. >> >> Thanks, >> Vishwas >> >> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >> wrote: >>> Hi Vishwas, >>> >>> You're right I guess there's ambiguity as to whether immediate is refer= ring to data-plane or control-plane. >>> >>> Regards, >>> Reshad. >>> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Sunday, April 25, 2010 8:14 PM >>> To: Reshad Rahman (rrahman) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] Hello Message >>> >>> Hi Reshad, >>> >>> In GMPLS in the control plane the immediate neighbors may be more than >>> one IP Hop away. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>> wrote: >>>> Hi, >>>> >>>> I believe that TTL 1 is only for immediate neighbors. >>>> >>>> Regads, >>>> Reshad. >>>> >>>> =A0 When HELLO messages are being the exchanged between immediate >>>> =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD = be >>>> =A0 set to 1. >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Vishwas Manral >>>> Sent: Sunday, April 25, 2010 7:46 PM >>>> To: ccamp@ietf.org >>>> Subject: [CCAMP] Hello Message >>>> >>>> Hi, >>>> >>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>> however RFC3473 does not change the behavior. >>>> >>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>> control channel to he data plane nexthop could be multiple hops away? >>>> I think we should reccomend the use of the TTL value of 255. Besides >>>> for IPv6 it would be the Hop Limit field. >>>> >>>> Thanks, >>>> Vishwas >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > From vishwas.ietf@gmail.com Mon Apr 26 07:49:59 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375F03A6C5A for ; Mon, 26 Apr 2010 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzQ3wm-AypJF for ; Mon, 26 Apr 2010 07:49:58 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8414628C298 for ; Mon, 26 Apr 2010 07:30:59 -0700 (PDT) Received: by pvg11 with SMTP id 11so539965pvg.31 for ; Mon, 26 Apr 2010 07:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9NS8n6h8SiISNqVSQQwp/EWgaeJiecZaO00L9gMhCAA=; b=sE/XtgA4yksk/g8+V0ovy+U3UxW1XZjg0slppX33vfkggbqaXPunl2Uz9OJT74iW3r 6dx35OEbikLyStcfGhhy5fY6FMeUolrysjuCDIVa/znkybJuquXoMngsqI4Pe8isV3oA aEFj17101G6XdAVD5ikW3J5McjUyVLFa3lhd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mEFG6sjVUDy3Q8EamcIZ2FdaigjYc+GOajn+YFJWSujHCafoQ2Hg0pfHjKxEm4c/u9 lsdKr9oC5cU6oHmDOtTThsqHTGGTJLM6E5D/YU/nItDTpt9FFDFeECT0eeiGQv/wtxyo ftnY549bxHxdE0RITfcdCebJgfV9Jt1hM2FDM= MIME-Version: 1.0 Received: by 10.143.20.19 with SMTP id x19mr1865661wfi.260.1272292245177; Mon, 26 Apr 2010 07:30:45 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 07:30:45 -0700 (PDT) In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2BA8C8275140@EX-NAP.tellabs-west.tellabsinc.net> References: <5292FFA96EC22A4386067E9DBCC0CD2BA8C8275140@EX-NAP.tellabs-west.tellabsinc.net> Date: Mon, 26 Apr 2010 07:30:45 -0700 Message-ID: From: Vishwas Manral To: "Sadler, Jonathan B." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:49:59 -0000 Hi Jonathan, Thanks a lot for the inputs. I guess you wanted to forward the mail to the = list. I agree if like you mentioned, older implementations used GRE the TTL required in the inner header is always 1. However that is just one way to implement it and like you mentioned implementations set the TTL value to greater than 1. I agree LMP CC Hello mechanisms are useful. Thanks, Vishwas On Mon, Apr 26, 2010 at 7:04 AM, Sadler, Jonathan B. wrote: > Vishwas - > > It all depends on how your supporting your control channel. =A0In early y= ears, many implementations ran the control channel as a tunnel (e.g. GRE, I= P-in-IP) to handle two issues: getting around the snooping of RSVP traffic = by intermediate routers (this was later accommodated for by router alert) a= nd TTL expiry limits in both RSVP-TE and OSPF. =A0This is part of the reaso= n LMP sessions are critical - they in essence provide CC OAM (i.e. is it st= ill up) for the tunnel. > > Today, many implementations run control channels without running over a t= unnel and support larger TTL. > > Hope this helps, > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Vishwas Manral > Sent: Sunday, April 25, 2010 6:46 PM > To: ccamp@ietf.org > Subject: [CCAMP] Hello Message > > Hi, > > While working on the document for RSVP-TE for IPv6 I noticed that > RFC3209 specifies that the Hello Message TTL should be set to 1, > however RFC3473 does not change the behavior. > > Shouldn't the TTL in the case of GMPLS be set to more than one as a > control channel to he data plane nexthop could be multiple hops away? > I think we should reccomend the use of the TTL value of 255. Besides > for IPv6 it would be the Hop Limit field. > > Thanks, > Vishwas > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader > of this message is not the intended recipient, or an employee > or agent responsible for delivering this message to the > intended recipient, you are hereby notified that any reproduction, > dissemination or distribution of this communication is strictly > prohibited. If you have received this communication in error, > please notify us immediately by replying to the message and > deleting it from your computer. Thank you. Tellabs > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > From vishwas.ietf@gmail.com Mon Apr 26 07:50:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E003A687C for ; Mon, 26 Apr 2010 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2Q+V5fJnugt for ; Mon, 26 Apr 2010 07:50:41 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id D884C28C1C9 for ; Mon, 26 Apr 2010 07:32:30 -0700 (PDT) Received: by pzk12 with SMTP id 12so8402660pzk.32 for ; Mon, 26 Apr 2010 07:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X3ulVndu8D/zDss2TL/M880dSCh1cwnR2u7Q5LKL6WI=; b=Q3xIknwscoshBrGlwvscvsq/NJX+JRJ0MSWHsxTF4ibJHfF+5mcV+8RsKc7ZEHkWor d+IHVW5nl2bJ/osCtbvT37mb6s6LYeQ2LafrdeiHZFTpbAQzRAg9o4I91tpBs5vdciql UkyrQYCxC5aCz+WKvkJTz2nOclpbg+26l0D+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uy1fmYJF1976xcOp206LFaqXeyTvjDFNmCsucKv+6Zyao9Zh+pGBeGHBYCjdNNW4nv 50zmbaS6bIpDQLpWCqnw+u5uxE6tME2tmkh+4VMwbLVlvQ2cj0PXYljjswPN4CQyAghN hhDGZLEi6IEQU6WkLzS36kC1Hg5KFaimYMtjY= MIME-Version: 1.0 Received: by 10.115.133.17 with SMTP id k17mr4336141wan.24.1272292334848; Mon, 26 Apr 2010 07:32:14 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 07:32:14 -0700 (PDT) In-Reply-To: <4BD5914F.10708@labn.net> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> Date: Mon, 26 Apr 2010 07:32:14 -0700 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:50:43 -0000 Changed with a small correction: Hi Lou, I think if you read the sentence just before the one we have mentioned it becomes clear: The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1. What this seems to mean to me, is that HELLO's always use TTL 1. The text we need to have in GMPLS RFC is: The HELLO mechanism is intended for use between immediate neighbors. In the GMPLS case the immediate neighbors can be more than one IP Hop away. HELLO messages exchanged in GMPLS between immediate neighbors SHOULD have the IP TTL field of all outgoing HELLO messages set to 255. Without this the HELLO mechanism does not work. Thanks, Vishwas On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: > Vishwas, > > I have to say, I really don't see an issue here. Recall that in 3209 DP > and CP adjacencies are congruent, so there is no ambiguity. =A0In the > cases where hellos are exchanged between non-immediate neighbors (GMPLS > or MPLS), TTL shouldn't be set to 1. =A0I think this case is fairly > clearly covered too. =A0To be specific, how would you like to see the tex= t > changed? For example, do you want the text to read: > > Current 3209: > =A0 When HELLO messages are being the exchanged between immediate > =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be > =A0 set to 1. > Add > =A0 Additionally, when HELLO messages are not being the exchanged > =A0 between immediate neighbors, the IP TTL field of all outgoing HELLO > =A0 messages SHOULD NOT be set to 1. > > Seems a bit redundant and obvious. =A0Don't you think? > > Am I missing something? > > Lou > > On 4/25/2010 8:50 PM, Vishwas Manral wrote: >> Hi Reshad, >> >> That is correct. >> >> All messages except the OAM and LMP test message are sent over the >> control plane. So immediate neighbors in the control plane too should >> not set the TTL to 1, unless they are sure the neighbor is directly >> connected in the IP layer. >> >> In my view, it is more than an ambiguity its not been taken care of at >> all in the spec. >> >> Thanks, >> Vishwas >> >> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >> wrote: >>> Hi Vishwas, >>> >>> You're right I guess there's ambiguity as to whether immediate is refer= ring to data-plane or control-plane. >>> >>> Regards, >>> Reshad. >>> >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Sunday, April 25, 2010 8:14 PM >>> To: Reshad Rahman (rrahman) >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] Hello Message >>> >>> Hi Reshad, >>> >>> In GMPLS in the control plane the immediate neighbors may be more than >>> one IP Hop away. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>> wrote: >>>> Hi, >>>> >>>> I believe that TTL 1 is only for immediate neighbors. >>>> >>>> Regads, >>>> Reshad. >>>> >>>> =A0 When HELLO messages are being the exchanged between immediate >>>> =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD = be >>>> =A0 set to 1. >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>> Of Vishwas Manral >>>> Sent: Sunday, April 25, 2010 7:46 PM >>>> To: ccamp@ietf.org >>>> Subject: [CCAMP] Hello Message >>>> >>>> Hi, >>>> >>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>> however RFC3473 does not change the behavior. >>>> >>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>> control channel to he data plane nexthop could be multiple hops away? >>>> I think we should reccomend the use of the TTL value of 255. Besides >>>> for IPv6 it would be the Hop Limit field. >>>> >>>> Thanks, >>>> Vishwas >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > From julien.meuric@orange-ftgroup.com Mon Apr 26 08:59:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959AF3A68B5 for ; Mon, 26 Apr 2010 08:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFTNJdaFfFAo for ; Mon, 26 Apr 2010 08:59:11 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 53BFF3A6840 for ; Mon, 26 Apr 2010 08:59:11 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 25E49760008; Mon, 26 Apr 2010 17:59:32 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1D628760003; Mon, 26 Apr 2010 17:59:32 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 17:58:59 +0200 Received: from [10.193.71.172] ([10.193.71.172]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 17:58:58 +0200 Message-ID: <4BD5B841.5070702@orange-ftgroup.com> Date: Mon, 26 Apr 2010 17:58:57 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Vishwas Manral References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2010 15:58:58.0385 (UTC) FILETIME=[617C0C10:01CAE559] Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 15:59:12 -0000 Hi Vishwas. Keep in mind that RFC 3209 does not say "MUST" but "SHOULD". The fact that it does not work in case of multiple IP nodes between GMPLS neighbors is a very good (not to say obvious) reason to avoid 1 as IP TTL. What is more, with RFC 3473 in mind, I read "immediate neighbors" as refering to the IP layer (not to the GMPLS controllers); thus I would rather describe your context as: "GMPLS neighbors which are *not immediate neighbors*" (one of the drivers for LMP, as described by Jonathan). In that case, the quoted constraint would not even apply in your context. Regards, Julien Vishwas Manral wrote: > Changed with a small correction: > > Hi Lou, > > I think if you read the sentence just before the one we have mentioned > it becomes clear: > > The HELLO mechanism is intended for use between immediate > neighbors. When HELLO messages are being the exchanged between > immediate neighbors, the IP TTL field of all outgoing HELLO messages > SHOULD be set to 1. > > What this seems to mean to me, is that HELLO's always use TTL 1. > > The text we need to have in GMPLS RFC is: > > The HELLO mechanism is intended for use between immediate > neighbors. In the GMPLS case the immediate neighbors can be more > than one IP Hop away. HELLO messages exchanged in GMPLS > between immediate neighbors SHOULD have the IP TTL field of all > outgoing HELLO messages set to 255. > > Without this the HELLO mechanism does not work. > > Thanks, > Vishwas > > On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: > >> Vishwas, >> >> I have to say, I really don't see an issue here. Recall that in 3209 DP >> and CP adjacencies are congruent, so there is no ambiguity. In the >> cases where hellos are exchanged between non-immediate neighbors (GMPLS >> or MPLS), TTL shouldn't be set to 1. I think this case is fairly >> clearly covered too. To be specific, how would you like to see the text >> changed? For example, do you want the text to read: >> >> Current 3209: >> When HELLO messages are being the exchanged between immediate >> neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >> set to 1. >> Add >> Additionally, when HELLO messages are not being the exchanged >> between immediate neighbors, the IP TTL field of all outgoing HELLO >> messages SHOULD NOT be set to 1. >> >> Seems a bit redundant and obvious. Don't you think? >> >> Am I missing something? >> >> Lou >> >> On 4/25/2010 8:50 PM, Vishwas Manral wrote: >> >>> Hi Reshad, >>> >>> That is correct. >>> >>> All messages except the OAM and LMP test message are sent over the >>> control plane. So immediate neighbors in the control plane too should >>> not set the TTL to 1, unless they are sure the neighbor is directly >>> connected in the IP layer. >>> >>> In my view, it is more than an ambiguity its not been taken care of at >>> all in the spec. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >>> wrote: >>> >>>> Hi Vishwas, >>>> >>>> You're right I guess there's ambiguity as to whether immediate is referring to data-plane or control-plane. >>>> >>>> Regards, >>>> Reshad. >>>> >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Sunday, April 25, 2010 8:14 PM >>>> To: Reshad Rahman (rrahman) >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] Hello Message >>>> >>>> Hi Reshad, >>>> >>>> In GMPLS in the control plane the immediate neighbors may be more than >>>> one IP Hop away. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I believe that TTL 1 is only for immediate neighbors. >>>>> >>>>> Regads, >>>>> Reshad. >>>>> >>>>> When HELLO messages are being the exchanged between immediate >>>>> neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >>>>> set to 1. >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>>> Of Vishwas Manral >>>>> Sent: Sunday, April 25, 2010 7:46 PM >>>>> To: ccamp@ietf.org >>>>> Subject: [CCAMP] Hello Message >>>>> >>>>> Hi, >>>>> >>>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>>> however RFC3473 does not change the behavior. >>>>> >>>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>>> control channel to he data plane nexthop could be multiple hops away? >>>>> I think we should reccomend the use of the TTL value of 255. Besides >>>>> for IPv6 it would be the Hop Limit field. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Mon Apr 26 09:36:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F57E28C18A for ; Mon, 26 Apr 2010 09:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScA7mxYfjJIt for ; Mon, 26 Apr 2010 09:36:39 -0700 (PDT) Received: from outbound-mail-01.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id EE2673A6A2D for ; Mon, 26 Apr 2010 09:36:37 -0700 (PDT) Received: (qmail 27362 invoked by uid 0); 26 Apr 2010 16:36:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 26 Apr 2010 16:36:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=u6ExNqRlkcAFIBo0Ods9H/PBIFw3GvEddkR/AkvLB2Cr4FK96l84jLqBwaHi5B/AVtslLIF6GPmRBgzAyXuks6N2HTkEnZjk0nca65eFKFwBAxpHaAagaMol2yl5ct3R; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6RIH-0007nQ-Qe; Mon, 26 Apr 2010 10:36:26 -0600 Message-ID: <4BD5C127.1060509@labn.net> Date: Mon, 26 Apr 2010 12:36:55 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Vishwas Manral References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:36:41 -0000 Vishwas, See below. On 4/26/2010 10:32 AM, Vishwas Manral wrote: > Changed with a small correction: > > Hi Lou, > > I think if you read the sentence just before the one we have mentioned > it becomes clear: > > The HELLO mechanism is intended for use between immediate > neighbors. Note that this an informative statement without normative language. > When HELLO messages are being the exchanged between > immediate neighbors, the IP TTL field of all outgoing HELLO messages > SHOULD be set to 1. > Note that this is normative. > What this seems to mean to me, is that HELLO's always use TTL 1. > No. it says: (a) the statement's applicability is limited to the case where message exchange is between neighbors. Given that this statement (and RFC) applies to RSVP, a reasonable interpretation is that this statement applies to RSVP immediate neighbors. (b) The a TTL value of 1 is used except when an implementation knows that there is a reason not to do so. See RFC2119 for specific language. > The text we need to have in GMPLS RFC is: > > The HELLO mechanism is intended for use between immediate > neighbors. In the GMPLS case the immediate neighbors can be more > than one IP Hop away. HELLO messages exchanged in GMPLS > between immediate neighbors SHOULD have the IP TTL field of all > outgoing HELLO messages set to 255. > > Without this the HELLO mechanism does not work. I have to say that I simply disagree. The current language is sufficient for the scope of immediate (RSVP) adjacency and is silent on the non-adjacent case. Such silence is not atypical. For example, we (intentionally) don't discuss TTL usage on Hellos. Another example is RFC4271 which doesn't mention TTL at all. Lou > > Thanks, > Vishwas > > On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: >> Vishwas, >> >> I have to say, I really don't see an issue here. Recall that in 3209 DP >> and CP adjacencies are congruent, so there is no ambiguity. In the >> cases where hellos are exchanged between non-immediate neighbors (GMPLS >> or MPLS), TTL shouldn't be set to 1. I think this case is fairly >> clearly covered too. To be specific, how would you like to see the text >> changed? For example, do you want the text to read: >> >> Current 3209: >> When HELLO messages are being the exchanged between immediate >> neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >> set to 1. >> Add >> Additionally, when HELLO messages are not being the exchanged >> between immediate neighbors, the IP TTL field of all outgoing HELLO >> messages SHOULD NOT be set to 1. >> >> Seems a bit redundant and obvious. Don't you think? >> >> Am I missing something? >> >> Lou >> >> On 4/25/2010 8:50 PM, Vishwas Manral wrote: >>> Hi Reshad, >>> >>> That is correct. >>> >>> All messages except the OAM and LMP test message are sent over the >>> control plane. So immediate neighbors in the control plane too should >>> not set the TTL to 1, unless they are sure the neighbor is directly >>> connected in the IP layer. >>> >>> In my view, it is more than an ambiguity its not been taken care of at >>> all in the spec. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >>> wrote: >>>> Hi Vishwas, >>>> >>>> You're right I guess there's ambiguity as to whether immediate is referring to data-plane or control-plane. >>>> >>>> Regards, >>>> Reshad. >>>> >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>> Sent: Sunday, April 25, 2010 8:14 PM >>>> To: Reshad Rahman (rrahman) >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] Hello Message >>>> >>>> Hi Reshad, >>>> >>>> In GMPLS in the control plane the immediate neighbors may be more than >>>> one IP Hop away. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>>> wrote: >>>>> Hi, >>>>> >>>>> I believe that TTL 1 is only for immediate neighbors. >>>>> >>>>> Regads, >>>>> Reshad. >>>>> >>>>> When HELLO messages are being the exchanged between immediate >>>>> neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >>>>> set to 1. >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>>>> Of Vishwas Manral >>>>> Sent: Sunday, April 25, 2010 7:46 PM >>>>> To: ccamp@ietf.org >>>>> Subject: [CCAMP] Hello Message >>>>> >>>>> Hi, >>>>> >>>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>>> however RFC3473 does not change the behavior. >>>>> >>>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>>> control channel to he data plane nexthop could be multiple hops away? >>>>> I think we should reccomend the use of the TTL value of 255. Besides >>>>> for IPv6 it would be the Hop Limit field. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >> > > > From vishwas.ietf@gmail.com Mon Apr 26 11:08:15 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058783A68DF for ; Mon, 26 Apr 2010 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hidx9tASZM9f for ; Mon, 26 Apr 2010 11:08:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1995C3A68DD for ; Mon, 26 Apr 2010 11:08:12 -0700 (PDT) Received: by pwj2 with SMTP id 2so8653286pwj.31 for ; Mon, 26 Apr 2010 11:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p8EqeAJreXU1CTMrdUr4AXpZQZ7rp79rOQ5kWz543E4=; b=FFoL98yN31wVEu75eQpCTrL+wI1sinImCw2dELPPkRpsWC7wEUmM/RCR8lMxuTkv4P TeY5N1sp3baMbUaByJBWMH3ttLNcGQxJnev9nlQ11PpzIoww6v/dJWIPdbOO8oxFHFVo VFgKrSF1QqA4t2NRiQey4kbrbDrQeut6fHpmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cHersU1psAekdQtkiyJqCenxKay5XfoWYnB1fjTSkXiR5qyhQbojWnvojueS8bRSym 3dWcaeC5D3Fl4pKjjNSZyd7ZFUuxt99ACmFgfj7JA83K4ActAVFGRwaEZtI9lGtiaG8T Nex9CBYh+4FbweHCPXZWh+QL8jCMu1jircfFI= MIME-Version: 1.0 Received: by 10.115.39.29 with SMTP id r29mr4908925waj.22.1272305274375; Mon, 26 Apr 2010 11:07:54 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 11:07:53 -0700 (PDT) In-Reply-To: <4BD5B841.5070702@orange-ftgroup.com> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> <4BD5B841.5070702@orange-ftgroup.com> Date: Mon, 26 Apr 2010 11:07:53 -0700 Message-ID: From: Vishwas Manral To: Julien Meuric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:08:15 -0000 Hi Julien, I just saw a clear gap and brought it up. My comments are inline. > Keep in mind that RFC 3209 does not say "MUST" but "SHOULD". The fact tha= t > it does not work in case of multiple IP nodes between GMPLS neighbors is = a > very good (not to say obvious) reason to avoid 1 as IP TTL. I agree it is a SHOULD and not a MUST. That is ok, if we assume that also means that the control plane neighbors are one IP HOP away is a SHOULD case. Is my thinking correct? > What is more, with RFC 3473 in mind, I read "immediate neighbors" as > refering to the IP layer (not to the GMPLS controllers); thus I would rat= her > describe your context as: "GMPLS neighbors which are *not immediate > neighbors*" (one of the drivers for LMP, as described by Jonathan). If that is the case then the statement Hello's are sent to immediate neighbors needs to be first updated (please read the statement just before the statement you have mentioned). Regarding Jonathan's comment, I agree it can be implemented with tunnels. However we cannot write a spec based on a particular implementation (which is not even listed as a way to do it in the RFC). My aim is to just bring out gaps that are very clearly visible. I have no aim to offend anyone. Thanks, Vishwas > > Vishwas Manral wrote: >> >> Changed with a small correction: >> >> Hi Lou, >> >> I think if you read the sentence just before the one we have mentioned >> it becomes clear: >> >> =A0The HELLO mechanism is intended for use between immediate >> =A0neighbors. When HELLO messages are being the exchanged between >> =A0immediate neighbors, the IP TTL field of all outgoing HELLO messages >> =A0SHOULD be set to 1. >> >> What this seems to mean to me, is that HELLO's always use TTL 1. >> >> The text we need to have in GMPLS RFC is: >> >> =A0The HELLO mechanism is intended for use between immediate >> =A0neighbors. In the GMPLS case the immediate neighbors can be more >> =A0than one IP Hop away. HELLO messages exchanged in GMPLS >> =A0between immediate neighbors SHOULD have the IP TTL field of all >> =A0outgoing HELLO messages set to 255. >> >> Without this the HELLO mechanism does not work. >> >> Thanks, >> Vishwas >> >> On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: >> >>> >>> Vishwas, >>> >>> I have to say, I really don't see an issue here. Recall that in 3209 DP >>> and CP adjacencies are congruent, so there is no ambiguity. =A0In the >>> cases where hellos are exchanged between non-immediate neighbors (GMPLS >>> or MPLS), TTL shouldn't be set to 1. =A0I think this case is fairly >>> clearly covered too. =A0To be specific, how would you like to see the t= ext >>> changed? For example, do you want the text to read: >>> >>> Current 3209: >>> =A0When HELLO messages are being the exchanged between immediate >>> =A0neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be >>> =A0set to 1. >>> Add >>> =A0Additionally, when HELLO messages are not being the exchanged >>> =A0between immediate neighbors, the IP TTL field of all outgoing HELLO >>> =A0messages SHOULD NOT be set to 1. >>> >>> Seems a bit redundant and obvious. =A0Don't you think? >>> >>> Am I missing something? >>> >>> Lou >>> >>> On 4/25/2010 8:50 PM, Vishwas Manral wrote: >>> >>>> >>>> Hi Reshad, >>>> >>>> That is correct. >>>> >>>> All messages except the OAM and LMP test message are sent over the >>>> control plane. So immediate neighbors in the control plane too should >>>> not set the TTL to 1, unless they are sure the neighbor is directly >>>> connected in the IP layer. >>>> >>>> In my view, it is more than an ambiguity its not been taken care of at >>>> all in the spec. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >>>> wrote: >>>> >>>>> >>>>> Hi Vishwas, >>>>> >>>>> You're right I guess there's ambiguity as to whether immediate is >>>>> referring to data-plane or control-plane. >>>>> >>>>> Regards, >>>>> Reshad. >>>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Sunday, April 25, 2010 8:14 PM >>>>> To: Reshad Rahman (rrahman) >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] Hello Message >>>>> >>>>> Hi Reshad, >>>>> >>>>> In GMPLS in the control plane the immediate neighbors may be more tha= n >>>>> one IP Hop away. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>>>> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I believe that TTL 1 is only for immediate neighbors. >>>>>> >>>>>> Regads, >>>>>> Reshad. >>>>>> >>>>>> =A0When HELLO messages are being the exchanged between immediate >>>>>> =A0neighbors, the IP TTL field of all outgoing HELLO messages SHOULD= be >>>>>> =A0set to 1. >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Beha= lf >>>>>> Of Vishwas Manral >>>>>> Sent: Sunday, April 25, 2010 7:46 PM >>>>>> To: ccamp@ietf.org >>>>>> Subject: [CCAMP] Hello Message >>>>>> >>>>>> Hi, >>>>>> >>>>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>>>> however RFC3473 does not change the behavior. >>>>>> >>>>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>>>> control channel to he data plane nexthop could be multiple hops away= ? >>>>>> I think we should reccomend the use of the TTL value of 255. Besides >>>>>> for IPv6 it would be the Hop Limit field. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>>> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> > > From vishwas.ietf@gmail.com Mon Apr 26 11:16:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C33728C0E9 for ; Mon, 26 Apr 2010 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm87iV49uBBO for ; Mon, 26 Apr 2010 11:16:16 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id AE8583A6959 for ; Mon, 26 Apr 2010 11:15:57 -0700 (PDT) Received: by pxi19 with SMTP id 19so1916953pxi.31 for ; Mon, 26 Apr 2010 11:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ic3e+x4TDtySR37v5Pkda00E0v+ReBAjznJNSWJf+J4=; b=nr11X7ilHg5pp89LKKZCjKQQGsYALuCX3l7FuuLOwBp7b0uRimymby0jr4MjQuvXfx GaJNc4RnqIgVqYpp3I9XD6V00u1LNgUPM3qVDyKwTtKRpuWDkmLjWuKIyiNJSY38UYaF 809VnvEKGkvuqiVyvb5JHk8+mK7Feyekk1Vb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G6y/HUzF2XGZ/TkwL6DIpLuNsacTHfuYphb9YntgEb3eT1zoON21YdoIvlF5K8VaYS 6aWMATi5kQxJysoP/nYYfy8UN+aWx6piMRR+h/8Zucs1LPa0BwmE0SB/MpTvlrtQW2yH T/sEhi7nk9Kjc/L3biECYO0lI5UKi3PFKVLJc= MIME-Version: 1.0 Received: by 10.141.91.4 with SMTP id t4mr4242141rvl.78.1272305742326; Mon, 26 Apr 2010 11:15:42 -0700 (PDT) Received: by 10.151.27.4 with HTTP; Mon, 26 Apr 2010 11:15:42 -0700 (PDT) In-Reply-To: <4BD5C127.1060509@labn.net> References: <654701C60BCC7C4EBD533B89D72BDFEA01288F65@XMB-RCD-204.cisco.com> <654701C60BCC7C4EBD533B89D72BDFEA01288F67@XMB-RCD-204.cisco.com> <4BD5914F.10708@labn.net> <4BD5C127.1060509@labn.net> Date: Mon, 26 Apr 2010 11:15:42 -0700 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Hello Message X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:16:18 -0000 Hi Lou, I really appriciate your prompt replies. But by saying that we can overlook all sentences without a MUST/ SHOULD is opening a can of worms. In that case you may have to put in MUST and SHOULD in a lot of places in the RFC. I agree the BGP RFC does not mention TTL (it is a totally self contained RFC) but RFC 3473 updates RFC3209. If there is no update that means the behavior of RFC3209 holds good. Am I totally off the mark? Also I have made the TTL statement IPv6 friendly in the RSVP-TE IPv6 draft I have written which now talks of it as Hop Limit. Please do have a look at it and comment on it. Thanks, Vishwas On Mon, Apr 26, 2010 at 9:36 AM, Lou Berger wrote: > Vishwas, > =A0 =A0 =A0 =A0See below. > > On 4/26/2010 10:32 AM, Vishwas Manral wrote: >> Changed with a small correction: >> >> Hi Lou, >> >> I think if you read the sentence just before the one we have mentioned >> it becomes clear: >> >> =A0 The HELLO mechanism is intended for use between immediate >> =A0 neighbors. > > Note that this an informative statement without normative language. > >> When HELLO messages are being the exchanged between >> =A0 immediate neighbors, the IP TTL field of all outgoing HELLO messages >> =A0 SHOULD be set to 1. >> > > Note that this is normative. > >> What this seems to mean to me, is that HELLO's always use TTL 1. >> > > No. =A0it says: > (a) the statement's applicability is limited to the case where message > exchange is between neighbors. =A0Given that this statement (and RFC) > applies to RSVP, a reasonable interpretation is that this statement > applies to RSVP immediate neighbors. > (b) The a TTL value of 1 is used except when an implementation knows > that there is a reason not to do so. =A0See RFC2119 for specific language= . > >> The text we need to have in GMPLS RFC is: >> >> =A0 The HELLO mechanism is intended for use between immediate >> =A0 neighbors. In the GMPLS case the immediate neighbors can be more >> =A0 than one IP Hop away. HELLO messages exchanged in GMPLS >> =A0 between immediate neighbors SHOULD have the IP TTL field of all >> =A0 outgoing HELLO messages set to 255. >> >> Without this the HELLO mechanism does not work. > > I have to say that I simply disagree. =A0The current language is > sufficient for the scope of immediate (RSVP) adjacency and is silent on > the non-adjacent case. =A0Such silence is not atypical. =A0For example, w= e > (intentionally) don't discuss TTL usage on Hellos. =A0Another example is > RFC4271 which doesn't mention TTL at all. > > Lou > >> >> Thanks, >> Vishwas >> >> On Mon, Apr 26, 2010 at 6:12 AM, Lou Berger wrote: >>> Vishwas, >>> >>> I have to say, I really don't see an issue here. Recall that in 3209 DP >>> and CP adjacencies are congruent, so there is no ambiguity. =A0In the >>> cases where hellos are exchanged between non-immediate neighbors (GMPLS >>> or MPLS), TTL shouldn't be set to 1. =A0I think this case is fairly >>> clearly covered too. =A0To be specific, how would you like to see the t= ext >>> changed? For example, do you want the text to read: >>> >>> Current 3209: >>> =A0 When HELLO messages are being the exchanged between immediate >>> =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOULD b= e >>> =A0 set to 1. >>> Add >>> =A0 Additionally, when HELLO messages are not being the exchanged >>> =A0 between immediate neighbors, the IP TTL field of all outgoing HELLO >>> =A0 messages SHOULD NOT be set to 1. >>> >>> Seems a bit redundant and obvious. =A0Don't you think? >>> >>> Am I missing something? >>> >>> Lou >>> >>> On 4/25/2010 8:50 PM, Vishwas Manral wrote: >>>> Hi Reshad, >>>> >>>> That is correct. >>>> >>>> All messages except the OAM and LMP test message are sent over the >>>> control plane. So immediate neighbors in the control plane too should >>>> not set the TTL to 1, unless they are sure the neighbor is directly >>>> connected in the IP layer. >>>> >>>> In my view, it is more than an ambiguity its not been taken care of at >>>> all in the spec. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, Apr 25, 2010 at 5:23 PM, Reshad Rahman (rrahman) >>>> wrote: >>>>> Hi Vishwas, >>>>> >>>>> You're right I guess there's ambiguity as to whether immediate is ref= erring to data-plane or control-plane. >>>>> >>>>> Regards, >>>>> Reshad. >>>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>>>> Sent: Sunday, April 25, 2010 8:14 PM >>>>> To: Reshad Rahman (rrahman) >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] Hello Message >>>>> >>>>> Hi Reshad, >>>>> >>>>> In GMPLS in the control plane the immediate neighbors may be more tha= n >>>>> one IP Hop away. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Sun, Apr 25, 2010 at 5:11 PM, Reshad Rahman (rrahman) >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I believe that TTL 1 is only for immediate neighbors. >>>>>> >>>>>> Regads, >>>>>> Reshad. >>>>>> >>>>>> =A0 When HELLO messages are being the exchanged between immediate >>>>>> =A0 neighbors, the IP TTL field of all outgoing HELLO messages SHOUL= D be >>>>>> =A0 set to 1. >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Beha= lf >>>>>> Of Vishwas Manral >>>>>> Sent: Sunday, April 25, 2010 7:46 PM >>>>>> To: ccamp@ietf.org >>>>>> Subject: [CCAMP] Hello Message >>>>>> >>>>>> Hi, >>>>>> >>>>>> While working on the document for RSVP-TE for IPv6 I noticed that >>>>>> RFC3209 specifies that the Hello Message TTL should be set to 1, >>>>>> however RFC3473 does not change the behavior. >>>>>> >>>>>> Shouldn't the TTL in the case of GMPLS be set to more than one as a >>>>>> control channel to he data plane nexthop could be multiple hops away= ? >>>>>> I think we should reccomend the use of the TTL value of 255. Besides >>>>>> for IPv6 it would be the Hop Limit field. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>> >> >> >> > From wwwrun@rfc-editor.org Mon Apr 26 16:50:00 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B953A69EA; Mon, 26 Apr 2010 16:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRMLW81TLU0U; Mon, 26 Apr 2010 16:49:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id A7E093A6889; Mon, 26 Apr 2010 16:49:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 294B2E07DC; Mon, 26 Apr 2010 16:49:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100426234948.294B2E07DC@rfc-editor.org> Date: Mon, 26 Apr 2010 16:49:48 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 5817 on Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 23:50:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5817 Title: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Author: Z. Ali, JP. Vasseur, A. Zamfir, J. Newton Status: Informational Stream: IETF Date: April 2010 Mailbox: zali@cisco.com, jpv@cisco.com, ancaz@cisco.com, jonathan.newton@cw.com Pages: 11 Characters: 24219 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-mpls-graceful-shutdown-13.txt URL: http://www.rfc-editor.org/rfc/rfc5817.txt MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Common Control and Measurement Plane 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 Mon Apr 26 16:50:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2623A6BF8; Mon, 26 Apr 2010 16:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcsfG2UXJyX0; Mon, 26 Apr 2010 16:50:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id E48C73A69EA; Mon, 26 Apr 2010 16:50:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 51593E07E4; Mon, 26 Apr 2010 16:50:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100426235002.51593E07E4@rfc-editor.org> Date: Mon, 26 Apr 2010 16:50:02 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 5818 on Data Channel Status Confirmation Extensions for the Link Management Protocol X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 23:50:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5818 Title: Data Channel Status Confirmation Extensions for the Link Management Protocol Author: D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia Status: Standards Track Stream: IETF Date: April 2010 Mailbox: danli@huawei.com, xuhuiying@huawei.com, snigdho.bardalai@us.fujitsu.com, julien.meuric@orange-ftgroup.com, diego.caviglia@ericsson.com Pages: 15 Characters: 34092 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-confirm-data-channel-status-09.txt URL: http://www.rfc-editor.org/rfc/rfc5818.txt This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane 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 Mon Apr 26 16:51:03 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEA73A6BFF; Mon, 26 Apr 2010 16:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTaN8XAmaHaf; Mon, 26 Apr 2010 16:51:02 -0700 (PDT) Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id A158A3A6C05; Mon, 26 Apr 2010 16:50:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 239E1E07F7; Mon, 26 Apr 2010 16:50:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100426235047.239E1E07F7@rfc-editor.org> Date: Mon, 26 Apr 2010 16:50:47 -0700 (PDT) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 5852 on RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 23:51:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5852 Title: RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network Author: D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai Status: Standards Track Stream: IETF Date: April 2010 Mailbox: diego.caviglia@ericsson.com, daniele.ceccarelli@ericsson.com, danli@huawei.com, sbardalai@gmail.com Pages: 23 Characters: 49293 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt URL: http://www.rfc-editor.org/rfc/rfc5852.txt In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493. This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane 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 swallow@cisco.com Tue Apr 27 10:39:07 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCD53A6922; Tue, 27 Apr 2010 10:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.801 X-Spam-Level: X-Spam-Status: No, score=-7.801 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehcyW5tQmn4O; Tue, 27 Apr 2010 10:39:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BEAA03A684D; Tue, 27 Apr 2010 10:39:05 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIq+1ktAZnwM/2dsb2JhbACbdlhxpzCaHgKFDAQ X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105732502" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2010 17:38:49 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3RHcnot009702; Tue, 27 Apr 2010 17:38:49 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 12:38:49 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 17:38:48 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:38:47 -0400 From: George Swallow To: Diego Caviglia , Attila Takacs , Loa Andersson , , , , Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczLI0hRemNw6QIizlAldPNT1mwQvaaOAAAAvpBAE/7lf1w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 27 Apr 2010 17:38:49.0235 (UTC) FILETIME=[7EB8F630:01CAE630] Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:39:08 -0000 Diego - On 4/2/10 2:58 AM, "Diego Caviglia" wrote: > Hi, > Some more comments from me more ore less on the same route as Attila. >=20 > =B7 Section 1.1 >=20 > o PSC is also used as Packet Switching Capable for OSPF-TE The term is now not used in the document, so I will take it out of the list= . > =B7 Section 2 >=20 > o Tunnel I think that here a reference to the actual identifier of= the > quoted entity could help I mean a reference to Section 5 I'm going to rewrite the note. Maybe able to work in the forward reference you propose if I can make the text flow. > =B7 Section 4 >=20 > o would be good to have a short explanation why numbered interface= s are > not in the scope of MPLS-TP I'm not trying to rule them out. Right now I'm trying to get to something that is useable in an IP-less environment as well as an IP environment. We have yet to start serious work on the signaling. We can add these if we need them then. > =B7 Section 5 >=20 > o Even if section 2 points to 3209 than the Tunnel Identifier chos= en is > different from what is defined in 3209, Extended Tunnel ID field is missi= ng > while there are two different Tunnel Num that is not clear how they works= . I > think here the same convention used in 3209 and in GMPLS signaling would = be > good to avoid to have two or more Tunnel identifiers for MPLS-TP networks > using GMPLS.=20 In section 5.3 I show the mapping to GMPLS. The extended tunnel-id gets filled in with the destination address. You will note that the destination tunnel number doesn't show up at all. What I have in mind is that the dest tunnel number would be carried in a new object with the semantic that this tunnel "connects-to" a particular tunnel number at the destination. The object could be filled in by the source (in which case the destination woul= d verify and accept or reject) or left empty (in which case the destination would return its chosen value in the RESV). > o Why MPLS-TP tunnels must be associated to a LIH? Why MPLS-TP tu= nnels > need to be configured as FA? Does that imply that in case OSPF-TE is used= it > must advertise MPLS-TP tunnels as FA each time a new tunnel is created? The IF-ID names the access point to the tunnel. PWs and LSP can be routed through the interface (AP if you prefer). They do not need to be advertise= d in OSPF. =20 > =B7 Section 5.2 I think that sentence "The format of a Tunnel_ID is= :" > should be "The format of a LSP_ID is:" same for the globally unique case. Yes. Typo - thanks for pointing it out. > =B7 Section 5.3 addresses some of my above concern about usage of t= unnel > and lsp identifiers even if is not a 1:1 mapping given that the Dst-Tunne= l_Num > is not mapped in GMPLS Tunnel ID Addressed above. BR ...George > =B7 Remaining of the docs is still WP > =20 >=20 > BR >=20 > Diego >=20 >=20 > line >=20 >=20 >=20 > DIEGO CAVIGLIA=20 > Strategic Product Manager >=20 >=20 > Ericsson Italy > Product Line PAIB > Via A. Negrone 1/A > Genoa, Italy > Phone +390106003736 > Mobile +393357181762 > diego.caviglia@ericsson.com > www.ericsson.com=20 >=20 >=20 >=20 > Ericsson >=20 >=20 >=20 >=20 >=20 >=20 > This Communication is Confidential. We only send and receive email on the > basis of the term set out at www.ericsson.com/email_disclaimer >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of A= ttila > Takacs > Sent: venerd=EC 2 aprile 2010 8.54 > To: Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; > ccamp@ietf.org > Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-0= 1 >=20 > Hi Matthew and George, >=20 > Please find some comments/questions below. >=20 > -In Section 5.1 you have: >=20 > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num >=20 > What is the reason of having a Dst-Tunnel_Num besides the Src-Tunnel_Num? > Is it there to support associated unidirectional Tunnels/LSPs? If so it s= hould > be called out in the text. >=20 > Same applies to the globally unique case. >=20 > -In Section 5.2 you simply append one LSP_Num to the above. This is a bit > confusing to me, if there are Src/Dst Tunnel_Nums then two LSP_Nums would= be > needed too, wouldn't it? >=20 > -In Section 5.3 Mapping to GMPLS signaling does not use the Dst-Tunnel_Nu= m. So > this means that we may have two different tunnels identified with > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this intenti= onal, > e.g., the associated unidirectional case? This should be clarified. >=20 >=20 > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether. >=20 >=20 > -Section 7 has a note saying to be aligned with the OAM fwk, is this stil= l to > be done? >=20 > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs. > How would Tunnel and LSP MEGs be used? What OAM would run at the Tunnel l= evel > and not at the LSP level? > Do we need Tunnel MEG_IDs as defined in 7.1.2.1? >=20 > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too. >=20 > -Section 8 talks about open issues? When will these be addressed? >=20 > Thanks, > Attila=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Friday, March 12, 2010 12:33 AM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >>=20 >> All, >>=20 >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >>=20 >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >>=20 >>=20 >> Please send your comments to the mpls-tp@ietf.org mailing list. >>=20 >> The working group last ends eob April 2nd. >>=20 >> /Loa >>=20 >> -- >>=20 >> Loa Andersson >>=20 >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >>=20 >> email: loa.andersson@ericsson.com >> loa@pi.nu >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From swallow@cisco.com Tue Apr 27 10:51:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370DD28C138; Tue, 27 Apr 2010 10:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVOcQDPKBYiE; Tue, 27 Apr 2010 10:51:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B22E33A69AC; Tue, 27 Apr 2010 10:51:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOLA1kutJV2a/2dsb2JhbACcTnGnHJofAoUMBA X-IronPort-AV: E=Sophos;i="4.52,282,1270425600"; d="scan'208";a="105598920" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2010 17:51:11 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o3RHpAAK022590; Tue, 27 Apr 2010 17:51:10 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 12:51:10 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Apr 2010 17:51:10 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Apr 2010 13:51:08 -0400 From: George Swallow To: Sriganesh Kini , Loa Andersson , "mpls@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Message-ID: Thread-Topic: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBc0WnZb3W+AQWTpuJTuXgXymZDgQ8Q2QwBPN49pE= In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F52E4835FCC@EUSAACMS0703.eamcs.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Apr 2010 17:51:10.0575 (UTC) FILETIME=[389877F0:01CAE632] Subject: Re: [CCAMP] [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:51:28 -0000 Sri - See inline: On 4/2/10 9:11 AM, "Sriganesh Kini" wrote: > Hi, > > 1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the > Source Node_ID and a locally assigned tunnel number." > a) Should "Source" be replaced by the "endpoint's" since later the > "Dst-Node_ID" is used? Agree - will make change. > b) Useful to clarify the scope of "uniquely identified" before this > statement. Will do my best. > C) Should there be a similar identifier at each intermediate node besides > the endpoints? The midpoints need to have this (not a similar) identifier too. Either through configuration or through signaling. > 2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that. In the provisioned case, it would be the provisioning system. In the signaled case, the end that initiates the signaling. ...George > Thanks > > - Sri > > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Loa Andersson >> Sent: Thursday, March 11, 2010 3:33 PM >> To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >> >> All, >> >> this is to start an MPLS working group last call on >> draft-ietf-mpls-tp-identifiers-01 >> >> There is a discussion on the OAM model for MS-PWs where we >> haven't been able to come to conclusion. Once we reach >> agreement the document will be updated. Comments in this area >> are welcome during the working group last call. >> >> >> Please send your comments to the mpls-tp@ietf.org mailing list. >> >> The working group last ends eob April 2nd. >> >> /Loa >> >> -- >> >> Loa Andersson >> >> Sr Strategy and Standards Manager >> Ericsson /// >> phone: +46 10 717 52 13 >> +46 767 72 92 13 >> >> email: loa.andersson@ericsson.com >> loa@pi.nu >> >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lberger@labn.net Tue Apr 27 11:36:08 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965663A6767 for ; Tue, 27 Apr 2010 11:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd99Z8VXSvA2 for ; Tue, 27 Apr 2010 11:36:07 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id C377C3A6918 for ; Tue, 27 Apr 2010 11:36:00 -0700 (PDT) Received: (qmail 21977 invoked by uid 0); 27 Apr 2010 18:35:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Apr 2010 18:35:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=0S1UQKM8fDmUk3caV40Fu03bOfhm3cA7xwcsg4psFChIdIBFN6cHp9rSNzyn3Ect6ENjRSMNsf6cfoSU7jTiQIyHS2b/boP2KwiByw2oMdtmfKm3QwGDVPE07DWi7HEO; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6pdM-0002sB-7q for ccamp@ietf.org; Tue, 27 Apr 2010 12:35:48 -0600 Message-ID: <4BD72E84.9080307@labn.net> Date: Tue, 27 Apr 2010 14:35:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Draft Response to Liaison Statement, "OTN and WSON work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:36:08 -0000 All, The enclosed is a proposed response to three Liaisons received from Q12. Please send any comments you have by May 11th. Thank you, Deborah and Lou ------------------------------------------------------------- To: greg.jones@itu.int Cc: ccamp@ietf.org; greg.jones@itu.int; sob@harvard.edu; yoichi.maeda@ntt-at.co.jp; paf@cisco.com; adrian.farrel@huawei.com; tsbsg15@itu.int; malcolm.betts@zte.com.cn Subject: New Liaison Statement, "OTN and WSON work in CCAMP" Title: OTN and WSON work in CCAMP Submission Date: 2010-xx-xx From: Deborah Brungard (IETF CCAMP WG) To: ITU-T SG15 Q12 (greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int malcolm.betts@zte.com.cn tsbsg15@itu.int adrian.farrel@huawei.com stbryant@cisco.com paf@cisco.com ccamp@ietf.org lberger@labn.net Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com sob@harvard.edu Purpose: For information Thank you for your liaison statements "COM 15 – LS 100 – E", and "COM 15 – LS 138 – E" on your plans to update G.872 the OTN architecture to reflect the G.709 updates. We would like to inform you that the CCAMP Working Group recently accepted as a Working Group draft: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-00.txt This document will serve as our basis for further work. Please keep us informed as you progress your work. Regarding your liaison "COM 15 – LS 86 – E", "Comments on WSON Impairment Work in CCAMP", we thank you for your comments and we will take these into consideration as we progress our work. We note that you will initiate work to update the architecture and control plane Recommendations related to WSON. Please keep us informed as you progress this work. We look forward to continuing our cooperative relationship with you on these topics. Deborah Brungard Lou Berger CCAMP Working Group co-Chairs From lberger@labn.net Tue Apr 27 11:44:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F97A3A69A3 for ; Tue, 27 Apr 2010 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoGeFYc5woHv for ; Tue, 27 Apr 2010 11:44:17 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 27DA628C148 for ; Tue, 27 Apr 2010 11:43:08 -0700 (PDT) Received: (qmail 3223 invoked by uid 0); 27 Apr 2010 18:42:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Apr 2010 18:42:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=g2OYjuhF/KCM7UJC2DvT2QHCFPSQgciG0DlwxQ8DsEv1o9T7EfR8UZv8ITsAiopn9QxwjKmKI5cGkZbFqGhzBAkYQWe+/k/vf8orxq9Qk4HdYJXlDpU69ZC3TvAfA1vk; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6pkF-0004tB-Se for ccamp@ietf.org; Tue, 27 Apr 2010 12:42:56 -0600 Message-ID: <4BD7302F.4000800@labn.net> Date: Tue, 27 Apr 2010 14:42:55 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Draft Response to Liaison Statement, "Lambda Switch Capable Equipment" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:44:18 -0000 All, The enclosed is a proposed response to a Liaisons received from Q6. Please send any comments you have by May 11th. Thank you, Deborah and Lou ------------------------------------------------------------- To: greg.jones@itu.int Cc: ccamp@ietf.org; greg.jones@itu.int; sob@harvard.edu; yoichi.maeda@ntt-at.co.jp; paf@cisco.com; adrian.farrel@huawei.com; tsbsg15@itu.int; peter.stassar@ties.itu.int; panslow@ciena.com Subject: New Liaison Statement, "Lambda Switch Capable Equipment" Title: Lambda Switch Capable Equipment Submission Date: 2010-xx-xx From: Deborah Brungard (IETF CCAMP WG) To: ITU-T SG15 Q6 (greg.jones@itu.int) Cc: yoichi.maeda@ntt-at.co.jp greg.jones@itu.int peter.stassar@ties.itu.int panslow@ciena.com tsbsg15@itu.int adrian.farrel@huawei.com stbryant@cisco.com paf@cisco.com ccamp@ietf.org lberger@labn.net Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com sob@harvard.edu Purpose: For information Thank you for your liaison statement "COM 15 – LS 78 – E", "Lambda Switch Capable Equipment" and your review of the CCAMP document "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers". Based on the suggestions provided by ITU-T Q6/15, the following modifications were made in CCAMP document: - Reference to G.694 has been removed in title of document. - Reference to "G.694.1" or "G.694.2" was adopted to replace references to "G.694" in the draft accordingly. - The term "DWDM" was replaced by "DWDM multiplexer & demultiplexer" in Clause 3 and Figure 1. - "tables" is replaced by "grids" in Clause 4.1. - The current format of the wavelength label is the following, a new field "Identifier" is introduced. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As you noted, this is slightly different from the information ordering in G.697. For protocol encoding, we have chosen this representation. All the functionality is supported semantically. We also would like to thank ITU-T Q6/15 for the comments on the modeling of 1R, 2R and 3R regenerators in ITU-T Recommendation G.680. We would appreciate it if you would continue to providing us on the progress of ITU-T G.680. We would like to inform you that the CCAMP Working Group ???... We look forward to continuing our exchange of information with you on these topics. Deborah Brungard Lou Berger CCAMP Working Group co-Chairs From lberger@labn.net Tue Apr 27 11:49:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFF728C14F for ; Tue, 27 Apr 2010 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb+DfuEnP02R for ; Tue, 27 Apr 2010 11:49:39 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id A145B28C169 for ; Tue, 27 Apr 2010 11:49:26 -0700 (PDT) Received: (qmail 15895 invoked by uid 0); 27 Apr 2010 18:49:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Apr 2010 18:49:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=xPT6B9XXnnByBSBqhuLM7yFOQkIW4YKt96FAfbjfmK/y0nSu39dP3GDDD+ygc7hQ1QVnXD+SgIjCuUWUgutbuoLl9nMj5jjIr3T7b6WHodQouIge98BzpECeDGUdBAoF; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6pqM-0006cJ-Fk for ccamp@ietf.org; Tue, 27 Apr 2010 12:49:14 -0600 Message-ID: <4BD731AA.8050707@labn.net> Date: Tue, 27 Apr 2010 14:49:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Draft Response to OIF Communication Dated March 4, 2010 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:49:41 -0000 All, The enclosed is a proposed response to a communication received from the OIF. Please send any comments you have by May 3rd. Thank you, Deborah and Lou ------------------------- To: "Kimberly Chiu" Cc: "'Ong, Lyndon'" , "'Sadler, Jonathan B.'" , ccamp-chairs@tools.ietf.org, ospf-chairs@tools.ietf.org, ccamp-ads@tools.ietf.org Subject: Response to OIF Communication Dated March 4, 2010 Dear Mr. Ong, Thank you for your communication related to Routing issues dated March 4, 2010. We are please to have, as anticipated in your communication, the active contribution of OIF participants at the IETF-77 CCAMP meetings. We particularly appreciate the OIF working within the IETF process and RFC4929. In the IETF-77 CCAMP session, the possibility of an update to RFC5787 was discussed. Such an update will need to follow the standard IETF and CCAMP processes. This process typically starts with an individual Internet-Draft. Based on discussions, we anticipate that CCAMP participants will submit such a Draft prior to the IETF-78 meeting. The minutes from the IETF-77 CCAMP sessions can be found at: http://tools.ietf.org/wg/ccamp/minutes?item=minutes77.html We look forward to the continued contribution of OIF participants to the CCAMP working group. Regards, Deborah Brungard and Lou Berger IETF CCAMP Working Group Co-Chairs From lberger@labn.net Tue Apr 27 11:49:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2344328C173 for ; Tue, 27 Apr 2010 11:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUS0NlH3XCjC for ; Tue, 27 Apr 2010 11:49:49 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id A23CA3A68FC for ; Tue, 27 Apr 2010 11:49:29 -0700 (PDT) Received: (qmail 11344 invoked by uid 0); 27 Apr 2010 18:49:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 27 Apr 2010 18:49:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ORmlIqeUykA3mGCGvvgN8jssqXAxuIax1WPxYeBdMher3Jcs/PU7hwXsk/37s5migKWex++sMrWI78I5ssa1VDTK8Fe45I2AokjzJ8oAkdq8bhOBxQwifTf6AHx88SR7; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O6pqP-0006dQ-2o for ccamp@ietf.org; Tue, 27 Apr 2010 12:49:17 -0600 Message-ID: <4BD731AD.9060101@labn.net> Date: Tue, 27 Apr 2010 14:49:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Draft Response to OIF Communication on OIF Requirements X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:49:50 -0000 All, The enclosed is a proposed response to a communication received from the OIF. Please send any comments you have by May 3rd. Thank you, Deborah and Lou ------------------------- To: "Kimberly Chiu" Cc: "'Ong, Lyndon'" , "'Sadler, Jonathan B.'" , ccamp-chairs@tools.ietf.org Subject: Response to OIF Communication on OIF Requirements Dear Mr. Ong, Thank you for your communication related to OIF Requirements dated March 4, 2010. The communication referenced an anticipated Internet Draft on the topic of requirements for automatic link configuration. We understand that this draft was submitted as draft-roch-ccamp-reqts-auto-adj-00.txt. This draft was presented and discussed in the IETF-77 CCAMP meeting. (See http://tools.ietf.org/wg/ccamp/minutes?item=minutes77.html) At the meeting, some expressed interest in the requirements as well as the possibility that some of the requirements can be fulfilled using existing mechanisms. There was agreement that some individuals would work with the co-authors on a revised version of the document. We expect this document to now progress through normal working group process. We don't anticipate further formal communication on this matter. The second topic covered in communication related to draft-sadler-ccamp-rsvp-mt-bundled-links. No agenda slot on this draft was requested for IETF-77. A search of the CCAMP mail archive also fails to find any discussion on this topic. From a process perspective, the proper venue for a discussion of an Internet Draft is either in a working session or (preferably) on the working group mail list. We recommend that questions related to draft-sadler-ccamp-rsvp-mt-bundled-links be raised on the CCAMP mail list, ccamp@ietf.org, or in a future IETF session. It is also worth noting that the requirements identified in this draft seem to have commonality with the requirements listed in draft-ietf-rtgwg-cl-requirement. Regards, Deborah Brungard and Lou Berger IETF CCAMP Working Group Co-Chairs From gregb@grotto-networking.com Wed Apr 28 10:53:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8223A6A8C for ; Wed, 28 Apr 2010 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOMu73VigMEO for ; Wed, 28 Apr 2010 10:53:35 -0700 (PDT) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id B013B3A6B5E for ; Wed, 28 Apr 2010 10:53:33 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o3SHrGib013964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Apr 2010 13:53:18 -0400 Message-ID: <4BD87610.20303@grotto-networking.com> Date: Wed, 28 Apr 2010 10:53:20 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <4BD72E84.9080307@labn.net> In-Reply-To: <4BD72E84.9080307@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [CCAMP] Draft Response to Liaison Statement, "OTN and WSON work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 17:53:35 -0000 Hi Deborah and Lou, this seems fine to me. I think we still need more discussions with ITU-T on the definition and use of the term "black link". They had some comments in the liaison on our use of the term in the impairments draft but we thought our use was consistent with what we had read so far in ITU-T documents. Cheers Greg B. On 4/27/2010 11:35 AM, Lou Berger wrote: > All, > The enclosed is a proposed response to three Liaisons received from > Q12. Please send any comments you have by May 11th. > > Thank you, > Deborah and Lou > > ------------------------------------------------------------- > To: greg.jones@itu.int > Cc: ccamp@ietf.org; greg.jones@itu.int; sob@harvard.edu; > yoichi.maeda@ntt-at.co.jp; paf@cisco.com; adrian.farrel@huawei.com; > tsbsg15@itu.int; malcolm.betts@zte.com.cn > > Subject: New Liaison Statement, "OTN and WSON work in CCAMP" > > Title: OTN and WSON work in CCAMP > Submission Date: 2010-xx-xx > > From: Deborah Brungard (IETF CCAMP WG) > To: ITU-T SG15 Q12 (greg.jones@itu.int) > Cc: yoichi.maeda@ntt-at.co.jp > greg.jones@itu.int > malcolm.betts@zte.com.cn > tsbsg15@itu.int > adrian.farrel@huawei.com > stbryant@cisco.com > paf@cisco.com > ccamp@ietf.org > lberger@labn.net > Reponse Contact: dbrungard@att.com > Technical Contact: dbrungard@att.com > sob@harvard.edu > Purpose: For information > > > Thank you for your liaison statements "COM 15 – LS 100 – E", and "COM 15 > – LS 138 – E" on your plans to update G.872 the OTN architecture to > reflect the G.709 updates. > > We would like to inform you that the CCAMP Working Group recently > accepted as a Working Group draft: > http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-00.txt > > This document will serve as our basis for further work. Please keep us > informed as you progress your work. > > Regarding your liaison "COM 15 – LS 86 – E", "Comments on WSON > Impairment Work in CCAMP", we thank you for your comments and we will > take these into consideration as we progress our work. We note that you > will initiate work to update the architecture and control plane > Recommendations related to WSON. Please keep us informed as you progress > this work. > > We look forward to continuing our cooperative relationship with you on > these topics. > > Deborah Brungard > Lou Berger > > CCAMP Working Group co-Chairs > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Thu Apr 29 05:30:32 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B2B28C2D5 for ; Thu, 29 Apr 2010 05:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzRhym5eq+GH for ; Thu, 29 Apr 2010 05:30:26 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 0361828C2F0 for ; Thu, 29 Apr 2010 05:26:37 -0700 (PDT) Received: (qmail 22481 invoked by uid 0); 29 Apr 2010 12:26:24 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 29 Apr 2010 12:26:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=OCnPKE65Ha/2trzpIaUbhREKr38RXfnf8eXway2UjNBfEKm9y9S6J3xdjZW7PCN1CGRaV/L3y9CW70p/xqx38EI3IYse4YhRxRKBhU80TsPZVbV9nc+vPmltR2IoGIXL; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O7Soy-0004co-KD; Thu, 29 Apr 2010 06:26:24 -0600 Message-ID: <4BD97AF5.3070203@labn.net> Date: Thu, 29 Apr 2010 08:26:29 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: Greg Bernstein , Malcolm.BETTS@zte.com.cn References: <4BD72E84.9080307@labn.net> <4BD87610.20303@grotto-networking.com> In-Reply-To: <4BD87610.20303@grotto-networking.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Draft Response to Liaison Statement, "OTN and WSON work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 12:30:32 -0000 Greg, Can you contact Malcolm and have an (on or off-line) discussion on this topic and come back with a recommended set of changes to either the impairments draft or the Liaison? Much thanks, Lou On 4/28/2010 1:53 PM, Greg Bernstein wrote: > Hi Deborah and Lou, this seems fine to me. I think we still need more > discussions with ITU-T on the definition and use of the term "black > link". They had some comments in the liaison on our use of the term in > the impairments draft but we thought our use was consistent with what we > had read so far in ITU-T documents. > > Cheers > > Greg B. > > > On 4/27/2010 11:35 AM, Lou Berger wrote: >> All, >> The enclosed is a proposed response to three Liaisons received from >> Q12. Please send any comments you have by May 11th. >> >> Thank you, >> Deborah and Lou >> >> ------------------------------------------------------------- >> To: greg.jones@itu.int >> Cc: ccamp@ietf.org; greg.jones@itu.int; sob@harvard.edu; >> yoichi.maeda@ntt-at.co.jp; paf@cisco.com; adrian.farrel@huawei.com; >> tsbsg15@itu.int; malcolm.betts@zte.com.cn >> >> Subject: New Liaison Statement, "OTN and WSON work in CCAMP" >> >> Title: OTN and WSON work in CCAMP >> Submission Date: 2010-xx-xx >> >> From: Deborah Brungard (IETF CCAMP WG) >> To: ITU-T SG15 Q12 (greg.jones@itu.int) >> Cc: yoichi.maeda@ntt-at.co.jp >> greg.jones@itu.int >> malcolm.betts@zte.com.cn >> tsbsg15@itu.int >> adrian.farrel@huawei.com >> stbryant@cisco.com >> paf@cisco.com >> ccamp@ietf.org >> lberger@labn.net >> Reponse Contact: dbrungard@att.com >> Technical Contact: dbrungard@att.com >> sob@harvard.edu >> Purpose: For information >> >> >> Thank you for your liaison statements "COM 15 – LS 100 – E", and "COM 15 >> – LS 138 – E" on your plans to update G.872 the OTN architecture to >> reflect the G.709 updates. >> >> We would like to inform you that the CCAMP Working Group recently >> accepted as a Working Group draft: >> http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g709-framework-00.txt >> >> This document will serve as our basis for further work. Please keep us >> informed as you progress your work. >> >> Regarding your liaison "COM 15 – LS 86 – E", "Comments on WSON >> Impairment Work in CCAMP", we thank you for your comments and we will >> take these into consideration as we progress our work. We note that you >> will initiate work to update the architecture and control plane >> Recommendations related to WSON. Please keep us informed as you progress >> this work. >> >> We look forward to continuing our cooperative relationship with you on >> these topics. >> >> Deborah Brungard >> Lou Berger >> >> CCAMP Working Group co-Chairs >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > From swallow@cisco.com Thu Apr 29 07:19:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB043A6B0A; Thu, 29 Apr 2010 07:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.226 X-Spam-Level: X-Spam-Status: No, score=-8.226 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJwmjgn6ploq; Thu, 29 Apr 2010 07:19:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 817833A6C06; Thu, 29 Apr 2010 07:14:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFAMUx2UutJV2Z/2dsb2JhbACBP5pyXXGkNpoIAoUOBA X-IronPort-AV: E=Sophos;i="4.52,295,1270425600"; d="scan'208,217";a="106314741" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 29 Apr 2010 14:14:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o3TEELY1018355; Thu, 29 Apr 2010 14:14:22 GMT Received: from xmb-rcd-106.cisco.com ([72.163.62.148]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 09:14:03 -0500 Received: from 10.98.32.165 ([10.98.32.165]) by XMB-RCD-106.cisco.com ([72.163.62.148]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 Apr 2010 14:14:02 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 29 Apr 2010 10:14:01 -0400 From: George Swallow To: Shahram Davari , Loa Andersson , , , , Message-ID: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 Thread-Index: AcrBczT1LsEVDiSwTX2v9QSMrvpjyAAA7NaQCYvTuPM= In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68171AE5BF5@SJEXCHCCR02.corp.ad.broadcom.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3355380842_133468876" X-OriginalArrivalTime: 29 Apr 2010 14:14:03.0322 (UTC) FILETIME=[3892E9A0:01CAE7A6] Subject: Re: [CCAMP] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:19:05 -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_3355380842_133468876 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Shahram - See inline On 3/11/10 7:27 PM, "Shahram Davari" wrote: > Hi, >=20 > Couple of comments: >=20 > 1) Why the Interface_ID is 32-bit while the Tunnel_ID is 16-bit? Do we ne= ed to > support more interfaces than tunnels? GS: Planning to change scope of Tunnel_ID. Just needs to be unique in the context of the Session Object as defined in 3209 with source address used a= s the extended tunnel-id > 2) The draft defines the Global_Tunnel_ID as: > Src-Global_ID::Src-Node_ID::Src-Tunnel_Num:: > Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num >=20 > This seems to define a bidirectional tunnel. Is that the intent? If so pl= ease > clarify. If not then why Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is ne= eded? >=20 GS: The scope is bidirectional. But I suppose it can be applied to unidirectional as well. I still don=B9t understand the requirement for unidirectional =AD seems to be that bidirectional with 0 data-bandwidth in th= e reverse direction would do better as you would have a return path for OAM and DCC etc. >=20 > 3) Is section 5.2 talking about unidirectional LSP or bidirectional LSP? >=20 GS: Ditto >=20 > 4) Section 7.1.2.1 says: > Since a MEG pertains to a single MPLS-TP Tunnel, IP compatible ME= G_IDs > for MPLS-TP Tunnels are simply the corresponding Tunnel_IDs >=20 > Assuming the Tunnel_ID is a unidirectional ID, then this statement implie= s > that for the reverse direction a different MEG_ID is required. Is that th= e > intent? If so why? >=20 GS: Not unidirectional! >=20 > 5) Why are drafts part of the normative references? >=20 Cut and paste error actually! Thanks for pointing it out! >=20 > 6) Will section 8 (open issues) be removed before publishing? This sectio= n > implies that the MEP and MIP definition is not yet aligned with framework= ? >=20 GS: Yes >=20 > Regards, > Shahram >=20 >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Thursday, March 11, 2010 3:33 PM > To: mpls@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01 >=20 > All, >=20 > this is to start an MPLS working group last call on > draft-ietf-mpls-tp-identifiers-01 >=20 > There is a discussion on the OAM model for MS-PWs where we haven't been > able to come to conclusion. Once we reach agreement the document will > be updated. Comments in this area are welcome during the working group > last call. >=20 >=20 > Please send your comments to the mpls-tp@ietf.org mailing list. >=20 > The working group last ends eob April 2nd. >=20 > /Loa >=20 > -- >=20 > Loa Andersson >=20 > Sr Strategy and Standards Manager > Ericsson /// > phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 > email: loa.andersson@ericsson.com > loa@pi.nu >=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 --B_3355380842_133468876 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01</T= ITLE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:14pt'>Shahram= -<BR> <BR> See inline<BR> <BR> <BR> On 3/11/10 7:27 PM, "Shahram Davari" <<a href=3D"davari@broadcom= .com">davari@broadcom.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'>Hi,<BR> <BR> Couple of comments:<BR> <BR> 1) Why the Interface_ID is 32-bit while the Tunnel_ID is 16-bit? Do we need= to support more interfaces than tunnels?<BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'><BR> GS:  Planning to change scope of Tunnel_ID.  Just needs to be uni= que in the context of the Session Object as defined in 3209 with source addr= ess used as the extended tunnel-id<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'>2) The draft defines the Global_Tunnel_ID as:<BR>       Src-Global_ID::Src-Node_ID::Src-Tunnel_= Num:: Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num<BR> <BR> This seems to define a bidirectional tunnel. Is that the intent? If so plea= se clarify. If not then why Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is ne= eded?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: The scope is bidirectional.  But I suppose it c= an be applied to unidirectional as well.  I still don’t understan= d the requirement for unidirectional – seems to be that bidirectional = with 0 data-bandwidth in the reverse direction would do better as you would = have a return path for OAM and DCC etc.<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 3) Is section 5.2 talking about unidirectional LSP or bidirectional LSP?<BR= > <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Ditto<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 4) Section 7.1.2.1 says:<BR>         Since a MEG pertains to a s= ingle MPLS-TP Tunnel, IP compatible MEG_IDs for MPLS-TP Tunnels are simply t= he corresponding Tunnel_IDs<BR> <BR> Assuming the Tunnel_ID is a unidirectional ID, then this statement implies = that for the reverse direction a different MEG_ID is required. Is that the i= ntent? If so why?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Not unidirectional!<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 5) Why are drafts part of the normative references?<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>Cut and paste error actually!  Thanks for pointing = it out!<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> 6) Will section 8 (open issues) be removed before publishing? This section = implies that the MEP and MIP definition is not yet aligned with framework?<B= R> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY= LE=3D'font-size:14pt'>GS: Yes<BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14pt'><BR> Regards,<BR> Shahram<BR> <BR> <BR> <BR> -----Original Message-----<BR> From: <a href=3D"mpls-bounces@ietf.org">mpls-bounces@ietf.org</a> [<a href=3D"m= ailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</a>] On Behalf Of = Loa Andersson<BR> Sent: Thursday, March 11, 2010 3:33 PM<BR> To: <a href=3D"mpls@ietf.org">mpls@ietf.org</a>; <a href=3D"mpls-tp@ietf.org">m= pls-tp@ietf.org</a>; <a href=3D"pwe3@ietf.org">pwe3@ietf.org</a>; <a href=3D"cca= mp@ietf.org">ccamp@ietf.org</a><BR> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01<BR> <BR> All,<BR> <BR> this is to start an MPLS working group last call on<BR> draft-ietf-mpls-tp-identifiers-01<BR> <BR> There is a discussion on the OAM model for MS-PWs where we haven't been<BR> able to come to conclusion. Once we reach agreement the document will<BR> be updated. Comments in this area are welcome during the working group<BR> last call.<BR> <BR> <BR> Please send your comments to the <a href=3D"mpls-tp@ietf.org">mpls-tp@ietf.or= g</a> mailing list.<BR> <BR> The working group last ends eob April 2nd.<BR> <BR> /Loa<BR> <BR> --<BR> <BR> Loa Andersson<BR> <BR> Sr Strategy and Standards Manager<BR> Ericsson ///<BR>    phone:  +46 10 717 52 13<BR>            +46 767 7= 2 92 13<BR> <BR>    email:  <a href=3D"loa.andersson@ericsson.com">loa.and= ersson@ericsson.com</a><BR>            <a href=3D"= loa@pi.nu">loa@pi.nu</a><BR> <BR> <BR> <BR> <BR> _______________________________________________<BR> mpls mailing list<BR> <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><BR> <BR> <BR> _______________________________________________<BR> mpls mailing list<BR> <a href=3D"mpls@ietf.org">mpls@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --B_3355380842_133468876-- From dieter.beller@alcatel-lucent.com Fri Apr 30 04:48:47 2010 Return-Path: <dieter.beller@alcatel-lucent.com> X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCCE3A6969 for <ccamp@core3.amsl.com>; Fri, 30 Apr 2010 04:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.897 X-Spam-Level: X-Spam-Status: No, score=-3.897 tagged_above=-999 required=5 tests=[AWL=-1.706, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3KVyqCIwyzG for <ccamp@core3.amsl.com>; Fri, 30 Apr 2010 04:48:45 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id D86973A69B8 for <ccamp@ietf.org>; Fri, 30 Apr 2010 04:48:44 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3UBks06015091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Apr 2010 13:48:25 +0200 Received: from [149.204.106.249] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 30 Apr 2010 13:48:22 +0200 Message-ID: <4BDAC383.5040801@alcatel-lucent.com> Date: Fri, 30 Apr 2010 13:48:19 +0200 From: Dieter Beller <Dieter.Beller@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Gladwin Ramoshaba <Gladwin.Ramoshaba@neotel.co.za> References: <775409D245199443BECA1684DF93527A1B18C35ABA@EXMAIL.neotel.co.za> In-Reply-To: <775409D245199443BECA1684DF93527A1B18C35ABA@EXMAIL.neotel.co.za> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "Diego.Caviglia@marconi.com" <Diego.Caviglia@marconi.com>, "ccamp@ietf.org" <ccamp@ietf.org> Subject: Re: [CCAMP] VC4-4c and VC4-4v X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ccamp> List-Post: <mailto:ccamp@ietf.org> List-Help: <mailto:ccamp-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Apr 2010 11:48:47 -0000 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Trebuchet MS">Hi Gladwin,<br> <br> ITU-T Recommendation G.707 defines two mechanisms of concatenating VC-4<br> signals: contiguous and virtual concatenation.<br> <br> Please check G.707 (chapter 11) which can be found under the following URL:<br> </font><tt><a class="moz-txt-link-freetext" href="http://www.itu.int/itu-t/recommendations/index.aspx?ser=G">http://www.itu.int/itu-t/recommendations/index.aspx?ser=G</a></tt><font face="Trebuchet MS"><br> <br> I hope this helps.<br> <br> <br> Regards,<br> Dieter<br> </font><br> On 30.04.2010 13:27, Gladwin Ramoshaba wrote: <blockquote cite="mid:775409D245199443BECA1684DF93527A1B18C35ABA@EXMAIL.neotel.co.za" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <meta name="Generator" content="Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.Section1 {page:Section1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="Section1"> <p class="MsoNormal">Hi Guys,<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">My name is Gladwin from South Africa I actually work on one of the Telco companies here at home.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I was browsing on the net and I came across this topic, of which I’m sitting in a situation as  I write this mail to you .<o:p></o:p></p> <p class="MsoNormal">Firstly I would like you to explain the difference between VC4-4c and VC4-4v<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I do understand the 4c because it’s 4x VC4 concatenated on one VCG to make 622Mb/s and the VC4’s are in sequence eg 1,2,3,4 or 13,14,15,16 etc<o:p></o:p></p> <p class="MsoNormal">The way I understand the 4v is that the VC4’s can be out of sequence when creating a trail you can choose randomly eg VC4 #1,7,10,16 etc<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Is this how it should be ?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Regards<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><span lang="EN-US">Gladwin Ramoshaba<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">Transmission Tac2<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">Office:+27 11 585 0486<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">Mobile:+27 82 061 1111<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US">Fax:+27 86 521 7072<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US"><a class="moz-txt-link-abbreviated" href="mailto:email:gladwin.ramoshaba@neotel.co.za">email:gladwin.ramoshaba@neotel.co.za</a><o:p></o:p></span></p> <p class="MsoNormal"><o:p> </o:p></p> </div> <br> <hr> <font size="3" color="Gray" face="Arial">Neotel is a level 3 B-BBEE contributor. EmpowerLogic Rating: EE<br> Note<br> Information about Neotel directors and registration number is available at <a class="moz-txt-link-freetext" href="http://www.neotel.co.za/about/Pages/OurBoardofDirectors.aspx">http://www.neotel.co.za/about/Pages/OurBoardofDirectors.aspx</a><br> A disclaimer relating to the above email is available at <a class="moz-txt-link-freetext" href="http://www.neotel.co.za/Pages/Disclaimer.aspx">http://www.neotel.co.za/Pages/Disclaimer.aspx</a><br> <br> <br> </font></blockquote> <br> <div class="moz-signature">-- <br> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <title>