From l2vpn-bounces@ietf.org Tue May 03 06:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSv6w-0003xa-UE; Tue, 03 May 2005 06:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSv6u-0003ud-Ps for l2vpn@megatron.ietf.org; Tue, 03 May 2005 06:58:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00556 for ; Tue, 3 May 2005 06:58:37 -0400 (EDT) Received: from mail.greenfieldnetworks.com ([64.220.152.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSvKm-0005JN-Fz for l2vpn@ietf.org; Tue, 03 May 2005 07:13:00 -0400 Received: from [10.20.20.141] ([10.20.20.141]) by mail.greenfieldnetworks.com (8.11.6/8.11.2) with ESMTP id j43AwW102491 for ; Tue, 3 May 2005 03:58:32 -0700 Message-ID: <42775A67.1080900@greenfieldnetworks.com> Date: Tue, 03 May 2005 16:33:03 +0530 From: Ravindra Rathi User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org References: <200502222104.QAA21016@ietf.org> In-Reply-To: <200502222104.QAA21016@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: Comments on draft-ietf-l2vpn-vpls-ldp-06.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org 1. Section 4.1.2 'Address Withdraw Message Containing MAC TLV' and section 4.2 'MAC Address Withdrawal' have similar descriptions. They may be combined. 2. The last paragraph in Section 5.2, VPLS Learning actions, states that: -- BEGIN -- In a basic VPLS case, upstream switches must insert such service delimiting tags. When an access port is shared among multiple customers, a reserved VLAN per customer domain must be used to carry STP/MSTP traffic. The STP/MSTP frames are encapsulated with a unique provider tag per customer (as the regular customer traffic), and a PEs looks up the provider tag to send such frames across the proper VPLS instance. -- END -- I believe the lines quoted above should be rephrased for clarity. Doesn't the "service delimiting tag", "reserved VLAN per customer" and "unique provider tag" in the lines above refer to the same tag. My interpretation of the quoted lines is: There MUST be a service delimiting tag in _all_ the frames received by the PE for STP/MSTP to work correctly in qualified mode since STP/MSTP BPDUS do not contain the customer vlan tag. Let me know if I am wrong about '_all_ the frames' part. I believe that 'must' in the quoted text should be replaced with RFC convention 'MUST'. 3. Section 5.1 says that service-delimiting tag is used to identify the vrf instance if it is present. But it doesn't explain clearly how the vrf instance is identified if the service-delimiting tag is not present. In section 5.2, couple of possibilities are discussed. a. For unqualified learning, ingress port can be used to identify the vrf instance. b. For qualified learning, customer vlan and/or ingress port in the frame is used to identify the vrf instance. Text should be added to explain this clearly. A related question is, whether separate PWs should be setup between PEs per customer per customer VLAN since each of them identify a separate vrf instance ? 4. One minor comment. On page 2, the version numbers of all the referred drafts should be updated. Thanks, Rathi From l2vpn-bounces@ietf.org Wed May 04 11:26:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLlQ-0006SR-Th; Wed, 04 May 2005 11:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTLlP-0006Pe-0p for l2vpn@megatron.ietf.org; Wed, 04 May 2005 11:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21324 for ; Wed, 4 May 2005 11:26:12 -0400 (EDT) From: prabakarts@future.futsoft.com Received: from [202.56.251.200] (helo=mail.future.futsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLzU-0001hF-Tt for l2vpn@ietf.org; Wed, 04 May 2005 11:40:50 -0400 Received: from kailash.future.futsoft.com (unverified [10.203.112.3]) by mail.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Wed, 4 May 2005 20:44:03 +0530 Received: from webmail.future.futsoft.com (webmail.future.futsoft.com [10.203.112.133]) by kailash.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j44FC07K017961; Wed, 4 May 2005 20:42:00 +0530 Received: from webmail.future.futsoft.com (localhost.localdomain [127.0.0.1]) by webmail.future.futsoft.com (8.12.8/8.12.8) with ESMTP id j44FBarg032518; Wed, 4 May 2005 20:41:36 +0530 Received: (from apache@localhost) by webmail.future.futsoft.com (8.12.8/8.12.8/Submit) id j44FBaZr032516; Wed, 4 May 2005 20:41:36 +0530 X-Authentication-Warning: webmail.future.futsoft.com: apache set sender to prabakarts@future.futsoft.com using -f Received: from 208.246.215.5 (SquirrelMail authenticated user prabakarts) by webmail.futsoft.com with HTTP; Wed, 4 May 2005 20:41:36 +0530 (IST) Message-ID: <3734.208.246.215.5.1115219496.squirrel@webmail.futsoft.com> Date: Wed, 4 May 2005 20:41:36 +0530 (IST) To: l2vpn@ietf.org, vipinietf@yahoo.com User-Agent: SquirrelMail/1.4.2-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 1.3 (+) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 8bit Cc: psampath@avici.com Subject: Re: FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Vipin, Sorry for the delayed reply, some how I missed this mail in my Inbox, just now found in the mailing-list and replying. I have updated the draft into draft-praba-l2vpn-vpls-mcast-emul-01.txt. Please see my inlined reply . Thanks for your comments. Best regards, Prabakaran T.S. Two comments, based on my understanding of the draft so far: - Why not allow register/deregister per multicast address. Without that, it would be either all or none of the multicast traffic getting forwarded on PE for a given VPLS instance. I mean, isn't that a severe limitation? Please note that we are not using any multicasting protocol to do the required filtering operation. The main aim of the draft is to avoid flooding of multicast traffic in all the PWs and it is independent/transparent of any multicast addresses. Our draft implementation will be more useful in the switches where there is no need of running multicast protocols to do the simple multicast data filtering operation on the PWs which are all not interested in the mesh topology. As you said, this is not a limitation for the given VPLS instance, this is a limitation for the particular PW in the VPLS instance which enabled this filter, not to all PWs in the VPLS instance. More over our assumption is whenever the user wants to enable/disable our filter, they can very well does through configurations, the corresponding LDP Notification messages will be send to the peer and enables the required operation. - VPLS keeps the layer2 transparency as much as possible. Introducing the configuration you propose requires explicit knowledge of customer, whose data is being subjected to this constraint. Do you agree? On other hand, I see snooping mechanism independent of any such customer agreement/interaction. I know that VPLS keeps the layer2 transparency(which may be an advantage/disadvantage, I don't know how to comment) but this is a kind of proposal came up because of this transparency to avoid multicast flooding on all the PWs which are all not interested at a given point. Our aim is to avoid the over head of Snooping mechanism in all the PE's and to reduce the overhead of running any multicast protocols and to make use of existing LDP signalling itself to perform the multicast data filtering. Our proposal will be much helpful, easy to implement, no complexity and a very simple implementation in the places where the switches don't want to add multicast protocol running over heads. thanks, -- vipin --- Prabakaran T Sampath wrote: > Dear L2VPN-WG, > > This is Prabakaran T.S. and Musthafa A.S. from FutureSoft, a Flextronics > company. > We have come up with some concept and contributed it as a IETF > draft in VPLS. Kindly go through this draft > and give us your valuable comments and feedback either in > IETF VPLS working group or directly to us by email. > > Thanks in advance, > > Best regards, > Prabakaran T.S. > Musthafa A.S. > FutureSoft, a Flextronics company, > 480-481 Anna salai, > Nandanam, > Chennai-600035. INDIA. > Ph: +91-44-24330550, extn: 459 > > > -----Original Message----- > From: i-d-announce-bounces at ietf.org > [mailto:i-d-announce-bounces at ietf.org]On Behalf Of > Internet-Drafts at ietf.org > Sent: Friday, 11 February 2005 2:18 AM > To: i-d-announce at ietf.org > Subject: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Multicast Emulation over VPLS > Author(s) : Prabakaran T.S, Musthafa A.S > Filename : draft-praba-l2vpn-vpls-mcast-emul-00.txt > Pages : 14 > Date : 2005-2-10 > > In Virtual Private LAN Service (VPLS), the PE devices provide a > logical interconnect such that CE devices belonging to a specific > VPLS instance appear to be connected by a single LAN. A VPLS > solution performs replication for multicast traffic at the ingress > PE devices. When replicated at the ingress PE, multicast traffic > wastes bandwidth when 1. Multicast traffic is sent to sites with no > members, and 2. Pseudo wires to different sites go through a shared > path. This document addresses the above cases by using LDP > signaling to emulate Multicast operation over VPLS with out using > IGMP and PIM snooping as described in [VPLS-MCAST]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-praba-l2vpn-vpls-mcast-emul-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ATTACHMENT part 2 message/external-body name=ATT00108.dat > ATTACHMENT part 3 message/external-body name=draft-praba-l2vpn-vpls-mcast-emul-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce at ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From l2vpn-bounces@ietf.org Fri May 06 01:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTviu-0000Nu-GP; Fri, 06 May 2005 01:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTvis-0000Mm-Cw for l2vpn@megatron.ietf.org; Fri, 06 May 2005 01:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10388 for ; Fri, 6 May 2005 01:50:01 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTvxJ-0000Lo-Lm for l2vpn@ietf.org; Fri, 06 May 2005 02:04:58 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 May 2005 01:49:54 -0400 Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j465nmdw028000; Fri, 6 May 2005 01:49:49 -0400 (EDT) Message-ID: <427B057C.7040808@cisco.com> Date: Thu, 05 May 2005 23:49:48 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shah, Himanshu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, vach.kompella@alcatel.com Subject: Re: WG Last Call on ARPmediation draft:draft-ietf-l2vpn-arp-mediation-01.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Himanshu, more comments in line. Thanks. Luca Shah, Himanshu wrote: > Hi Luca, Thanks for your comments. Responses in line marked with > "himanshu>" regards, himanshu > > -----Original Message----- > *From:* l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]*On > Behalf Of *Luca Martini > *Sent:* Monday, April 25, 2005 9:21 PM > *To:* vach.kompella@alcatel.com > *Cc:* l2vpn@ietf.org > *Subject:* Re: WG Last Call on ARPmediation > draft:draft-ietf-l2vpn-arp-mediation-01.txt > > Vach, > > I finally had made the time to read this draft. Here are some > comments: > > - I'll say it first ( I'm sure the IESG would say the same ) : > there seem to be a bit too many authors. I think this list needs > to be trimmed to people you can attribute some text in the > document to. I believe 5 authors is the maximum, without having to > really justify it. > [himanshu>] Noted. > - The introduction section needs to make it clear that A PW of > type IP is used. It should reference PWE3-CONTROL. > [himanshu>] Noted. > - Please fix all the non-ASCII characters in the document , Lot's > of "CE0x??E" and others. you need to turn off MS-word automatic > character substitution, or better still use emacs ;-) > [himanshu>] Noted > - Please change all the PWE3-IANA to PWE3-CONTROL. The IANA > document only specifies a PW type number , nothing more. > [himanshu>] Noted. > - Section 3.0: PWs are bi-directional by definition , so remove > the text "bi-directional" > [himanshu>] Noted > - Section 4.2 with the topology restriction to only one CE , > promiscuous ARP can be used to really simplify things. The > explanation should be added here. > [himanshu>] I am not sure what exact method you have in mind. Can > you elaborate?? > yes. If you restrict the ethernet broadcast domain to include only one host ( i.e. only one host is on the vlan , or attached to the ethernet port ) then it is possible to do promiscuous ARP on behalf of the remote link ip address. This means that any arp requests will be answered by the PE. I designed a prototype , and actually built PE with this capability. it worked quite well. This was presented in an mplscon conference about 3 years ago. I will send you the slides in a separate e-mail. > - Page 5 has some nordic region O characters in it ... not English. > [himanshu>] noted. > - section 5.2 and page 8. Define the IP Address interface > parameter , I believe it has been allocated in IANA so put the > number in here. > [himanshu>] I checked in the latest IANA draft, there is no > interface parameter for IP address. Besides, IP address in not > intended to be part of the interface parameter because that would > make it a static PW attribute. It is intentionally passed in the > optional parameter field of the Label Mapping message as the IP > address may not available when the PW FEC is exchanged. That is, > IP L2 Transport PW must be allowed to be established before the IP > address of the local CE is known. This way, multicast packets can > flow (such as OSPF hello) between the CEs, which in turn causes > ETH-CE to ARP for his peer. If ETH-attached PE is strictly > learning CE's IP address from ARP packets, this enables PE to > learn CE's IP address and can now send an update in LDP > NOTIFICATION message. > > Sorry my mistake . I remember the conversation a couple of years ago , yes it cannot be an interface parameter. > This section needs some major additions. There is no clear > description on how to work with the IP interface parameter. What > LDP notification message ? I do not recall defining anything other > then PW status messages. There is no way to change an interface > parameter once the PW is established. ( This is not an auxiliary > control channel ... it's static , can only be used once ) > [himanshu>] That is right. And hence there is no IP interface > parameter. Me and Hamid had written a > draft-shah-pwe3-control-protocol-extension-00.txt back in 2003. > This draft described how PEs can exchange capabilities and PW > attributes thereafter via LDP NOTIFICATION. About 4 cases were > sited in that draft, PW status, PW QOS, CE's IP address and CE's > IP and MAC address (used for IPLS). Out of which, you included the > PW status in the base PWE3-control draft but not others. Well, we > need the rest. Since that draft has expired, I have included the > text describing how exchange of CE's IP address can be conducted > as part of optional TLV of the LABEL MAPPING msg and LABEL > NOTIFICATION msg in this draft. > ok. Still you need a little more explanation how the IP address TLV is sent. what LDP message is it part of ? If is is part of a new ldp status message ? Luca > Spacing is wrong at the section 6.0 heading > [himanshu>] Noted > -PWE3 Control draft must be made normative. ( The procedures > described here are not implementable without pwe3-control ) > [himanshu>] Noted > > Thanks. > Luca > > > Vach Kompella wrote: > >>Two weeks are almost up, and there have been no comments on this draft. >>Either everyone is comfortable with the draft, or no one cares. In >>either case, we would like to hear comments. >> >>-Vach >> >> >> >>>-----Original Message----- >>>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >>>On Behalf Of Vach Kompella >>>Sent: Wednesday, April 06, 2005 1:08 PM >>>To: l2vpn@ietf.org >>>Subject: WG Last Call on ARP mediation >>>draft:draft-ietf-l2vpn-arp-mediation-01.txt >>> >>> >>>Folks, >>> >>>We are starting a 2 week working group Last Call on the ARP >>>mediation draft. Please read and send comments to the list. >>> >>>Thanks. >>> >>>Vach Kompella >>>IP Division, Alcatel >>>vach.kompella@alcatel.com >>>+1 650 623-2556 >>> >>> >>> >>> >> >> >> > From l2vpn-bounces@ietf.org Mon May 09 11:31:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAEJ-0001vF-Vp; Mon, 09 May 2005 11:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAEH-0001tt-Nj for l2vpn@megatron.ietf.org; Mon, 09 May 2005 11:31:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26695 for ; Mon, 9 May 2005 11:31:31 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVATQ-00059m-9r for l2vpn@ietf.org; Mon, 09 May 2005 11:47:12 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 09 May 2005 11:31:30 -0400 Received: from [209.245.27.1] ([10.32.241.115]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with SMTP id j49FVQnI000095 for ; Mon, 9 May 2005 11:31:27 -0400 (EDT) Message-ID: <427F824D.1090201@cisco.com> Date: Mon, 09 May 2005 09:31:25 -0600 From: Luca Martini User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [10.32.241.115] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Subject: meeting for 5/9 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Today's meeting is canceled. Thanks. Luca From l2vpn-bounces@ietf.org Tue May 10 06:32:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS28-0002VG-HE; Tue, 10 May 2005 06:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS26-0002VB-A7 for l2vpn@megatron.ietf.org; Tue, 10 May 2005 06:32:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05765 for ; Tue, 10 May 2005 06:32:07 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVSHO-0003qh-6o for l2vpn@ietf.org; Tue, 10 May 2005 06:47:59 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.43) id 1DVS1b-0005qc-2a; Tue, 10 May 2005 12:31:49 +0200 Message-ID: <42808CF3.1000504@pi.se> Date: Tue, 10 May 2005 12:29:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Lasserre References: <4268CCD7.3040803@pi.se> <426D208A.7020603@cisco.com> <039a01c549d2$a59851b0$6501a8c0@IBMT41ML> In-Reply-To: <039a01c549d2$a59851b0$6501a8c0@IBMT41ML> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: 7bit Cc: L2VPN , mpls@ietf.org, Rick Wilder , Bill Fenner , Mark Townsley , Margaret Wasserman , Luca Martini , Vach Kompella Subject: Re: [mpls] Re: Summary: mpls wg review of the draft-ietf-l2vpn-vpls-ldp-06.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Marc, inline please. Marc Lasserre wrote: > Besides agreeing with Luca's comments, I'd like to add that the > VPLS-LDP draft specifies how to reduce the size of the T-LDP full > mesh through hierarchical constructs in order to prevent scalability > problems with a large number of LDP adjacencies. Existing > deployments have demonstrated that large full mesh designs have > not caused scalabilty problems. Luca suggested that we try to substantiate this concern, I've suggested that we try to do so through some testing site. I would be open to discuss options. > > As far as MAC withdrawal is concerned, it is only used when a > primary AC fails, specifically in the case of dual-homed MTUs. Hence, > I do not see why LDP convergence time should be impacted. Re-reading the draft actually made me even more confused. Do you say that the MAC TLV is used only in one message? If so this should clearly be stated in the draft, if not we would need a list of the message in which the MAC TLV could appear. The message the you explictly say that the MAC TLV could go into is "MAC Address Withdraw Message". I would also prefer if we used the LDP terminology consistently, adding a new TLV won't change the name of an LDP message, I assume that a a "MAC Address Withdraw Message" is just an "Address Withdraw Message"? It is also said that: " The LDP Address Withdraw Message contains a FEC TLV (to identify the VPLS in consideration), a MAC Address TLV and optional parameters. No optional parameters have been defined for the MAC Address Withdraw signaling. " To be precise the LDP Address Withdraw Message base specification don't contain the FEC TLV, and I actually can't find where it has been specified as an optional TLV for the Address Withdraw Message. After re-reading the draft once more, and refering to the base LDP specification it is my impression that a major rework of the draft would be in place to align with the LDP concepts, terminology and style. /Loa > > I agree with the other comments from the group which call for > clarification. > > Marc > > ----- Original Message ----- From: "Luca Martini" > To: "Loa Andersson" > Cc: "L2VPN" ; ; "Rick Wilder" > ; "Bill Fenner" ; > "Mark Townsley" ; "Margaret Wasserman" > ; "Vach Kompella" > Sent: Monday, April 25, 2005 6:53 PM > Subject: [mpls] Re: Summary: mpls wg review of > thedraft-ietf-l2vpn-vpls-ldp-06.txt > > >> Loa, >> >> Comments in line... >> >> ..... >> >>> >>> Targeted LDP sessions >>> ---------------------- >>> One recurring theme is that a choice to use LDP to signaling >>> vpls de-multiplexors will lead to a full mesh of targeted >>> ldp session between PEs. It has been appointed out that this >>> will potentially cause scaling problems. >>> >>> WG-chair comment: LDP was never intended to support a full mesh of >>> targeted LDP sessions. >>> >>> >>> If LDP is used in this way it must clearly be stated that this is a >>> factor that will limit the scaling of the vpls application, >>> However this is nothing the changes or affects the workings of >>> other usages of LDP. This is local to this draft and should be >>> handled here. >>> >> I would like someone to actually substantiate that there would be a >> problem with a large number of targeted LDP sessions. >> It had been my experience that targeted LDP scales very easily beyond >> any number of session that would be deployed in this application. >> This is NOT BGP ! Let's not just assume that because BGP with hundreds >> of thousands routes, and very complex policies , does not scale in a >> full mesh environment, LDP will have the same fate. >> >> >>> MAC List TLV: >>> ------------- >>> A second point is made that the added TLV "MAC List TLV" >>> is an example of using LDP for something it was not intended >>> for. One issue here is that the already, as compared to a routing >>> protocol, long LDP convergence time could be even longer. This >>> will have effects on both "traditional" LDP convergence and the >>> vpls application. >>> >> >> As far as i remember , this is a TLV that is going to be used to >> indicate withdrawal of the mac addresses. >> When there is a link failure LDP does not advertise new IP label >> mappings, hence the only "slow down" will be in possibly withdrawing >> LDP IP label mappings ... >> And since these are targeted sessions it very likely that there will >> be no LDP ip label mappings in the first place. >> Nobody should care about LDP withdrawing IP label mapping , as the IGP >> is the master , and determines the convergence time. >> So what is going to be slowed down ? >> >>> The encoding of this TLV is not clearly defined. >>> First the diagram of the TLV depicts MAC addresses that are >>> only 4 bytes long. >>> Second, given the historic confusion between IEEE and IETF >>> encodings some discussion of bit and byte order and some >>> pointers to documents such as RFC1042 would be in order. >>> >>> WG-chair comment: >>> The MPLS working group is concerned about this issue. However >>> we need a better understanding of the dynamics involved before >>> a recommendation can be made. >>> >>> The text on the usage of this TLV is very difficult to parse. >>> Some clean-up is needed. Further use of this TLV should be >>> incorporated into the examples. >>> >>> Use of Generalized PWid FEC Element >>> ----------------------------------- >>> >>> Several fields are not clearly specified. >>> >>> E.g. in section 4.1.1: >>> >> Control bit (C): Depending on whether, on that particular PW, the >>> >> control word is desired or not, the control bit may be specified. >>> >>> >>> simply say: >>> >>> This bit is used to signal use of the control word as specified in >>> [PWE3-CTRL]. >>> >>> >>> >> PW type: The allowed PW types in this version are Ethernet and >>> >> Ethernet VLAN. >>> >>> >>> The phrase "in this version" should be deleted. >>> >>> >>> >> AGI Type field >>> >>> Either a value should be specified (along with a corresponding format) >>> or it should be stated how values are to be selected. >>> >>> >>> >> - Requested VLAN ID: If the PW type is Ethernet VLAN, this >>> >> parameter may be used to signal the insertion of the >>> >> appropriate VLAN ID. >>> >>> >>> This looks under specified. >>> >>> >>> >> Section 7. Operation of a VPLS >>> >>> Since FEC 128 has been moved to an appendix, this section should be >>> recast in terms of FEC 129. >>> >>> >> Section 8.2.2. Failure detection and recovery >>> >>> The hello message only detect control plane failures and not at a >>> particularly fast rate. If fast detection is needed, then >>> VCCV or BFD on the PSN tunnel should be employed. >>> >>> >>> MD5 and security >>> ---------------- >>> >>> A third point that has been made is that the security >>> considerations of the LDP specification were never designed >>> to meet the requirements of VPLS. >>> >>> WG-chair comment: This would definitely be of great concern, >>> but again it does not effect the LDP as a protocol but is >>> limited to the usage of LDP in this application. >>> >> this document should probably point to the pwe3 document and it's >> security section ... >> >> Luca >> >>> >>> /Loa and George >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/mpls >> >> > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se