RE: Static VPLS MAC withdrawal draft

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 10 May 2012 14:11 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1718E21F865F for <l2vpn@ietfa.amsl.com>; Thu, 10 May 2012 07:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.531
X-Spam-Level:
X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyzdcGHUzeqp for <l2vpn@ietfa.amsl.com>; Thu, 10 May 2012 07:11:27 -0700 (PDT)
Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0666321F865A for <l2vpn@ietf.org>; Thu, 10 May 2012 07:11:26 -0700 (PDT)
Received: from [85.158.143.99:64581] by server-1.bemta-4.messagelabs.com id C5/A7-20925-E8CCBAF4; Thu, 10 May 2012 14:11:26 +0000
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1336659081!20349993!1
X-Originating-IP: [168.87.1.157]
X-StarScan-Version: 6.5.10; banners=-,-,-
Received: (qmail 21197 invoked from network); 10 May 2012 14:11:21 -0000
Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-6.tower-216.messagelabs.com with SMTP; 10 May 2012 14:11:21 -0000
X-AuditID: a8571401-b7f8d6d0000035b0-1a-4fabcd113218
Received: from FRIDWPPCH002.ecitele.com (fridwppch002.ecitele.com [10.1.16.53]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id CF.93.13744.11DCBAF4; Thu, 10 May 2012 16:13:38 +0200 (CEST)
Received: from FRIDWPPMB001.ecitele.com ([169.254.3.187]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Thu, 10 May 2012 16:11:20 +0200
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "msiva@cisco.com" <msiva@cisco.com>, "Sami Boutros (sboutros@cisco.com)" <sboutros@cisco.com>, "nmcgill@cisco.com" <nmcgill@cisco.com>
Subject: RE: Static VPLS MAC withdrawal draft
Thread-Topic: Static VPLS MAC withdrawal draft
Thread-Index: Ac0tTYm5TIv9pECE0EWc8IlBO2eaCQBZSqlwAAD+M1A=
Date: Thu, 10 May 2012 14:11:19 +0000
Message-ID: <F9336571731ADE42A5397FC831CEAA02056539@FRIDWPPMB001.ecitele.com>
References: <CBCF2D0B.1AAF5%giles.heron@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.4.42.92]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0gUURj17syO4+bEtG3udemxDVhQraxkuT1WCiJUiJUeSP7Rafa6O7U7 O+2sov1JJcqkKMOsNrE0tdTKjKDUIlM0ssxeRGVJaC/NikQqkaIZx8zo/jr3O+d8j3s/EtP3 ECaSFwLIL7AehtDhOhBisui76hzW9hs629v248DW/6011Pag7zZm6/30Q2PrKB4Ga7QJxWMN 2oTG4KvQhMrKUU0ylpoLVrOC4AuwAWR2IomzM8l+Povlchgz77QzMYxZ9LAc8iIhYGdYUUSC k4nXmf87q2UZL5iRwPmcvOCyM4mbHBabbdkKSwwTv9nNS2Zk8bK8x+xFksS6kFmOKBMIzvSL mPte5yNCrJqd/exnBZ4LKiIKQRgJ6Vi4b2RMo+II+KC3nigEOlJPPwHwW2/LxKUKwNHKekxR EbQdXq57NU4Y6AMAlh89LxMkidFJcPRjuqKZSVtg96HnhIINdDQcay8BKl4J3+V1ahWM01Gw caRrPE7RG2Bzae94F3p6KTw5UowrGMgdfe88Px7HaCN88ebURKc0rLzejal4Fhzo/6VV8VyY X/MkVNUvgaebhwkVL4bV5R8xtdYMeOfEG1zVR8Jb557hh0FEcEqJ4BR7cIo9OMV+GuC1wJjh 552iKG2zWmOiEccHkAdFcz7vZSCvy7kUA7gG+g5GtwKaBEw41ZJX69Br2Swpx9sKIkkNM4ta frvOoZ++zefMcbOSO82f6UFSK4Akxhio0mMyRznZnF3I7/tD2eR3K8JM0zif8q2BtKVW6z8X xkjVb4x36GmXvGs7EBKR/491NkkykBq6K2ed4UculJ3BewJ/aQ0ZplQOlyvfUjSUJLJeiXep fCeINBmpaoWgFcKdKUx6B4FRnm8m1aOw4fK+TboG5YQaOWFJW42SUN7/ScqUCxIXFnk/2MWw Jm3U45fY59f9Z5kfKYRDggVXrxz+8p7bObClu6MtpGGgpyUx68WyeR3rtp9Zu7zwUtn26rxU d/aq/W0FDfPbIx9uLV9QnPDzQ1FP5u6bDVxcis9Tj6+9FBLIS6poukA8XbyXHLofa4jrYufg ZYnG/D1f849EjWRsWs/gkpuNWYT5JfY3TpEyiO4DAAA=
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2012 14:11:28 -0000

Resending with less addressees...

Regards,
     Sasha


> -----Original Message-----
> From: Alexander Vainshtein
> Sent: Thursday, May 10, 2012 5:08 PM
> To: 'msiva@cisco.com:'; Sami Boutros (sboutros@cisco.com);
> 'nmcgill@cisco.com'
> Cc: l2vpn@ietf.org; 'Giles Heron'; Rotem Cohen; Andrew Sergeev; Mishael
> Wexler; Gideon Agmon
> Subject: RE: Static VPLS MAC withdrawal draft
> 
> Hi all,
> I've read the draft in question and I would like to clarify several issues that
> look either undefined or ambiguous to me.
> 
> 1. To the best of my understanding, the draft requires each PE participating
> in a given VPLS instance to set up two counters for each static PW
> connecting it to a peer PE device in this VPLS instance: one for static MAC
> withdrawal messages it is going to send and another - for static MAC
> withdrawal messages it receives. Is this understanding correct?
> 
> 2. Assuming a positive answer to the previous questions, how are these
> counters initialized? The draft seems to be moot on this point. The more
> interesting question is, of course, about initialization of the counter of
> received static MAC withdrawal messages, since, with static PWs, generally
> speaking, there is no synchronization between setting up one of its end
> points and setting up another one.
> 
> 3. The draft specifies that:
> 	- The transmitter sends the MAC withdrawal message with the same
> sequence number until it receives an ACK for it (Section 4.1.1)
> 	- The receiver, after having acknowledged a MAC withdrawal
> message, ignores refresh messages with the same sequence number
> (Section 4.1.2)
>   What is supposed to happen in the following scenario:
> 	- Transmitter finds out that some MACs have to be withdrawn (e.g.,
> because the AC from which they have been learned fails)
> 	   and sends a MAC withdrawal message to its peers with sequence
> number N
> 	- Immediately after that (i.e., before it receives an ACK for this
> message) it finds out that yet another set of MAC addresses has to be
> withdrawn
> 	- Retransmission timer expires without ACK received.
> 
> 4. Suppose that only one end point of a static PW between a given pair of
> peers has been set up. In this case transmitting the static MAC withdrawal
> messages via such a PW is possible, but ACKs will never be received. Should
> retransmission of these messages go on "ad infinitum"?
> 
> 5. The draft does not specify any default value for the retransmit time.
> 
> 6. A nit:  Heading of Section 4 is followed by headings for Sections 4.1.1 and
> 4.1.2 without any heading for 4.1.
> 
> Hopefully these questions will be useful.
> 
> Regards,
>      Sasha
> 
> > -----Original Message-----
> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
> > Of Giles Heron
> > Sent: Tuesday, May 08, 2012 10:06 PM
> > To: l2vpn@ietf.org
> > Subject: Static VPLS MAC withdrawal draft
> >
> > Hi everyone,
> >
> > The following draft was presented at IETF in Paris:
> >
> > http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00
> >
> > The authors have asked for it to be adopted as a WG draft, but at this stage
> > the chairs' view is that it probably hasn't had enough sets of eyes on it.
> >
> > So this email is to request that those on the list take a read of the draft
> > and send comments back to the list.  Depending on the response we get
> we
> > may
> > then ask the WG if they feel happy adopting this as a WG draft.
> >
> > Nabil and Giles
> >


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