From exim@www1.ietf.org Tue Nov 4 11:05:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20381 for ; Tue, 4 Nov 2003 11:05:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3g1-0005f1-9X for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 11:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4G55gD021753 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 11:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3g1-0005em-3i for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 11:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20359 for ; Tue, 4 Nov 2003 11:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3fy-0007fr-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 11:05:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH3fy-0007fn-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 11:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3fx-0005do-6S; Tue, 04 Nov 2003 11:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH3ez-0005an-C9 for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 11:04:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20328 for ; Tue, 4 Nov 2003 11:03:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH3ew-0007ef-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 11:03:58 -0500 Received: from sc-f100-01.extremenetworks.com ([63.251.106.30] helo=extrgate1.extremenetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AH3ew-0007eO-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 11:03:58 -0500 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Nov 2003 08:03:01 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E123FD8A@sc-msexch-16.extremenetworks.com> From: Olen Stokes To: "'Thippanna Hongal'" , Olen Stokes , marc.lasserre@riverstonenet.com, l2vpn@ietf.org Cc: pishwar@riverstonenet.com Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 08:03:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please see in line.... > -----Original Message----- > From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > Sent: Friday, October 31, 2003 6:08 PM > To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > l2vpn@ietf.org > Cc: pishwar@riverstonenet.com > Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > hi Stokes, > > Below is the packet format on the wire as we understand from > the draft. > We have a few questins on this. > > Packet for the PING > > dmac1 (Next hop router) > smac1 (Of the originating router) > Etype - 8847 > Transport label -|__________________ Pseudo wire > Vc label ------| > dmac2 (of the target mtu/pe to which the ping is targeted) > smac2 (of the originating router (PE/MTU)) > etype (IP 0x800) > ... > Mac TLV > smac3 -- (??) > dmac3 -- (customer's mac/spoke's mac to be pinged). > > a) Is the above representation correct? > Here is an internal debug dump of a VPLS ping about to be sent... 00 01 30 05 84 00 Next Hop Router MAC 00 01 30 08 92 00 Local (originating) Router MAC 88 47 Ethertype = MPLS cb 00 10 ff Tunnel Label 8c 00 40 ff VC Label 00 00 e1 ff OAM Label 00 01 30 05 84 00 Remote Spoke/Core MAC being pinged 00 01 02 03 04 05 Local Customer MAC 08 00 Ethertype = IP 45 IPv4 00 TOS 00 6c Length 00 80 ID 00 00 Offset ff TTL 11 protocol = UDP cc 31 Header Checksum 0b 64 64 09 Src IP 7f 00 00 62 Dst IP 95 80 UDP Src Port = 38272 0d af UDP Dst Port = 3503 00 58 UDP Length 00 00 UDP Checksum 00 01 LSP Ping Version Number = 1 00 00 Must Be Zero 01 Message Type = MPLS Echo Request 05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet 00 Return Code 00 Return Subcode 00 04 00 01 Sender's Handle 00 00 00 61 Sequence Number 3f a7 5e 0c Timestamp Sent (seconds) 00 04 ba f0 Timestamp Sent (microseconds) 00 00 00 00 Timestamp Received (seconds) 00 00 00 00 Timestamp Received (microseconds) 00 01 Type = Target FEC Stack 00 20 Length 00 0a Sub-Type = Hierarchical L2 Circuit ID 00 1c Length 00 00 07 d0 VC ID 00 05 Encapsulation Type = Ethernet 00 00 Must Be Zero 00 05 L2 Specific Sub-Type = Ethernet 00 10 Length 00 01 30 05 84 00 Target Ethernet MAC 00 00 00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) 00 00 00 03 Type = Pad 00 08 Length 02 Copy Pad TLV to Reply 44 45 41 44 Pad Data 42 45 45 > b) What is the value of the smac3 in the TLV. Is it mandatory ?. > Should the reply take the path using the smac3 for lookup > (for reply mode 5)? Pseudo Wire Connectivity verification ?. This is the MAC to which the reply should be sent. It is included to support implementations where the processing is distributed in case the MAC header is not passed along with the IP packet. Here is an internal debug dump of a reply to a similar VPLS ping about to be sent... 00 01 30 08 92 00 Next Hop Router MAC 00 01 30 05 84 00 Local (originating) Router MAC 88 47 Ethertype = MPLS cb 00 10 ff Tunnel Label 8c 00 30 ff VC Label 00 00 e1 ff OAM Label 00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender Ethernet MAC from request) 00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target Ethernet MAC from request) 08 00 Ethertype = IP 45 IPv4 00 TOS 00 78 Length 00 93 ID 00 00 Offset ff TTL 11 protocol = UDP cc 59 Header Checksum 0b 64 64 08 Src IP 7f 00 00 1c Dst IP 0d af UDP Src Port = 3503 95 80 UDP Dst Port = 38272 00 64 UDP Length 00 00 UDP Checksum 00 01 LSP Ping Version Number = 1 00 00 Must Be Zero 02 Message Type = MPLS Echo Reply 05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet 00 Return Code 00 Return Subcode 00 05 00 01 Sender's Handle 00 00 00 1b Sequence Number 3f a7 62 be Timestamp Sent (seconds) 00 06 8f b0 Timestamp Sent (microseconds) 3f a7 56 45 Timestamp Received (seconds) 00 04 ba f0 Timestamp Received (microseconds) 00 01 Type = Target FEC Stack 00 20 Length 00 0a Sub-Type = Hierarchical L2 Circuit ID 00 1c Length 00 00 07 d0 VC ID 00 05 Encapsulation Type = Ethernet 00 00 Must Be Zero 00 05 L2 Specific Sub-Type = Ethernet 00 10 Length 00 01 30 05 84 00 Target Ethernet MAC 00 00 00 01 02 03 04 05 Sender Ethernet MAC 00 00 00 04 Type = Error Code 00 08 Length 00 0a Sub-Type = Hierarchical L2 Circuit ID 00 04 Length 00 01 Error Code = Replying router is the Egress for the MAC 00 00 Must Be Zero 00 03 Type = Pad 00 08 Length 02 Copy Pad TLV to Reply 44 45 41 44 Pad Data 42 45 45 In this example, when the reply is received at the originating PE, the OAM label causes the packet to be processed at the PE and not forwarded to the customer. > > c) Is there any relation between smac2 and smac3 ?. > Normally they would be the same. > d) We have assumed that the dmac2 is either the mac of the > target MTU/PE. This is because if the customer dmac is > used the packet would show up at the customer. If the > router alert is used the the packet would not go beyond > the PE. So is this assumption correct ?. You need the OAM label to prevent the packet from reaching customer devices. Remember that if dmac2 is not known in the network, the packet may be flooded. It would then reach PEs other than the one associated with dmac2. The OAM label allows these switches to prevent the traffic reaching a customer. > > e) pre-condition: > To do a VPLS ping to verify customer MAC sitting at > the remote end, we have to have a actual customer > traffic flowing on > the pseudo-wire, or at least some customer traffic has > to be there > within the 'L2 age out' time period. > For VPLS ping to work, this is a pre-condition. > > Question is 'Is this a valid pre-condition ?', If yes, are users > OK with this model of OAM ?. > As stated above, if the MAC is unknown, the packet is to be flooded as would any normal packet. Therefore, the intent that this pre-condition should not be necessary. > > thanks > hongal > From exim@www1.ietf.org Tue Nov 4 11:40:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21776 for ; Tue, 4 Nov 2003 11:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Du-00083x-4s for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 11:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Ge690030987 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 11:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Dt-00083h-Rs for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 11:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21745 for ; Tue, 4 Nov 2003 11:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4Ds-0000PC-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 11:40:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH4Ds-0000P9-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 11:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4Dr-00082F-7d; Tue, 04 Nov 2003 11:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH4DA-00081M-B5 for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 11:39:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21713 for ; Tue, 4 Nov 2003 11:39:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH4D9-0000OV-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 11:39:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH4D8-0000O1-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 11:39:18 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2003 08:38:57 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA4GcVAt028486; Tue, 4 Nov 2003 08:38:36 -0800 (PST) Received: from tnadeauw2k02 (dhcp-10-86-165-58.cisco.com [10.86.165.58]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS07343; Tue, 4 Nov 2003 11:38:29 -0500 (EST) Reply-To: From: "Thomas D. Nadeau" To: "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 11:38:29 -0500 Organization: Cisco Systems, inc. Message-ID: <00e501c3a2f2$140f53c0$3aa5560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <3DC3910A44FBD94B8513C8E2A3F220E123FD8A@sc-msexch-16.extremenetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One question and one comment below. >-----Original Message----- >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On >Behalf Of Olen Stokes >Sent: Tuesday, November 04, 2003 11:04 AM >To: 'Thippanna Hongal'; Olen Stokes; >marc.lasserre@riverstonenet.com; l2vpn@ietf.org >Cc: pishwar@riverstonenet.com >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > >Please see in line.... > > > >> -----Original Message----- >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] >> Sent: Friday, October 31, 2003 6:08 PM >> To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; >> l2vpn@ietf.org >> Cc: pishwar@riverstonenet.com >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt >> >> >> hi Stokes, >> >> Below is the packet format on the wire as we understand from >> the draft. >> We have a few questins on this. >> >> Packet for the PING >> >> dmac1 (Next hop router) >> smac1 (Of the originating router) >> Etype - 8847 >> Transport label -|__________________ Pseudo wire >> Vc label ------| >> dmac2 (of the target mtu/pe to which the ping is targeted) >> smac2 (of the originating router (PE/MTU)) >> etype (IP 0x800) >> ... >> Mac TLV >> smac3 -- (??) >> dmac3 -- (customer's mac/spoke's mac to be pinged). >> >> a) Is the above representation correct? >> >Here is an internal debug dump of a VPLS ping about to be sent... > > >00 01 30 05 84 00 Next Hop Router MAC >00 01 30 08 92 00 Local (originating) Router MAC > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 40 ff VC Label >00 00 e1 ff OAM Label > >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged >00 01 02 03 04 05 Local Customer MAC >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 6c Length >00 80 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 31 Header Checksum >0b 64 64 09 Src IP >7f 00 00 62 Dst IP > >95 80 UDP Src Port = 38272 >0d af UDP Dst Port = 3503 >00 58 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >01 Message Type = MPLS Echo Request >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 04 00 01 Sender's Handle >00 00 00 61 Sequence Number >3f a7 5e 0c Timestamp Sent (seconds) >00 04 ba f0 Timestamp Sent (microseconds) >00 00 00 00 Timestamp Received (seconds) >00 00 00 00 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > >00 00 > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > > > > >> b) What is the value of the smac3 in the TLV. Is it mandatory ?. >> Should the reply take the path using the smac3 for lookup >> (for reply mode 5)? Pseudo Wire Connectivity verification ?. > >This is the MAC to which the reply should be sent. It is included to >support implementations where the processing is distributed in >case the MAC >header is not passed along with the IP packet. > >Here is an internal debug dump of a reply to a similar VPLS >ping about to be >sent... > > >00 01 30 08 92 00 Next Hop Router MAC >00 01 30 05 84 00 Local (originating) Router MAC > > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 30 ff VC Label >00 00 e1 ff OAM Label > >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender >Ethernet MAC from >request) >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target >Ethernet MAC from >request) >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 78 Length >00 93 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 59 Header Checksum >0b 64 64 08 Src IP >7f 00 00 1c Dst IP > >0d af UDP Src Port = 3503 >95 80 UDP Dst Port = 38272 >00 64 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >02 Message Type = MPLS Echo Reply >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 05 00 01 Sender's Handle >00 00 00 1b Sequence Number >3f a7 62 be Timestamp Sent (seconds) >00 06 8f b0 Timestamp Sent (microseconds) >3f a7 56 45 Timestamp Received (seconds) >00 04 ba f0 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC >00 00 > >00 04 Type = Error Code >00 08 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 04 Length >00 01 Error Code = Replying router is the Egress >for the MAC >00 00 Must Be Zero > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > >In this example, when the reply is received at the originating >PE, the OAM label causes the packet to be processed at the PE and not >forwarded to the customer. Could you please explain/elaborate on how the TTL is treated in the aforementioned packets? Your packet dump does not show this. Specifically, what happens to the header + TTL as the packet traverses the MPLS network between the VPLS bridges as described in section 8.2.2 of your draft. >> c) Is there any relation between smac2 and smac3 ?. >> > >Normally they would be the same. > > > >> d) We have assumed that the dmac2 is either the mac of the >> target MTU/PE. This is because if the customer dmac is >> used the packet would show up at the customer. If the >> router alert is used the the packet would not go beyond >> the PE. So is this assumption correct ?. > >You need the OAM label to prevent the packet from reaching >customer devices. It should be pointed out that this extra label also adds the potential for the OAM packets being forwarded along ECMP paths that differ from those of the original data packets. I think you are making the assumption that the VC label is the only one used for load-share computation. This seems like a serious deficiency to me as it can result in false results. --Tom >Remember that if dmac2 is not known in the network, the packet may be >flooded. It would then reach PEs other than the one >associated with dmac2. >The OAM label allows these switches to prevent the traffic reaching a >customer. > > > >> >> e) pre-condition: >> To do a VPLS ping to verify customer MAC sitting at >> the remote end, we have to have a actual customer >> traffic flowing on >> the pseudo-wire, or at least some customer traffic has >> to be there >> within the 'L2 age out' time period. >> For VPLS ping to work, this is a pre-condition. >> >> Question is 'Is this a valid pre-condition ?', If yes, are users >> OK with this model of OAM ?. >> > >As stated above, if the MAC is unknown, the packet is to be >flooded as would >any normal packet. Therefore, the intent that this >pre-condition should not >be necessary. > > > >> >> thanks >> hongal >> > From exim@www1.ietf.org Tue Nov 4 12:58:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25255 for ; Tue, 4 Nov 2003 12:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5RM-0006ri-T0 for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 12:58:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4Hw4qE026384 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 12:58:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5RL-0006rL-AB for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 12:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25240 for ; Tue, 4 Nov 2003 12:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5RJ-0001n8-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 12:58:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH5RJ-0001n5-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 12:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5RJ-0006qi-26; Tue, 04 Nov 2003 12:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH5QO-0006pa-PD for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 12:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25229 for ; Tue, 4 Nov 2003 12:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH5QM-0001mb-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 12:57:02 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1AH5QM-0001mT-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 12:57:02 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 Nov 2003 09:56:27 -0800 Reply-To: From: "Vach Kompella" To: , "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 09:54:29 -0800 Organization: Alcatel USA Message-ID: <00d401c3a2fc$b34a38b0$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <00e501c3a2f2$140f53c0$3aa5560a@amer.cisco.com> X-OriginalArrivalTime: 04 Nov 2003 17:56:27.0236 (UTC) FILETIME=[F7FA9A40:01C3A2FC] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Tom, > >You need the OAM label to prevent the packet from reaching=20 > >customer devices. >=20 > It should be pointed out that this extra label also adds the=20 > potential for the OAM packets being forwarded along ECMP paths that=20 > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious=20 > deficiency to me as it can result in false results. >=20 > --Tom Two points: First regarding trying to do ECMP: So, suppose you wanted to do OAM somewhere in the middle of the network. The LSR looks at the top label. It understands that. It looks at the next label. It's bottom-of-stack. It looks at the next nibble - not 4x. Do you assume it is an Ethernet packet? Do you have a clue what kind of PW it is to make any assumptions about the usable fields for ECMP? Second, regarding ECMP: If the MAC learning was correctly executed, at ingress, the PW chosen to forward will still be the right one, the outgoing interface to the customer will still the right one, unless for some reason the dest MAC was learned against the wrong VPLS peer, on the wrong PW. In that case, you can correctly report the error. In other words, at the VPLS level, the ping/traceroute follows the PWs of the VPLS properly. -Vach=20 From exim@www1.ietf.org Tue Nov 4 14:16:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28869 for ; Tue, 4 Nov 2003 14:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6er-00058L-MT for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 14:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JG51w019727 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 14:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6er-000586-H4 for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:16:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28861 for ; Tue, 4 Nov 2003 14:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6ep-0003BQ-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:16:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6eo-0003BN-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6ep-00056R-FD; Tue, 04 Nov 2003 14:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6eQ-00055F-2M for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 14:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28834 for ; Tue, 4 Nov 2003 14:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6eN-0003Al-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:15:35 -0500 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1AH6eM-00038L-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:15:34 -0500 Received: from hongal-d2k.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA29109; Tue, 4 Nov 2003 11:13:56 -0800 (PST) Message-Id: <5.1.0.14.0.20031104105147.00ac7440@manet> X-Sender: hongal@manet X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Nov 2003 11:13:54 -0800 To: Olen Stokes , Olen Stokes , marc.lasserre@riverstonenet.com, l2vpn@ietf.org From: Thippanna Hongal Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Cc: pishwar@riverstonenet.com In-Reply-To: <3DC3910A44FBD94B8513C8E2A3F220E123FD8A@sc-msexch-16.extrem enetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Thanks for the reply but we have some additional questions. 1) From the draft we understand that the vpls ping can originate either at the mtu or the PE. And terminate at the PE or MTU depending on whether the customer is connected at the MTU or PE. From the reply below > >>You need the OAM label to prevent the packet from reaching customer > devices. > >>.Remember that if dmac2 is not known in the network, the packet may be > >>flooded. It would then reach PEs other than the one associated with dmac2. > >>The OAM label allows these switches to prevent the traffic reaching a > >>customer. We understand that the OAM label terminates at the PE always. So does it mean that Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine the packet (TLVs) and decide to either forward/ flood to the MTUs Case B) No MTUS connected but directly connected to customers the PE must reply back directly using the smac address? 2) In case 1A we believe that the PE must add OAM Label in addition to any PW label needed to send to the MTU/ Similarly when the MTU replies/requests a ping it also must add an OAM label which terminates at the PE. 3) Regarding the QAM label could you point us to the draft where the OAM label At 08:03 AM 11/4/2003 -0800, Olen Stokes wrote: >Please see in line.... > > > > > -----Original Message----- > > From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > > Sent: Friday, October 31, 2003 6:08 PM > > To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > > l2vpn@ietf.org > > Cc: pishwar@riverstonenet.com > > Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > > > hi Stokes, > > > > Below is the packet format on the wire as we understand from > > the draft. > > We have a few questins on this. > > > > Packet for the PING > > > > dmac1 (Next hop router) > > smac1 (Of the originating router) > > Etype - 8847 > > Transport label -|__________________ Pseudo wire > > Vc label ------| > > dmac2 (of the target mtu/pe to which the ping is targeted) > > smac2 (of the originating router (PE/MTU)) > > etype (IP 0x800) > > ... > > Mac TLV > > smac3 -- (??) > > dmac3 -- (customer's mac/spoke's mac to be pinged). > > > > a) Is the above representation correct? > > >Here is an internal debug dump of a VPLS ping about to be sent... > > >00 01 30 05 84 00 Next Hop Router MAC >00 01 30 08 92 00 Local (originating) Router MAC > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 40 ff VC Label >00 00 e1 ff OAM Label > >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged >00 01 02 03 04 05 Local Customer MAC >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 6c Length >00 80 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 31 Header Checksum >0b 64 64 09 Src IP >7f 00 00 62 Dst IP > >95 80 UDP Src Port = 38272 >0d af UDP Dst Port = 3503 >00 58 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >01 Message Type = MPLS Echo Request >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 04 00 01 Sender's Handle >00 00 00 61 Sequence Number >3f a7 5e 0c Timestamp Sent (seconds) >00 04 ba f0 Timestamp Sent (microseconds) >00 00 00 00 Timestamp Received (seconds) >00 00 00 00 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > >00 00 > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > > > > > > b) What is the value of the smac3 in the TLV. Is it mandatory ?. > > Should the reply take the path using the smac3 for lookup > > (for reply mode 5)? Pseudo Wire Connectivity verification ?. > >This is the MAC to which the reply should be sent. It is included to >support implementations where the processing is distributed in case the MAC >header is not passed along with the IP packet. > >Here is an internal debug dump of a reply to a similar VPLS ping about to be >sent... > > >00 01 30 08 92 00 Next Hop Router MAC >00 01 30 05 84 00 Local (originating) Router MAC > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 30 ff VC Label >00 00 e1 ff OAM Label > >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender Ethernet MAC from >request) >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target Ethernet MAC from >request) >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 78 Length >00 93 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 59 Header Checksum >0b 64 64 08 Src IP >7f 00 00 1c Dst IP > >0d af UDP Src Port = 3503 >95 80 UDP Dst Port = 38272 >00 64 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >02 Message Type = MPLS Echo Reply >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 05 00 01 Sender's Handle >00 00 00 1b Sequence Number >3f a7 62 be Timestamp Sent (seconds) >00 06 8f b0 Timestamp Sent (microseconds) >3f a7 56 45 Timestamp Received (seconds) >00 04 ba f0 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC >00 00 > >00 04 Type = Error Code >00 08 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 04 Length >00 01 Error Code = Replying router is the Egress for the MAC >00 00 Must Be Zero > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > >In this example, when the reply is received at the originating PE, the OAM >label causes the packet to be processed at the PE and not forwarded to the >customer. > > > > > > c) Is there any relation between smac2 and smac3 ?. > > > >Normally they would be the same. > > > > > d) We have assumed that the dmac2 is either the mac of the > > target MTU/PE. This is because if the customer dmac is > > used the packet would show up at the customer. If the > > router alert is used the the packet would not go beyond > > the PE. So is this assumption correct ?. > >You need the OAM label to prevent the packet from reaching customer devices. >Remember that if dmac2 is not known in the network, the packet may be >flooded. It would then reach PEs other than the one associated with dmac2. >The OAM label allows these switches to prevent the traffic reaching a >customer. > > > > > > > e) pre-condition: > > To do a VPLS ping to verify customer MAC sitting at > > the remote end, we have to have a actual customer > > traffic flowing on > > the pseudo-wire, or at least some customer traffic has > > to be there > > within the 'L2 age out' time period. > > For VPLS ping to work, this is a pre-condition. > > > > Question is 'Is this a valid pre-condition ?', If yes, are users > > OK with this model of OAM ?. > > > >As stated above, if the MAC is unknown, the packet is to be flooded as would >any normal packet. Therefore, the intent that this pre-condition should not >be necessary. > > > > > > > thanks > > hongal > > From exim@www1.ietf.org Tue Nov 4 14:23:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29347 for ; Tue, 4 Nov 2003 14:23:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6la-0006OF-MP for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 14:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JN2su024557 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 14:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6la-0006O0-Hp for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29290 for ; Tue, 4 Nov 2003 14:22:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6lX-0003LS-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6lX-0003LP-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6lZ-0006Md-3w; Tue, 04 Nov 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6l2-0006Ky-7v for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 14:22:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29268 for ; Tue, 4 Nov 2003 14:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6kz-0003Kn-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:22:25 -0500 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1AH6ky-0003K4-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:22:24 -0500 Received: from hongal-d2k.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA00014; Tue, 4 Nov 2003 11:21:52 -0800 (PST) Message-Id: <5.1.0.14.0.20031104111549.01ea7d90@manet> X-Sender: hongal@manet X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Nov 2003 11:21:51 -0800 To: l2vpn@ietf.org, Olen Stokes , pishwar@riverstonenet.com From: Thippanna Hongal Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , hi Olen, Thanks for the reply, we have some more questions. 1) From the draft we understand that the vpls ping can originate either at the MTU or PE. And terminate at the PE or MTU depending on whether the customer is connected at the MTU or PE. From the reply below >>You need the OAM label to prevent the packet from reaching customer devices. >>.Remember that if dmac2 is not known in the network, the packet may be >>flooded. It would then reach PEs other than the one associated with dmac2. >>The OAM label allows these switches to prevent the traffic reaching a >>customer. We understand that the OAM label terminates at the PE always. So does it mean that Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine the packet (TLVs) and decide to either forward/ flood to the MTUs Case B) No MTUS connected but directly connected to customers the PE must reply back directly using the smac address? 2) In case A we believe that the PE must add OAM Label in addition to any PW label needed to send to the MTU/ Similarly when the MTU replies/requests a ping it also must add an OAM label which makes this OAM frame terminate at the PE. 3) Regarding the QAM label could you point us to the draft where the OAM label is defined for VPLS Ping. Regards hongal From exim@www1.ietf.org Tue Nov 4 14:35:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29960 for ; Tue, 4 Nov 2003 14:35:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6xE-0007Hd-3w for l2vpn-archive@odin.ietf.org; Tue, 04 Nov 2003 14:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JZ4Oc027991 for l2vpn-archive@odin.ietf.org; Tue, 4 Nov 2003 14:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6xD-0007HN-TS for l2vpn-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 14:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29927 for ; Tue, 4 Nov 2003 14:34:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6xB-0003Zi-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:35:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH6xB-0003Zf-00 for l2vpn-web-archive@ietf.org; Tue, 04 Nov 2003 14:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6xC-0007Gj-2t; Tue, 04 Nov 2003 14:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6wQ-0007Cw-VQ for l2vpn@optimus.ietf.org; Tue, 04 Nov 2003 14:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29889 for ; Tue, 4 Nov 2003 14:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6wO-0003Yv-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:34:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AH6wN-0003YE-00 for l2vpn@ietf.org; Tue, 04 Nov 2003 14:34:11 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2003 11:35:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA4JXZDO018907; Tue, 4 Nov 2003 14:33:38 -0500 (EST) Received: from tnadeauw2k02 (dhcp-10-86-165-58.cisco.com [10.86.165.58]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS26788; Tue, 4 Nov 2003 14:33:35 -0500 (EST) Reply-To: From: "Thomas D. Nadeau" To: , "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 14:33:35 -0500 Organization: Cisco Systems, inc. Message-ID: <016c01c3a30a$8a04b2b0$3aa5560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <00d401c3a2fc$b34a38b0$0101010a@eng.timetra.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Vach Kompella [mailto:vach.kompella@alcatel.com] >Sent: Tuesday, November 04, 2003 12:54 PM >To: tnadeau@cisco.com; 'Olen Stokes'; 'Thippanna Hongal'; >marc.lasserre@riverstonenet.com; l2vpn@ietf.org >Cc: pishwar@riverstonenet.com >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > >Tom, > >> >You need the OAM label to prevent the packet from reaching >> >customer devices. >> >> It should be pointed out that this extra label also adds the >> potential for the OAM packets being forwarded along ECMP paths that >> differ from those of the original data packets. I think you >> are making the assumption that the VC label is the only one >> used for load-share computation. This seems like a serious >> deficiency to me as it can result in false results. >> >> --Tom > >Two points: > >First regarding trying to do ECMP: >So, suppose you wanted to do OAM somewhere in the middle of >the network. >The LSR looks at the top label. It understands that. It looks at the >next label. It's bottom-of-stack. It looks at the next nibble - not >4x. Do you assume it is an Ethernet packet? Do you have a clue what >kind of PW it is to make any assumptions about the usable fields for >ECMP? I am not understanding your point about wanting to do "OAM in the middle of the network". If you want to test the PWs that the VPLS is using, you can do that very easily using the same label stack that the PW uses (see VCCV and LSP ping). If you want to test any other labels/tunnels in the core, you use LSP ping. These all work fine whether or not ECMP is in use, or whether there is an ENET packet contained in the PW (or whatever). >Second, regarding ECMP: >If the MAC learning was correctly executed, at ingress, the PW >chosen to >forward will still be the right one, the outgoing interface to the >customer will still the right one, unless for some reason the dest MAC >was learned against the wrong VPLS peer, on the wrong PW. In >that case, you can correctly report the error. In other words, at the VPLS level, >the ping/traceroute follows the PWs of the VPLS properly. Not necessarily. The lesson to be learned from the work done over the past year or so on LSP ping is that you should not count on any specific ECMP behavior within the core; just that it might happen and if and when it does, you need to handle it. Thus, even if your PE happens to choose the right outgoing label at the ingress PE, it is very possible that a core LSR may still choose a different path in the core if it hashes on the entire label stack. This happens of course because another label (for OAM) has been inserted into the label stack. Also, there was no reply to my TTL/forwarding question. --Tom >-Vach > > From exim@www1.ietf.org Wed Nov 5 09:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07207 for ; Wed, 5 Nov 2003 09:51:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP04-0005nN-Nk for l2vpn-archive@odin.ietf.org; Wed, 05 Nov 2003 09:51:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5EpCSn022271 for l2vpn-archive@odin.ietf.org; Wed, 5 Nov 2003 09:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP04-0005n8-Ix for l2vpn-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07179 for ; Wed, 5 Nov 2003 09:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHP02-0005E4-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 09:51:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHP02-0005E1-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 09:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOzu-0005mX-Eq; Wed, 05 Nov 2003 09:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOzV-0005lt-3g for l2vpn@optimus.ietf.org; Wed, 05 Nov 2003 09:50:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07146 for ; Wed, 5 Nov 2003 09:50:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOzT-0005DD-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 09:50:35 -0500 Received: from sc-f100-01.extremenetworks.com ([63.251.106.30] helo=extrgate1.extremenetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AHOzS-0005Cs-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 09:50:34 -0500 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Nov 2003 06:49:42 -0800 Message-ID: <3DC3910A44FBD94B8513C8E2A3F220E123FD90@sc-msexch-16.extremenetworks.com> From: Olen Stokes To: "'tnadeau@cisco.com'" , Olen Stokes , "'Thippanna Hongal'" , marc.lasserre@riverstonenet.com, l2vpn@ietf.org Cc: pishwar@riverstonenet.com Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Wed, 5 Nov 2003 06:50:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Question copied from below.... > Could you please explain/elaborate on how the TTL is > treated in the aforementioned packets? Your packet dump does > not show this. Specifically, what happens to the header + TTL > as the packet traverses the MPLS network between the VPLS bridges > as described in section 8.2.2 of your draft. I apologize, but Section 8.2.2 is the best way that I know how to describe the handling of the TTL in the VC FEC label. Can you give me a specific scenario that is not covered in the draft? In case anyone is not aware, the draft describes a method for handling the TTL in the VC FEC label. For example, consider a packet from a spoke node received at a core node. The TTL in the received VC FEC label is decremented and the result placed in the TTL of the outgoing VC FEC label. Comment copied from below.... > It should be pointed out that this extra label also adds the > potential for the OAM packets being forwarded along ECMP paths that > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious > deficiency to me as it can result in false results. This is already discussed in Sections 8.1.4 and in Section 11 of the draft. There has been no attempt to hide this issue. If you have any suggestions for wording to make this clearer, I would be happy to take a look. Cheers, Olen > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, November 04, 2003 11:38 AM > To: 'Olen Stokes'; 'Thippanna Hongal'; > marc.lasserre@riverstonenet.com; > l2vpn@ietf.org > Cc: pishwar@riverstonenet.com > Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > One question and one comment below. > > >-----Original Message----- > >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > >Behalf Of Olen Stokes > >Sent: Tuesday, November 04, 2003 11:04 AM > >To: 'Thippanna Hongal'; Olen Stokes; > >marc.lasserre@riverstonenet.com; l2vpn@ietf.org > >Cc: pishwar@riverstonenet.com > >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > > > > >Please see in line.... > > > > > > > >> -----Original Message----- > >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > >> Sent: Friday, October 31, 2003 6:08 PM > >> To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > >> l2vpn@ietf.org > >> Cc: pishwar@riverstonenet.com > >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > >> > >> > >> hi Stokes, > >> > >> Below is the packet format on the wire as we understand from > >> the draft. > >> We have a few questins on this. > >> > >> Packet for the PING > >> > >> dmac1 (Next hop router) > >> smac1 (Of the originating router) > >> Etype - 8847 > >> Transport label -|__________________ Pseudo wire > >> Vc label ------| > >> dmac2 (of the target mtu/pe to which the ping is targeted) > >> smac2 (of the originating router (PE/MTU)) > >> etype (IP 0x800) > >> ... > >> Mac TLV > >> smac3 -- (??) > >> dmac3 -- (customer's mac/spoke's mac to be pinged). > >> > >> a) Is the above representation correct? > >> > >Here is an internal debug dump of a VPLS ping about to be sent... > > > > > >00 01 30 05 84 00 Next Hop Router MAC > >00 01 30 08 92 00 Local (originating) Router MAC > > > >88 47 Ethertype = MPLS > >cb 00 10 ff Tunnel Label > >8c 00 40 ff VC Label > >00 00 e1 ff OAM Label > > > >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged > >00 01 02 03 04 05 Local Customer MAC > >08 00 Ethertype = IP > > > >45 IPv4 > >00 TOS > >00 6c Length > >00 80 ID > >00 00 Offset > >ff TTL > >11 protocol = UDP > >cc 31 Header Checksum > >0b 64 64 09 Src IP > >7f 00 00 62 Dst IP > > > >95 80 UDP Src Port = 38272 > >0d af UDP Dst Port = 3503 > >00 58 UDP Length > >00 00 UDP Checksum > > > >00 01 LSP Ping Version Number = 1 > >00 00 Must Be Zero > >01 Message Type = MPLS Echo Request > >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >00 Return Code > >00 Return Subcode > >00 04 00 01 Sender's Handle > >00 00 00 61 Sequence Number > >3f a7 5e 0c Timestamp Sent (seconds) > >00 04 ba f0 Timestamp Sent (microseconds) > >00 00 00 00 Timestamp Received (seconds) > >00 00 00 00 Timestamp Received (microseconds) > > > >00 01 Type = Target FEC Stack > >00 20 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 1c Length > >00 00 07 d0 VC ID > >00 05 Encapsulation Type = Ethernet > >00 00 Must Be Zero > >00 05 L2 Specific Sub-Type = Ethernet > >00 10 Length > >00 01 30 05 84 00 Target Ethernet MAC > >00 00 > >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > > > >00 00 > > > >00 03 Type = Pad > >00 08 Length > >02 Copy Pad TLV to Reply > >44 45 41 44 Pad Data > >42 45 45 > > > > > > > > > >> b) What is the value of the smac3 in the TLV. Is it mandatory ?. > >> Should the reply take the path using the smac3 for lookup > >> (for reply mode 5)? Pseudo Wire Connectivity verification ?. > > > >This is the MAC to which the reply should be sent. It is included to > >support implementations where the processing is distributed in > >case the MAC > >header is not passed along with the IP packet. > > > >Here is an internal debug dump of a reply to a similar VPLS > >ping about to be > >sent... > > > > > >00 01 30 08 92 00 Next Hop Router MAC > >00 01 30 05 84 00 Local (originating) Router MAC > > > > > >88 47 Ethertype = MPLS > >cb 00 10 ff Tunnel Label > >8c 00 30 ff VC Label > >00 00 e1 ff OAM Label > > > >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender > >Ethernet MAC from > >request) > >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target > >Ethernet MAC from > >request) > >08 00 Ethertype = IP > > > >45 IPv4 > >00 TOS > >00 78 Length > >00 93 ID > >00 00 Offset > >ff TTL > >11 protocol = UDP > >cc 59 Header Checksum > >0b 64 64 08 Src IP > >7f 00 00 1c Dst IP > > > >0d af UDP Src Port = 3503 > >95 80 UDP Dst Port = 38272 > >00 64 UDP Length > >00 00 UDP Checksum > > > >00 01 LSP Ping Version Number = 1 > >00 00 Must Be Zero > >02 Message Type = MPLS Echo Reply > >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >00 Return Code > >00 Return Subcode > >00 05 00 01 Sender's Handle > >00 00 00 1b Sequence Number > >3f a7 62 be Timestamp Sent (seconds) > >00 06 8f b0 Timestamp Sent (microseconds) > >3f a7 56 45 Timestamp Received (seconds) > >00 04 ba f0 Timestamp Received (microseconds) > > > >00 01 Type = Target FEC Stack > >00 20 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 1c Length > >00 00 07 d0 VC ID > >00 05 Encapsulation Type = Ethernet > >00 00 Must Be Zero > >00 05 L2 Specific Sub-Type = Ethernet > >00 10 Length > >00 01 30 05 84 00 Target Ethernet MAC > >00 00 > >00 01 02 03 04 05 Sender Ethernet MAC > >00 00 > > > >00 04 Type = Error Code > >00 08 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 04 Length > >00 01 Error Code = Replying router is the Egress > >for the MAC > >00 00 Must Be Zero > > > >00 03 Type = Pad > >00 08 Length > >02 Copy Pad TLV to Reply > >44 45 41 44 Pad Data > >42 45 45 > > > >In this example, when the reply is received at the originating > >PE, the OAM label causes the packet to be processed at the > PE and not > >forwarded to the customer. > > Could you please explain/elaborate on how the TTL is > treated in the aforementioned packets? Your packet dump does > not show this. Specifically, what happens to the header + TTL > as the packet traverses the MPLS network between the VPLS bridges > as described in section 8.2.2 of your draft. > > >> c) Is there any relation between smac2 and smac3 ?. > >> > > > >Normally they would be the same. > > > > > > > >> d) We have assumed that the dmac2 is either the mac of the > >> target MTU/PE. This is because if the customer dmac is > >> used the packet would show up at the customer. If the > >> router alert is used the the packet would not go beyond > >> the PE. So is this assumption correct ?. > > > >You need the OAM label to prevent the packet from reaching > >customer devices. > > It should be pointed out that this extra label also adds the > potential for the OAM packets being forwarded along ECMP paths that > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious > deficiency to me as it can result in false results. > > --Tom > > > > >Remember that if dmac2 is not known in the network, the packet may be > >flooded. It would then reach PEs other than the one > >associated with dmac2. > >The OAM label allows these switches to prevent the traffic reaching a > >customer. > > > > > > > >> > >> e) pre-condition: > >> To do a VPLS ping to verify customer MAC sitting at > >> the remote end, we have to have a actual customer > >> traffic flowing on > >> the pseudo-wire, or at least some customer traffic has > >> to be there > >> within the 'L2 age out' time period. > >> For VPLS ping to work, this is a pre-condition. > >> > >> Question is 'Is this a valid pre-condition ?', If > yes, are users > >> OK with this model of OAM ?. > >> > > > >As stated above, if the MAC is unknown, the packet is to be > >flooded as would > >any normal packet. Therefore, the intent that this > >pre-condition should not > >be necessary. > > > > > > > >> > >> thanks > >> hongal > >> > > > From exim@www1.ietf.org Wed Nov 5 09:56:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07445 for ; Wed, 5 Nov 2003 09:56:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP4l-00063D-1p for l2vpn-archive@odin.ietf.org; Wed, 05 Nov 2003 09:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Eu301023253 for l2vpn-archive@odin.ietf.org; Wed, 5 Nov 2003 09:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP4k-00062y-TN for l2vpn-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:56:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07438 for ; Wed, 5 Nov 2003 09:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHP4i-0005IY-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 09:56:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHP4i-0005IV-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 09:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP4j-00061M-I2; Wed, 05 Nov 2003 09:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHP4S-00060K-S1 for l2vpn@optimus.ietf.org; Wed, 05 Nov 2003 09:55:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07413 for ; Wed, 5 Nov 2003 09:55:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHP4Q-0005Hy-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 09:55:42 -0500 Received: from mail.congdoanvn.org.vn ([203.113.131.34] helo=vietel.com.vn) by ietf-mx with esmtp (Exim 4.12) id 1AHP4O-0005Ha-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 09:55:41 -0500 Received: from [203.210.134.31] (account thinhtx HELO txthinh) by vietel.com.vn (CommuniGate Pro SMTP 3.5.9) with ESMTP id 254699 for l2vpn@ietf.org; Wed, 05 Nov 2003 21:36:30 +0700 Reply-To: From: "Tran Thinh" To: Subject: RE: L2vpn digest, Vol 1 #85 - 5 msgs Date: Wed, 5 Nov 2003 21:54:42 +0700 Organization: Viettel Internet Message-ID: <002f01c3a3ac$c2ecb120$2001a8c0@vietel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal In-Reply-To: <20031105145102.22206.91601.Mailman@www1.ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of l2vpn-request@ietf.org Sent: Wednesday, November 05, 2003 9:51 PM To: l2vpn@ietf.org Subject: L2vpn digest, Vol 1 #85 - 5 msgs Send L2vpn mailing list submissions to l2vpn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/l2vpn or, via email, send a message with subject or body 'help' to l2vpn-request@ietf.org You can reach the person managing the list at l2vpn-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..." Today's Topics: 1. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Vach Kompella) 2. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thippanna Hongal) 3. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thippanna Hongal) 4. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Thomas D. Nadeau) 5. RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt (Olen Stokes) --__--__-- Message: 1 Reply-To: From: "Vach Kompella" To: , "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 09:54:29 -0800 Organization: Alcatel USA Tom, > >You need the OAM label to prevent the packet from reaching=20 > >customer devices. >=20 > It should be pointed out that this extra label also adds the=20 > potential for the OAM packets being forwarded along ECMP paths that=20 > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious=20 > deficiency to me as it can result in false results. >=20 > --Tom Two points: First regarding trying to do ECMP: So, suppose you wanted to do OAM somewhere in the middle of the network. The LSR looks at the top label. It understands that. It looks at the next label. It's bottom-of-stack. It looks at the next nibble - not 4x. Do you assume it is an Ethernet packet? Do you have a clue what kind of PW it is to make any assumptions about the usable fields for ECMP? Second, regarding ECMP: If the MAC learning was correctly executed, at ingress, the PW chosen to forward will still be the right one, the outgoing interface to the customer will still the right one, unless for some reason the dest MAC was learned against the wrong VPLS peer, on the wrong PW. In that case, you can correctly report the error. In other words, at the VPLS level, the ping/traceroute follows the PWs of the VPLS properly. -Vach=20 --__--__-- Message: 2 Date: Tue, 04 Nov 2003 11:13:54 -0800 To: Olen Stokes , Olen Stokes , marc.lasserre@riverstonenet.com, l2vpn@ietf.org From: Thippanna Hongal Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Cc: pishwar@riverstonenet.com Thanks for the reply but we have some additional questions. 1) From the draft we understand that the vpls ping can originate either at the mtu or the PE. And terminate at the PE or MTU depending on whether the customer is connected at the MTU or PE. From the reply below > >>You need the OAM label to prevent the packet from reaching customer > devices. > >>.Remember that if dmac2 is not known in the network, the packet may be > >>flooded. It would then reach PEs other than the one associated with dmac2. > >>The OAM label allows these switches to prevent the traffic reaching a > >>customer. We understand that the OAM label terminates at the PE always. So does it mean that Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine the packet (TLVs) and decide to either forward/ flood to the MTUs Case B) No MTUS connected but directly connected to customers the PE must reply back directly using the smac address? 2) In case 1A we believe that the PE must add OAM Label in addition to any PW label needed to send to the MTU/ Similarly when the MTU replies/requests a ping it also must add an OAM label which terminates at the PE. 3) Regarding the QAM label could you point us to the draft where the OAM label At 08:03 AM 11/4/2003 -0800, Olen Stokes wrote: >Please see in line.... > > > > > -----Original Message----- > > From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > > Sent: Friday, October 31, 2003 6:08 PM > > To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > > l2vpn@ietf.org > > Cc: pishwar@riverstonenet.com > > Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > > > hi Stokes, > > > > Below is the packet format on the wire as we understand from > > the draft. > > We have a few questins on this. > > > > Packet for the PING > > > > dmac1 (Next hop router) > > smac1 (Of the originating router) > > Etype - 8847 > > Transport label -|__________________ Pseudo wire > > Vc label ------| > > dmac2 (of the target mtu/pe to which the ping is targeted) > > smac2 (of the originating router (PE/MTU)) > > etype (IP 0x800) > > ... > > Mac TLV > > smac3 -- (??) > > dmac3 -- (customer's mac/spoke's mac to be pinged). > > > > a) Is the above representation correct? > > >Here is an internal debug dump of a VPLS ping about to be sent... > > >00 01 30 05 84 00 Next Hop Router MAC >00 01 30 08 92 00 Local (originating) Router MAC > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 40 ff VC Label >00 00 e1 ff OAM Label > >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged >00 01 02 03 04 05 Local Customer MAC >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 6c Length >00 80 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 31 Header Checksum >0b 64 64 09 Src IP >7f 00 00 62 Dst IP > >95 80 UDP Src Port = 38272 >0d af UDP Dst Port = 3503 >00 58 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >01 Message Type = MPLS Echo Request >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 04 00 01 Sender's Handle >00 00 00 61 Sequence Number >3f a7 5e 0c Timestamp Sent (seconds) >00 04 ba f0 Timestamp Sent (microseconds) >00 00 00 00 Timestamp Received (seconds) >00 00 00 00 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > >00 00 > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > > > > > > b) What is the value of the smac3 in the TLV. Is it mandatory ?. > > Should the reply take the path using the smac3 for lookup > > (for reply mode 5)? Pseudo Wire Connectivity verification ?. > >This is the MAC to which the reply should be sent. It is included to >support implementations where the processing is distributed in case the MAC >header is not passed along with the IP packet. > >Here is an internal debug dump of a reply to a similar VPLS ping about to be >sent... > > >00 01 30 08 92 00 Next Hop Router MAC >00 01 30 05 84 00 Local (originating) Router MAC > >88 47 Ethertype = MPLS >cb 00 10 ff Tunnel Label >8c 00 30 ff VC Label >00 00 e1 ff OAM Label > >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender Ethernet MAC from >request) >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target Ethernet MAC from >request) >08 00 Ethertype = IP > >45 IPv4 >00 TOS >00 78 Length >00 93 ID >00 00 Offset >ff TTL >11 protocol = UDP >cc 59 Header Checksum >0b 64 64 08 Src IP >7f 00 00 1c Dst IP > >0d af UDP Src Port = 3503 >95 80 UDP Dst Port = 38272 >00 64 UDP Length >00 00 UDP Checksum > >00 01 LSP Ping Version Number = 1 >00 00 Must Be Zero >02 Message Type = MPLS Echo Reply >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >00 Return Code >00 Return Subcode >00 05 00 01 Sender's Handle >00 00 00 1b Sequence Number >3f a7 62 be Timestamp Sent (seconds) >00 06 8f b0 Timestamp Sent (microseconds) >3f a7 56 45 Timestamp Received (seconds) >00 04 ba f0 Timestamp Received (microseconds) > >00 01 Type = Target FEC Stack >00 20 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 1c Length >00 00 07 d0 VC ID >00 05 Encapsulation Type = Ethernet >00 00 Must Be Zero >00 05 L2 Specific Sub-Type = Ethernet >00 10 Length >00 01 30 05 84 00 Target Ethernet MAC >00 00 >00 01 02 03 04 05 Sender Ethernet MAC >00 00 > >00 04 Type = Error Code >00 08 Length >00 0a Sub-Type = Hierarchical L2 Circuit ID >00 04 Length >00 01 Error Code = Replying router is the Egress for the MAC >00 00 Must Be Zero > >00 03 Type = Pad >00 08 Length >02 Copy Pad TLV to Reply >44 45 41 44 Pad Data >42 45 45 > >In this example, when the reply is received at the originating PE, the OAM >label causes the packet to be processed at the PE and not forwarded to the >customer. > > > > > > c) Is there any relation between smac2 and smac3 ?. > > > >Normally they would be the same. > > > > > d) We have assumed that the dmac2 is either the mac of the > > target MTU/PE. This is because if the customer dmac is > > used the packet would show up at the customer. If the > > router alert is used the the packet would not go beyond > > the PE. So is this assumption correct ?. > >You need the OAM label to prevent the packet from reaching customer devices. >Remember that if dmac2 is not known in the network, the packet may be >flooded. It would then reach PEs other than the one associated with dmac2. >The OAM label allows these switches to prevent the traffic reaching a >customer. > > > > > > > e) pre-condition: > > To do a VPLS ping to verify customer MAC sitting at > > the remote end, we have to have a actual customer > > traffic flowing on > > the pseudo-wire, or at least some customer traffic has > > to be there > > within the 'L2 age out' time period. > > For VPLS ping to work, this is a pre-condition. > > > > Question is 'Is this a valid pre-condition ?', If yes, are users > > OK with this model of OAM ?. > > > >As stated above, if the MAC is unknown, the packet is to be flooded as would >any normal packet. Therefore, the intent that this pre-condition should not >be necessary. > > > > > > > thanks > > hongal > > --__--__-- Message: 3 Date: Tue, 04 Nov 2003 11:21:51 -0800 To: l2vpn@ietf.org, Olen Stokes , pishwar@riverstonenet.com From: Thippanna Hongal Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt hi Olen, Thanks for the reply, we have some more questions. 1) From the draft we understand that the vpls ping can originate either at the MTU or PE. And terminate at the PE or MTU depending on whether the customer is connected at the MTU or PE. From the reply below >>You need the OAM label to prevent the packet from reaching customer devices. >>.Remember that if dmac2 is not known in the network, the packet may be >>flooded. It would then reach PEs other than the one associated with dmac2. >>The OAM label allows these switches to prevent the traffic reaching a >>customer. We understand that the OAM label terminates at the PE always. So does it mean that Case A) (HVPLS) MTUs being connected to the PE, the PE has to examine the packet (TLVs) and decide to either forward/ flood to the MTUs Case B) No MTUS connected but directly connected to customers the PE must reply back directly using the smac address? 2) In case A we believe that the PE must add OAM Label in addition to any PW label needed to send to the MTU/ Similarly when the MTU replies/requests a ping it also must add an OAM label which makes this OAM frame terminate at the PE. 3) Regarding the QAM label could you point us to the draft where the OAM label is defined for VPLS Ping. Regards hongal --__--__-- Message: 4 Reply-To: From: "Thomas D. Nadeau" To: , "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 4 Nov 2003 14:33:35 -0500 Organization: Cisco Systems, inc. >-----Original Message----- >From: Vach Kompella [mailto:vach.kompella@alcatel.com] >Sent: Tuesday, November 04, 2003 12:54 PM >To: tnadeau@cisco.com; 'Olen Stokes'; 'Thippanna Hongal'; >marc.lasserre@riverstonenet.com; l2vpn@ietf.org >Cc: pishwar@riverstonenet.com >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > >Tom, > >> >You need the OAM label to prevent the packet from reaching >> >customer devices. >> >> It should be pointed out that this extra label also adds the >> potential for the OAM packets being forwarded along ECMP paths that >> differ from those of the original data packets. I think you >> are making the assumption that the VC label is the only one >> used for load-share computation. This seems like a serious >> deficiency to me as it can result in false results. >> >> --Tom > >Two points: > >First regarding trying to do ECMP: >So, suppose you wanted to do OAM somewhere in the middle of >the network. >The LSR looks at the top label. It understands that. It looks at the >next label. It's bottom-of-stack. It looks at the next nibble - not >4x. Do you assume it is an Ethernet packet? Do you have a clue what >kind of PW it is to make any assumptions about the usable fields for >ECMP? I am not understanding your point about wanting to do "OAM in the middle of the network". If you want to test the PWs that the VPLS is using, you can do that very easily using the same label stack that the PW uses (see VCCV and LSP ping). If you want to test any other labels/tunnels in the core, you use LSP ping. These all work fine whether or not ECMP is in use, or whether there is an ENET packet contained in the PW (or whatever). >Second, regarding ECMP: >If the MAC learning was correctly executed, at ingress, the PW >chosen to >forward will still be the right one, the outgoing interface to the >customer will still the right one, unless for some reason the dest MAC >was learned against the wrong VPLS peer, on the wrong PW. In >that case, you can correctly report the error. In other words, at the VPLS level, >the ping/traceroute follows the PWs of the VPLS properly. Not necessarily. The lesson to be learned from the work done over the past year or so on LSP ping is that you should not count on any specific ECMP behavior within the core; just that it might happen and if and when it does, you need to handle it. Thus, even if your PE happens to choose the right outgoing label at the ingress PE, it is very possible that a core LSR may still choose a different path in the core if it hashes on the entire label stack. This happens of course because another label (for OAM) has been inserted into the label stack. Also, there was no reply to my TTL/forwarding question. --Tom >-Vach > > --__--__-- Message: 5 From: Olen Stokes To: "'tnadeau@cisco.com'" , Olen Stokes , "'Thippanna Hongal'" , marc.lasserre@riverstonenet.com, l2vpn@ietf.org Cc: pishwar@riverstonenet.com Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Wed, 5 Nov 2003 06:50:22 -0800 Question copied from below.... > Could you please explain/elaborate on how the TTL is > treated in the aforementioned packets? Your packet dump does > not show this. Specifically, what happens to the header + TTL > as the packet traverses the MPLS network between the VPLS bridges > as described in section 8.2.2 of your draft. I apologize, but Section 8.2.2 is the best way that I know how to describe the handling of the TTL in the VC FEC label. Can you give me a specific scenario that is not covered in the draft? In case anyone is not aware, the draft describes a method for handling the TTL in the VC FEC label. For example, consider a packet from a spoke node received at a core node. The TTL in the received VC FEC label is decremented and the result placed in the TTL of the outgoing VC FEC label. Comment copied from below.... > It should be pointed out that this extra label also adds the > potential for the OAM packets being forwarded along ECMP paths that > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious > deficiency to me as it can result in false results. This is already discussed in Sections 8.1.4 and in Section 11 of the draft. There has been no attempt to hide this issue. If you have any suggestions for wording to make this clearer, I would be happy to take a look. Cheers, Olen > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, November 04, 2003 11:38 AM > To: 'Olen Stokes'; 'Thippanna Hongal'; > marc.lasserre@riverstonenet.com; > l2vpn@ietf.org > Cc: pishwar@riverstonenet.com > Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > One question and one comment below. > > >-----Original Message----- > >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > >Behalf Of Olen Stokes > >Sent: Tuesday, November 04, 2003 11:04 AM > >To: 'Thippanna Hongal'; Olen Stokes; > >marc.lasserre@riverstonenet.com; l2vpn@ietf.org > >Cc: pishwar@riverstonenet.com > >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > > > > >Please see in line.... > > > > > > > >> -----Original Message----- > >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > >> Sent: Friday, October 31, 2003 6:08 PM > >> To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > >> l2vpn@ietf.org > >> Cc: pishwar@riverstonenet.com > >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > >> > >> > >> hi Stokes, > >> > >> Below is the packet format on the wire as we understand from > >> the draft. > >> We have a few questins on this. > >> > >> Packet for the PING > >> > >> dmac1 (Next hop router) > >> smac1 (Of the originating router) > >> Etype - 8847 > >> Transport label -|__________________ Pseudo wire > >> Vc label ------| > >> dmac2 (of the target mtu/pe to which the ping is targeted) > >> smac2 (of the originating router (PE/MTU)) > >> etype (IP 0x800) > >> ... > >> Mac TLV > >> smac3 -- (??) > >> dmac3 -- (customer's mac/spoke's mac to be pinged). > >> > >> a) Is the above representation correct? > >> > >Here is an internal debug dump of a VPLS ping about to be sent... > > > > > >00 01 30 05 84 00 Next Hop Router MAC > >00 01 30 08 92 00 Local (originating) Router MAC > > > >88 47 Ethertype = MPLS > >cb 00 10 ff Tunnel Label > >8c 00 40 ff VC Label > >00 00 e1 ff OAM Label > > > >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged > >00 01 02 03 04 05 Local Customer MAC > >08 00 Ethertype = IP > > > >45 IPv4 > >00 TOS > >00 6c Length > >00 80 ID > >00 00 Offset > >ff TTL > >11 protocol = UDP > >cc 31 Header Checksum > >0b 64 64 09 Src IP > >7f 00 00 62 Dst IP > > > >95 80 UDP Src Port = 38272 > >0d af UDP Dst Port = 3503 > >00 58 UDP Length > >00 00 UDP Checksum > > > >00 01 LSP Ping Version Number = 1 > >00 00 Must Be Zero > >01 Message Type = MPLS Echo Request > >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >00 Return Code > >00 Return Subcode > >00 04 00 01 Sender's Handle > >00 00 00 61 Sequence Number > >3f a7 5e 0c Timestamp Sent (seconds) > >00 04 ba f0 Timestamp Sent (microseconds) > >00 00 00 00 Timestamp Received (seconds) > >00 00 00 00 Timestamp Received (microseconds) > > > >00 01 Type = Target FEC Stack > >00 20 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 1c Length > >00 00 07 d0 VC ID > >00 05 Encapsulation Type = Ethernet > >00 00 Must Be Zero > >00 05 L2 Specific Sub-Type = Ethernet > >00 10 Length > >00 01 30 05 84 00 Target Ethernet MAC > >00 00 > >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > > > >00 00 > > > >00 03 Type = Pad > >00 08 Length > >02 Copy Pad TLV to Reply > >44 45 41 44 Pad Data > >42 45 45 > > > > > > > > > >> b) What is the value of the smac3 in the TLV. Is it mandatory ?. > >> Should the reply take the path using the smac3 for lookup > >> (for reply mode 5)? Pseudo Wire Connectivity verification ?. > > > >This is the MAC to which the reply should be sent. It is included to > >support implementations where the processing is distributed in > >case the MAC > >header is not passed along with the IP packet. > > > >Here is an internal debug dump of a reply to a similar VPLS > >ping about to be > >sent... > > > > > >00 01 30 08 92 00 Next Hop Router MAC > >00 01 30 05 84 00 Local (originating) Router MAC > > > > > >88 47 Ethertype = MPLS > >cb 00 10 ff Tunnel Label > >8c 00 30 ff VC Label > >00 00 e1 ff OAM Label > > > >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender > >Ethernet MAC from > >request) > >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target > >Ethernet MAC from > >request) > >08 00 Ethertype = IP > > > >45 IPv4 > >00 TOS > >00 78 Length > >00 93 ID > >00 00 Offset > >ff TTL > >11 protocol = UDP > >cc 59 Header Checksum > >0b 64 64 08 Src IP > >7f 00 00 1c Dst IP > > > >0d af UDP Src Port = 3503 > >95 80 UDP Dst Port = 38272 > >00 64 UDP Length > >00 00 UDP Checksum > > > >00 01 LSP Ping Version Number = 1 > >00 00 Must Be Zero > >02 Message Type = MPLS Echo Reply > >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >00 Return Code > >00 Return Subcode > >00 05 00 01 Sender's Handle > >00 00 00 1b Sequence Number > >3f a7 62 be Timestamp Sent (seconds) > >00 06 8f b0 Timestamp Sent (microseconds) > >3f a7 56 45 Timestamp Received (seconds) > >00 04 ba f0 Timestamp Received (microseconds) > > > >00 01 Type = Target FEC Stack > >00 20 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 1c Length > >00 00 07 d0 VC ID > >00 05 Encapsulation Type = Ethernet > >00 00 Must Be Zero > >00 05 L2 Specific Sub-Type = Ethernet > >00 10 Length > >00 01 30 05 84 00 Target Ethernet MAC > >00 00 > >00 01 02 03 04 05 Sender Ethernet MAC > >00 00 > > > >00 04 Type = Error Code > >00 08 Length > >00 0a Sub-Type = Hierarchical L2 Circuit ID > >00 04 Length > >00 01 Error Code = Replying router is the Egress > >for the MAC > >00 00 Must Be Zero > > > >00 03 Type = Pad > >00 08 Length > >02 Copy Pad TLV to Reply > >44 45 41 44 Pad Data > >42 45 45 > > > >In this example, when the reply is received at the originating > >PE, the OAM label causes the packet to be processed at the > PE and not > >forwarded to the customer. > > Could you please explain/elaborate on how the TTL is > treated in the aforementioned packets? Your packet dump does > not show this. Specifically, what happens to the header + TTL > as the packet traverses the MPLS network between the VPLS bridges > as described in section 8.2.2 of your draft. > > >> c) Is there any relation between smac2 and smac3 ?. > >> > > > >Normally they would be the same. > > > > > > > >> d) We have assumed that the dmac2 is either the mac of the > >> target MTU/PE. This is because if the customer dmac is > >> used the packet would show up at the customer. If the > >> router alert is used the the packet would not go beyond > >> the PE. So is this assumption correct ?. > > > >You need the OAM label to prevent the packet from reaching > >customer devices. > > It should be pointed out that this extra label also adds the > potential for the OAM packets being forwarded along ECMP paths that > differ from those of the original data packets. I think you > are making the assumption that the VC label is the only one > used for load-share computation. This seems like a serious > deficiency to me as it can result in false results. > > --Tom > > > > >Remember that if dmac2 is not known in the network, the packet may be > >flooded. It would then reach PEs other than the one > >associated with dmac2. > >The OAM label allows these switches to prevent the traffic reaching a > >customer. > > > > > > > >> > >> e) pre-condition: > >> To do a VPLS ping to verify customer MAC sitting at > >> the remote end, we have to have a actual customer > >> traffic flowing on > >> the pseudo-wire, or at least some customer traffic has > >> to be there > >> within the 'L2 age out' time period. > >> For VPLS ping to work, this is a pre-condition. > >> > >> Question is 'Is this a valid pre-condition ?', If > yes, are users > >> OK with this model of OAM ?. > >> > > > >As stated above, if the MAC is unknown, the packet is to be > >flooded as would > >any normal packet. Therefore, the intent that this > >pre-condition should not > >be necessary. > > > > > > > >> > >> thanks > >> hongal > >> > > > --__--__-- _______________________________________________ L2vpn mailing list L2vpn@ietf.org https://www1.ietf.org/mailman/listinfo/l2vpn End of L2vpn Digest From exim@www1.ietf.org Wed Nov 5 10:08:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08530 for ; Wed, 5 Nov 2003 10:08:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPGM-0006rP-9U for l2vpn-archive@odin.ietf.org; Wed, 05 Nov 2003 10:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5F826x026365 for l2vpn-archive@odin.ietf.org; Wed, 5 Nov 2003 10:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPGM-0006rA-4I for l2vpn-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 10:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08473 for ; Wed, 5 Nov 2003 10:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPGK-0005V1-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 10:08:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPGJ-0005Uy-00 for l2vpn-web-archive@ietf.org; Wed, 05 Nov 2003 10:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPGK-0006qf-9j; Wed, 05 Nov 2003 10:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPG9-0006oU-1p for l2vpn@optimus.ietf.org; Wed, 05 Nov 2003 10:07:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08435 for ; Wed, 5 Nov 2003 10:07:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPG6-0005Ue-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 10:07:46 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHPG6-0005UP-00 for l2vpn@ietf.org; Wed, 05 Nov 2003 10:07:46 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5F7BAt005233; Wed, 5 Nov 2003 07:07:12 -0800 (PST) Received: from tnadeauw2k02 (dhcp-10-86-165-58.cisco.com [10.86.165.58]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS89628; Wed, 5 Nov 2003 10:07:10 -0500 (EST) Reply-To: From: "Thomas D. Nadeau" To: "'Olen Stokes'" , "'Thippanna Hongal'" , , Cc: Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Wed, 5 Nov 2003 10:06:59 -0500 Organization: Cisco Systems, inc. Message-ID: <001001c3a3ae$7bd3f030$3aa5560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3DC3910A44FBD94B8513C8E2A3F220E123FD90@sc-msexch-16.extremenetworks.com> Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Olen Stokes [mailto:ostokes@extremenetworks.com] >Sent: Wednesday, November 05, 2003 9:50 AM >To: 'tnadeau@cisco.com'; Olen Stokes; 'Thippanna Hongal'; >marc.lasserre@riverstonenet.com; l2vpn@ietf.org >Cc: pishwar@riverstonenet.com >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > >Question copied from below.... > >> Could you please explain/elaborate on how the TTL is >> treated in the aforementioned packets? Your packet dump does >> not show this. Specifically, what happens to the header + TTL >> as the packet traverses the MPLS network between the VPLS bridges >> as described in section 8.2.2 of your draft. > >I apologize, but Section 8.2.2 is the best way that I know how >to describe the handling of the TTL in the VC FEC label. Can you give me >a specific scenario that is not covered in the draft? > >In case anyone is not aware, the draft describes a method for >handling the >TTL in the VC FEC label. For example, consider a packet from >a spoke node >received at a core node. The TTL in the received VC FEC label is >decremented and the result placed in the TTL of the outgoing >VC FEC label. The problem with the algorithm described is that it requires the basic MPLS forwarding/switching functions as described in the MPLS architecutre and which is widely deployed in networks today, to be altered. VPLS is made up of pseudo-wires which begin and end at VPLS bridge entities. What you are describing is that when a pseudo-wire terminates (at the hub in your example), that the TTL information is passed to another PW carried by a different LSP. This seems like a major layering violation to me. The other question is how does your mechanism work when L2TPv3 is used as one or part of the PWs used in the VPLS? >Comment copied from below.... > >> It should be pointed out that this extra label also adds the >> potential for the OAM packets being forwarded along ECMP paths that >> differ from those of the original data packets. I think you >> are making the assumption that the VC label is the only one >> used for load-share computation. This seems like a serious >> deficiency to me as it can result in false results. > >This is already discussed in Sections 8.1.4 and in Section 11 >of the draft. >There has been no attempt to hide this issue. If you have any >suggestions >for wording to make this clearer, I would be happy to take a look. I suggest that this mechanism is inappropriate for the reasons stated because it potentially violates the MPLS OAM requirements as stated in draft-ietf-mpls-oam-requirements-02.txt as well as the requirements stated at the beginning of your draft itself. There are other mechanisms available like VCCV which do not alter the fundamental forwardinging and do test the actual PW's dataplane path. There are other mechanisms being worked on in the 802.11ad group at the IEEE for testing ENET segment OAM. I recommend that we use the appropriate tools to test the appropriate levels within the network instead of munging things together. --Tom >Cheers, >Olen > > >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> Sent: Tuesday, November 04, 2003 11:38 AM >> To: 'Olen Stokes'; 'Thippanna Hongal'; >> marc.lasserre@riverstonenet.com; >> l2vpn@ietf.org >> Cc: pishwar@riverstonenet.com >> Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt >> >> >> >> One question and one comment below. >> >> >-----Original Message----- >> >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On >> >Behalf Of Olen Stokes >> >Sent: Tuesday, November 04, 2003 11:04 AM >> >To: 'Thippanna Hongal'; Olen Stokes; >> >marc.lasserre@riverstonenet.com; l2vpn@ietf.org >> >Cc: pishwar@riverstonenet.com >> >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt >> > >> > >> > >> >Please see in line.... >> > >> > >> > >> >> -----Original Message----- >> >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] >> >> Sent: Friday, October 31, 2003 6:08 PM >> >> To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; >> >> l2vpn@ietf.org >> >> Cc: pishwar@riverstonenet.com >> >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt >> >> >> >> >> >> hi Stokes, >> >> >> >> Below is the packet format on the wire as we understand from >> >> the draft. >> >> We have a few questins on this. >> >> >> >> Packet for the PING >> >> >> >> dmac1 (Next hop router) >> >> smac1 (Of the originating router) >> >> Etype - 8847 >> >> Transport label -|__________________ Pseudo wire >> >> Vc label ------| >> >> dmac2 (of the target mtu/pe to which the ping is targeted) >> >> smac2 (of the originating router (PE/MTU)) >> >> etype (IP 0x800) >> >> ... >> >> Mac TLV >> >> smac3 -- (??) >> >> dmac3 -- (customer's mac/spoke's mac to be pinged). >> >> >> >> a) Is the above representation correct? >> >> >> >Here is an internal debug dump of a VPLS ping about to be sent... >> > >> > >> >00 01 30 05 84 00 Next Hop Router MAC >> >00 01 30 08 92 00 Local (originating) Router MAC >> > >> >88 47 Ethertype = MPLS >> >cb 00 10 ff Tunnel Label >> >8c 00 40 ff VC Label >> >00 00 e1 ff OAM Label >> > >> >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged >> >00 01 02 03 04 05 Local Customer MAC >> >08 00 Ethertype = IP >> > >> >45 IPv4 >> >00 TOS >> >00 6c Length >> >00 80 ID >> >00 00 Offset >> >ff TTL >> >11 protocol = UDP >> >cc 31 Header Checksum >> >0b 64 64 09 Src IP >> >7f 00 00 62 Dst IP >> > >> >95 80 UDP Src Port = 38272 >> >0d af UDP Dst Port = 3503 >> >00 58 UDP Length >> >00 00 UDP Checksum >> > >> >00 01 LSP Ping Version Number = 1 >> >00 00 Must Be Zero >> >01 Message Type = MPLS Echo Request >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >> >00 Return Code >> >00 Return Subcode >> >00 04 00 01 Sender's Handle >> >00 00 00 61 Sequence Number >> >3f a7 5e 0c Timestamp Sent (seconds) >> >00 04 ba f0 Timestamp Sent (microseconds) >> >00 00 00 00 Timestamp Received (seconds) >> >00 00 00 00 Timestamp Received (microseconds) >> > >> >00 01 Type = Target FEC Stack >> >00 20 Length >> >00 0a Sub-Type = Hierarchical L2 Circuit ID >> >00 1c Length >> >00 00 07 d0 VC ID >> >00 05 Encapsulation Type = Ethernet >> >00 00 Must Be Zero >> >00 05 L2 Specific Sub-Type = Ethernet >> >00 10 Length >> >00 01 30 05 84 00 Target Ethernet MAC >> >00 00 >> >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) >> > >> >00 00 >> > >> >00 03 Type = Pad >> >00 08 Length >> >02 Copy Pad TLV to Reply >> >44 45 41 44 Pad Data >> >42 45 45 >> > >> > >> > >> > >> >> b) What is the value of the smac3 in the TLV. Is it mandatory ?. >> >> Should the reply take the path using the smac3 for lookup >> >> (for reply mode 5)? Pseudo Wire Connectivity verification ?. >> > >> >This is the MAC to which the reply should be sent. It is >included to >> >support implementations where the processing is distributed in >> >case the MAC >> >header is not passed along with the IP packet. >> > >> >Here is an internal debug dump of a reply to a similar VPLS >> >ping about to be >> >sent... >> > >> > >> >00 01 30 08 92 00 Next Hop Router MAC >> >00 01 30 05 84 00 Local (originating) Router MAC >> > >> > >> >88 47 Ethertype = MPLS >> >cb 00 10 ff Tunnel Label >> >8c 00 30 ff VC Label >> >00 00 e1 ff OAM Label >> > >> >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender >> >Ethernet MAC from >> >request) >> >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target >> >Ethernet MAC from >> >request) >> >08 00 Ethertype = IP >> > >> >45 IPv4 >> >00 TOS >> >00 78 Length >> >00 93 ID >> >00 00 Offset >> >ff TTL >> >11 protocol = UDP >> >cc 59 Header Checksum >> >0b 64 64 08 Src IP >> >7f 00 00 1c Dst IP >> > >> >0d af UDP Src Port = 3503 >> >95 80 UDP Dst Port = 38272 >> >00 64 UDP Length >> >00 00 UDP Checksum >> > >> >00 01 LSP Ping Version Number = 1 >> >00 00 Must Be Zero >> >02 Message Type = MPLS Echo Reply >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet >> >00 Return Code >> >00 Return Subcode >> >00 05 00 01 Sender's Handle >> >00 00 00 1b Sequence Number >> >3f a7 62 be Timestamp Sent (seconds) >> >00 06 8f b0 Timestamp Sent (microseconds) >> >3f a7 56 45 Timestamp Received (seconds) >> >00 04 ba f0 Timestamp Received (microseconds) >> > >> >00 01 Type = Target FEC Stack >> >00 20 Length >> >00 0a Sub-Type = Hierarchical L2 Circuit ID >> >00 1c Length >> >00 00 07 d0 VC ID >> >00 05 Encapsulation Type = Ethernet >> >00 00 Must Be Zero >> >00 05 L2 Specific Sub-Type = Ethernet >> >00 10 Length >> >00 01 30 05 84 00 Target Ethernet MAC >> >00 00 >> >00 01 02 03 04 05 Sender Ethernet MAC >> >00 00 >> > >> >00 04 Type = Error Code >> >00 08 Length >> >00 0a Sub-Type = Hierarchical L2 Circuit ID >> >00 04 Length >> >00 01 Error Code = Replying router is the Egress >> >for the MAC >> >00 00 Must Be Zero >> > >> >00 03 Type = Pad >> >00 08 Length >> >02 Copy Pad TLV to Reply >> >44 45 41 44 Pad Data >> >42 45 45 >> > >> >In this example, when the reply is received at the originating >> >PE, the OAM label causes the packet to be processed at the >> PE and not >> >forwarded to the customer. >> >> Could you please explain/elaborate on how the TTL is >> treated in the aforementioned packets? Your packet dump does >> not show this. Specifically, what happens to the header + TTL >> as the packet traverses the MPLS network between the VPLS bridges >> as described in section 8.2.2 of your draft. >> >> >> c) Is there any relation between smac2 and smac3 ?. >> >> >> > >> >Normally they would be the same. >> > >> > >> > >> >> d) We have assumed that the dmac2 is either the mac of the >> >> target MTU/PE. This is because if the customer dmac is >> >> used the packet would show up at the customer. If the >> >> router alert is used the the packet would not go beyond >> >> the PE. So is this assumption correct ?. >> > >> >You need the OAM label to prevent the packet from reaching >> >customer devices. >> >> It should be pointed out that this extra label also adds the >> potential for the OAM packets being forwarded along ECMP paths that >> differ from those of the original data packets. I think you >> are making the assumption that the VC label is the only one >> used for load-share computation. This seems like a serious >> deficiency to me as it can result in false results. >> >> --Tom >> >> >> >> >Remember that if dmac2 is not known in the network, the >packet may be >> >flooded. It would then reach PEs other than the one >> >associated with dmac2. >> >The OAM label allows these switches to prevent the traffic >reaching a >> >customer. >> > >> > >> > >> >> >> >> e) pre-condition: >> >> To do a VPLS ping to verify customer MAC sitting at >> >> the remote end, we have to have a actual customer >> >> traffic flowing on >> >> the pseudo-wire, or at least some customer traffic has >> >> to be there >> >> within the 'L2 age out' time period. >> >> For VPLS ping to work, this is a pre-condition. >> >> >> >> Question is 'Is this a valid pre-condition ?', If >> yes, are users >> >> OK with this model of OAM ?. >> >> >> > >> >As stated above, if the MAC is unknown, the packet is to be >> >flooded as would >> >any normal packet. Therefore, the intent that this >> >pre-condition should not >> >be necessary. >> > >> > >> > >> >> >> >> thanks >> >> hongal >> >> >> > >> > From exim@www1.ietf.org Fri Nov 7 14:25:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02835 for ; Fri, 7 Nov 2003 14:25:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEJ-0001Hj-OF for l2vpn-archive@odin.ietf.org; Fri, 07 Nov 2003 14:25:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JPBHh004933 for l2vpn-archive@odin.ietf.org; Fri, 7 Nov 2003 14:25:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEJ-0001HU-H1 for l2vpn-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02800 for ; Fri, 7 Nov 2003 14:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICEG-0001ha-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 14:25:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICEG-0001hV-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 14:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICEA-0001Ej-LX; Fri, 07 Nov 2003 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICDX-0001DM-RM for l2vpn@optimus.ietf.org; Fri, 07 Nov 2003 14:24:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02716 for ; Fri, 7 Nov 2003 14:24:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICDV-0001g8-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 14:24:21 -0500 Received: from mail1.ssmb.com ([199.67.139.25] helo=imbaspam-ny03.ssmb.com) by ietf-mx with esmtp (Exim 4.12) id 1AICDU-0001g4-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 14:24:20 -0500 Received: from imbarc-ny02.ny.ssmb.com (imbarc-ny02-1 [162.124.186.139]) by imbaspam-ny03.ssmb.com (8.12.10/8.12.10/SSMB_EXT/evision: 1.26 $) with ESMTP id hA7JNkoD023250 for ; Fri, 7 Nov 2003 14:23:46 -0500 (EST) Received: from mailhub-nyc2.ny.ssmb.com (mailhub-nyc2-hme0.ny.ssmb.com [162.124.148.16]) by imbarc-ny02.ny.ssmb.com (8.12.9/8.12.9/SSMB_QQQ_IN/1.1) with ESMTP id hA7JNiAs018865 for ; Fri, 7 Nov 2003 14:23:44 -0500 (EST) Received: from exnyims01.nj.ssmb.com (EXNYIMS01.ny.ssmb.com [162.124.190.168]) by mailhub-nyc2.ny.ssmb.com (8.9.3-GEMSp3/8.9.3/SSMB-HUB) with ESMTP id OAA09324 for ; Fri, 7 Nov 2003 14:23:43 -0500 (EST) Received: by EXNYIMS01.ny.ssmb.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 14:22:49 -0500 Message-ID: <159DF57E62CDD5118FCA0002A51352B00AA1F8D8@EXCHNY36.ny.ssmb.com> From: "Hawthorne, Austin J [IT]" To: "'l2vpn@ietf.org'" Subject: Unqualified Learning Question? Date: Fri, 7 Nov 2003 14:23:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.36 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I have a question about section 8.1.1 of draft-ietf-ppvpn-vpls-ldp-01.txt, specifically this text: "In unqualified learning, all the customer VLANs are handled by a single VPLS, which means they all share a single broadcast domain and a single MAC address space." Does that imply that in unqualified learning, multiple VLANs from the same VPLS instance will be bridged together in a single broadcast domain? Thanks, Austin From exim@www1.ietf.org Fri Nov 7 14:52:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03926 for ; Fri, 7 Nov 2003 14:52:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICeI-00042q-Fe for l2vpn-archive@odin.ietf.org; Fri, 07 Nov 2003 14:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Jq20s015542 for l2vpn-archive@odin.ietf.org; Fri, 7 Nov 2003 14:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICeI-00042b-9M for l2vpn-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03913 for ; Fri, 7 Nov 2003 14:51:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICeF-000251-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 14:51:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICeF-00024y-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 14:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICeG-000426-47; Fri, 07 Nov 2003 14:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICe9-0003yY-Tt for l2vpn@optimus.ietf.org; Fri, 07 Nov 2003 14:51:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03907 for ; Fri, 7 Nov 2003 14:51:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICe6-00024o-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 14:51:50 -0500 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1AICe5-00024j-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 14:51:49 -0500 Received: from MARCLWIN2K by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA25118; Fri, 7 Nov 2003 11:50:50 -0800 (PST) Message-ID: <03a601c3a568$7246cbd0$6401a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Hawthorne, Austin J [IT]" , References: <159DF57E62CDD5118FCA0002A51352B00AA1F8D8@EXCHNY36.ny.ssmb.com> Subject: Re: Unqualified Learning Question? Date: Fri, 7 Nov 2003 20:50:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Austin, No, it does not imply that VLANs are bridged together. What it means is that there is a single VPLS broadcast domain used to carry traffic from different VLANs belonging to a specific a customer VPN. Marc ----- Original Message ----- From: "Hawthorne, Austin J [IT]" To: Sent: Friday, November 07, 2003 20:23 Subject: Unqualified Learning Question? > I have a question about section 8.1.1 of draft-ietf-ppvpn-vpls-ldp-01.txt, > specifically this text: > > "In unqualified learning, all the customer VLANs are handled by a single > VPLS, which means they all share a single broadcast domain and a single MAC > address space." > > Does that imply that in unqualified learning, multiple VLANs from the same > VPLS instance will be bridged together in a single broadcast domain? > > Thanks, > > Austin > > From exim@www1.ietf.org Fri Nov 7 22:57:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21367 for ; Fri, 7 Nov 2003 22:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIKDl-0005EP-Uf for l2vpn-archive@odin.ietf.org; Fri, 07 Nov 2003 22:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA83v9a7020103 for l2vpn-archive@odin.ietf.org; Fri, 7 Nov 2003 22:57:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIKDl-0005EA-Ot for l2vpn-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 22:57:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21361 for ; Fri, 7 Nov 2003 22:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIKDi-0000Ej-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 22:57:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIKDh-0000Eg-00 for l2vpn-web-archive@ietf.org; Fri, 07 Nov 2003 22:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIKDd-0005Dc-Kh; Fri, 07 Nov 2003 22:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIKDJ-0005DN-JA for l2vpn@optimus.ietf.org; Fri, 07 Nov 2003 22:56:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21351 for ; Fri, 7 Nov 2003 22:56:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIKDF-0000EW-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 22:56:37 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIKDF-0000Dz-00 for l2vpn@ietf.org; Fri, 07 Nov 2003 22:56:37 -0500 Received: from sajassi-w2k4.cisco.com (dhcp-171-68-147-20.cisco.com [171.68.147.20]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA83u4w6011096; Fri, 7 Nov 2003 19:56:04 -0800 (PST) Message-Id: <4.3.2.7.2.20031107194204.027e9808@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Nov 2003 19:56:04 -0800 To: , "'Olen Stokes'" , "'Thippanna Hongal'" , , From: Ali Sajassi Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Cc: In-Reply-To: <001001c3a3ae$7bd3f030$3aa5560a@amer.cisco.com> References: <3DC3910A44FBD94B8513C8E2A3F220E123FD90@sc-msexch-16.extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > There are other mechanisms being worked >on in the 802.11ad group at the IEEE for testing ENET segment OAM. >I recommend that we use the appropriate tools to test the appropriate >levels within the network instead of munging things together. Yes, Ethernet service layer OAM must be completely independent from transport layer OAM (e.g., an end to end VPLS service can have different transport layers - one network segment can be QinQ, another can be MPLS, and yet another can be L2TPv3). That is why in all the different standards groups such as ITU, MEF, and IEEE, the fundamental requirement is for Ethernet service layer OAM to be independent from transport layer OAM. Both ITU and MEF have produced some preliminary drafts that may of interest to those who want to explore this further. -Ali > --Tom > > > > > >Cheers, > >Olen > > > > > >> -----Original Message----- > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> Sent: Tuesday, November 04, 2003 11:38 AM > >> To: 'Olen Stokes'; 'Thippanna Hongal'; > >> marc.lasserre@riverstonenet.com; > >> l2vpn@ietf.org > >> Cc: pishwar@riverstonenet.com > >> Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > >> > >> > >> > >> One question and one comment below. > >> > >> >-----Original Message----- > >> >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > >> >Behalf Of Olen Stokes > >> >Sent: Tuesday, November 04, 2003 11:04 AM > >> >To: 'Thippanna Hongal'; Olen Stokes; > >> >marc.lasserre@riverstonenet.com; l2vpn@ietf.org > >> >Cc: pishwar@riverstonenet.com > >> >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > >> > > >> > > >> > > >> >Please see in line.... > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > >> >> Sent: Friday, October 31, 2003 6:08 PM > >> >> To: ostokes@extremenetworks.com; marc.lasserre@riverstonenet.com; > >> >> l2vpn@ietf.org > >> >> Cc: pishwar@riverstonenet.com > >> >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > >> >> > >> >> > >> >> hi Stokes, > >> >> > >> >> Below is the packet format on the wire as we understand from > >> >> the draft. > >> >> We have a few questins on this. > >> >> > >> >> Packet for the PING > >> >> > >> >> dmac1 (Next hop router) > >> >> smac1 (Of the originating router) > >> >> Etype - 8847 > >> >> Transport label -|__________________ Pseudo wire > >> >> Vc label ------| > >> >> dmac2 (of the target mtu/pe to which the ping is targeted) > >> >> smac2 (of the originating router (PE/MTU)) > >> >> etype (IP 0x800) > >> >> ... > >> >> Mac TLV > >> >> smac3 -- (??) > >> >> dmac3 -- (customer's mac/spoke's mac to be pinged). > >> >> > >> >> a) Is the above representation correct? > >> >> > >> >Here is an internal debug dump of a VPLS ping about to be sent... > >> > > >> > > >> >00 01 30 05 84 00 Next Hop Router MAC > >> >00 01 30 08 92 00 Local (originating) Router MAC > >> > > >> >88 47 Ethertype = MPLS > >> >cb 00 10 ff Tunnel Label > >> >8c 00 40 ff VC Label > >> >00 00 e1 ff OAM Label > >> > > >> >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged > >> >00 01 02 03 04 05 Local Customer MAC > >> >08 00 Ethertype = IP > >> > > >> >45 IPv4 > >> >00 TOS > >> >00 6c Length > >> >00 80 ID > >> >00 00 Offset > >> >ff TTL > >> >11 protocol = UDP > >> >cc 31 Header Checksum > >> >0b 64 64 09 Src IP > >> >7f 00 00 62 Dst IP > >> > > >> >95 80 UDP Src Port = 38272 > >> >0d af UDP Dst Port = 3503 > >> >00 58 UDP Length > >> >00 00 UDP Checksum > >> > > >> >00 01 LSP Ping Version Number = 1 > >> >00 00 Must Be Zero > >> >01 Message Type = MPLS Echo Request > >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >> >00 Return Code > >> >00 Return Subcode > >> >00 04 00 01 Sender's Handle > >> >00 00 00 61 Sequence Number > >> >3f a7 5e 0c Timestamp Sent (seconds) > >> >00 04 ba f0 Timestamp Sent (microseconds) > >> >00 00 00 00 Timestamp Received (seconds) > >> >00 00 00 00 Timestamp Received (microseconds) > >> > > >> >00 01 Type = Target FEC Stack > >> >00 20 Length > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > >> >00 1c Length > >> >00 00 07 d0 VC ID > >> >00 05 Encapsulation Type = Ethernet > >> >00 00 Must Be Zero > >> >00 05 L2 Specific Sub-Type = Ethernet > >> >00 10 Length > >> >00 01 30 05 84 00 Target Ethernet MAC > >> >00 00 > >> >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > >> > > >> >00 00 > >> > > >> >00 03 Type = Pad > >> >00 08 Length > >> >02 Copy Pad TLV to Reply > >> >44 45 41 44 Pad Data > >> >42 45 45 > >> > > >> > > >> > > >> > > >> >> b) What is the value of the smac3 in the TLV. Is it mandatory ?. > >> >> Should the reply take the path using the smac3 for lookup > >> >> (for reply mode 5)? Pseudo Wire Connectivity verification ?. > >> > > >> >This is the MAC to which the reply should be sent. It is > >included to > >> >support implementations where the processing is distributed in > >> >case the MAC > >> >header is not passed along with the IP packet. > >> > > >> >Here is an internal debug dump of a reply to a similar VPLS > >> >ping about to be > >> >sent... > >> > > >> > > >> >00 01 30 08 92 00 Next Hop Router MAC > >> >00 01 30 05 84 00 Local (originating) Router MAC > >> > > >> > > >> >88 47 Ethertype = MPLS > >> >cb 00 10 ff Tunnel Label > >> >8c 00 30 ff VC Label > >> >00 00 e1 ff OAM Label > >> > > >> >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender > >> >Ethernet MAC from > >> >request) > >> >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target > >> >Ethernet MAC from > >> >request) > >> >08 00 Ethertype = IP > >> > > >> >45 IPv4 > >> >00 TOS > >> >00 78 Length > >> >00 93 ID > >> >00 00 Offset > >> >ff TTL > >> >11 protocol = UDP > >> >cc 59 Header Checksum > >> >0b 64 64 08 Src IP > >> >7f 00 00 1c Dst IP > >> > > >> >0d af UDP Src Port = 3503 > >> >95 80 UDP Dst Port = 38272 > >> >00 64 UDP Length > >> >00 00 UDP Checksum > >> > > >> >00 01 LSP Ping Version Number = 1 > >> >00 00 Must Be Zero > >> >02 Message Type = MPLS Echo Reply > >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > >> >00 Return Code > >> >00 Return Subcode > >> >00 05 00 01 Sender's Handle > >> >00 00 00 1b Sequence Number > >> >3f a7 62 be Timestamp Sent (seconds) > >> >00 06 8f b0 Timestamp Sent (microseconds) > >> >3f a7 56 45 Timestamp Received (seconds) > >> >00 04 ba f0 Timestamp Received (microseconds) > >> > > >> >00 01 Type = Target FEC Stack > >> >00 20 Length > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > >> >00 1c Length > >> >00 00 07 d0 VC ID > >> >00 05 Encapsulation Type = Ethernet > >> >00 00 Must Be Zero > >> >00 05 L2 Specific Sub-Type = Ethernet > >> >00 10 Length > >> >00 01 30 05 84 00 Target Ethernet MAC > >> >00 00 > >> >00 01 02 03 04 05 Sender Ethernet MAC > >> >00 00 > >> > > >> >00 04 Type = Error Code > >> >00 08 Length > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > >> >00 04 Length > >> >00 01 Error Code = Replying router is the Egress > >> >for the MAC > >> >00 00 Must Be Zero > >> > > >> >00 03 Type = Pad > >> >00 08 Length > >> >02 Copy Pad TLV to Reply > >> >44 45 41 44 Pad Data > >> >42 45 45 > >> > > >> >In this example, when the reply is received at the originating > >> >PE, the OAM label causes the packet to be processed at the > >> PE and not > >> >forwarded to the customer. > >> > >> Could you please explain/elaborate on how the TTL is > >> treated in the aforementioned packets? Your packet dump does > >> not show this. Specifically, what happens to the header + TTL > >> as the packet traverses the MPLS network between the VPLS bridges > >> as described in section 8.2.2 of your draft. > >> > >> >> c) Is there any relation between smac2 and smac3 ?. > >> >> > >> > > >> >Normally they would be the same. > >> > > >> > > >> > > >> >> d) We have assumed that the dmac2 is either the mac of the > >> >> target MTU/PE. This is because if the customer dmac is > >> >> used the packet would show up at the customer. If the > >> >> router alert is used the the packet would not go beyond > >> >> the PE. So is this assumption correct ?. > >> > > >> >You need the OAM label to prevent the packet from reaching > >> >customer devices. > >> > >> It should be pointed out that this extra label also adds the > >> potential for the OAM packets being forwarded along ECMP paths that > >> differ from those of the original data packets. I think you > >> are making the assumption that the VC label is the only one > >> used for load-share computation. This seems like a serious > >> deficiency to me as it can result in false results. > >> > >> --Tom > >> > >> > >> > >> >Remember that if dmac2 is not known in the network, the > >packet may be > >> >flooded. It would then reach PEs other than the one > >> >associated with dmac2. > >> >The OAM label allows these switches to prevent the traffic > >reaching a > >> >customer. > >> > > >> > > >> > > >> >> > >> >> e) pre-condition: > >> >> To do a VPLS ping to verify customer MAC sitting at > >> >> the remote end, we have to have a actual customer > >> >> traffic flowing on > >> >> the pseudo-wire, or at least some customer traffic has > >> >> to be there > >> >> within the 'L2 age out' time period. > >> >> For VPLS ping to work, this is a pre-condition. > >> >> > >> >> Question is 'Is this a valid pre-condition ?', If > >> yes, are users > >> >> OK with this model of OAM ?. > >> >> > >> > > >> >As stated above, if the MAC is unknown, the packet is to be > >> >flooded as would > >> >any normal packet. Therefore, the intent that this > >> >pre-condition should not > >> >be necessary. > >> > > >> > > >> > > >> >> > >> >> thanks > >> >> hongal > >> >> > >> > > >> > > From exim@www1.ietf.org Mon Nov 10 06:28:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16085 for ; Mon, 10 Nov 2003 06:28:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJADE-0007jP-Kr for l2vpn-archive@odin.ietf.org; Mon, 10 Nov 2003 06:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAABS4ke029713 for l2vpn-archive@odin.ietf.org; Mon, 10 Nov 2003 06:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJADE-0007jA-Fe for l2vpn-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 06:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16081 for ; Mon, 10 Nov 2003 06:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJADA-00034d-00 for l2vpn-web-archive@ietf.org; Mon, 10 Nov 2003 06:28:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJADA-00034Z-00 for l2vpn-web-archive@ietf.org; Mon, 10 Nov 2003 06:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJADB-0007if-Bm; Mon, 10 Nov 2003 06:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJACQ-0007hm-Mr for l2vpn@optimus.ietf.org; Mon, 10 Nov 2003 06:27:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16061 for ; Mon, 10 Nov 2003 06:26:59 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJACM-00034B-00 for l2vpn@ietf.org; Mon, 10 Nov 2003 06:27:10 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138] helo=i2kc03-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AJACL-00033v-00 for l2vpn@ietf.org; Mon, 10 Nov 2003 06:27:09 -0500 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by i2kc03-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 Nov 2003 11:26:36 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 Nov 2003 11:26:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Mon, 10 Nov 2003 11:26:36 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2DDE@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt thread-index: AcOlrHEx4lNYW7OUQZaeJCmgf8Sv6ABgGgqg To: , , , , , Cc: X-OriginalArrivalTime: 10 Nov 2003 11:26:36.0651 (UTC) FILETIME=[809513B0:01C3A77D] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ali....I agree with what you say here. But have you noticed that you = are effectively contradicting your recent posting to the PWE3 list wrt = (in your view) not retaining the FCS in ethernet? That is, the ethernet = FCS *belongs* to the ethernet client and must be independent of whatever = the server layer is....which is as you correctly note below, ie we must = have layer (in this case OAM) independence. The fact that one may have = to do a linear update of the FCS on a link-connection basis does not = alter this fact. Indeed, from a G.805/809 functional arch perspective, = the ethernet FCS belongs to the client->server adaptation process and = obviously applies on all client layer ethernet link-connections (as = provided by server layer trails). regards, Neil > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: 08 November 2003 03:56 > To: tnadeau@cisco.com; 'Olen Stokes'; 'Thippanna Hongal'; > marc.lasserre@riverstonenet.com; l2vpn@ietf.org > Cc: pishwar@riverstonenet.com > Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt >=20 >=20 >=20 > > There are other mechanisms being worked > >on in the 802.11ad group at the IEEE for testing ENET segment OAM. > >I recommend that we use the appropriate tools to test the appropriate > >levels within the network instead of munging things together. >=20 > Yes, Ethernet service layer OAM must be completely independent from=20 > transport layer OAM (e.g., an end to end VPLS service can=20 > have different=20 > transport layers - one network segment can be QinQ, another=20 > can be MPLS,=20 > and yet another can be L2TPv3). That is why in all the=20 > different standards=20 > groups such as ITU, MEF, and IEEE, the fundamental requirement is for=20 > Ethernet service layer OAM to be independent from transport layer=20 > OAM. Both ITU and MEF have produced some preliminary drafts=20 > that may of=20 > interest to those who want to explore this further. >=20 > -Ali >=20 >=20 > > --Tom > > > > > > > > > > >Cheers, > > >Olen > > > > > > > > >> -----Original Message----- > > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > >> Sent: Tuesday, November 04, 2003 11:38 AM > > >> To: 'Olen Stokes'; 'Thippanna Hongal'; > > >> marc.lasserre@riverstonenet.com; > > >> l2vpn@ietf.org > > >> Cc: pishwar@riverstonenet.com > > >> Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > >> > > >> > > >> > > >> One question and one comment below. > > >> > > >> >-----Original Message----- > > >> >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > > >> >Behalf Of Olen Stokes > > >> >Sent: Tuesday, November 04, 2003 11:04 AM > > >> >To: 'Thippanna Hongal'; Olen Stokes; > > >> >marc.lasserre@riverstonenet.com; l2vpn@ietf.org > > >> >Cc: pishwar@riverstonenet.com > > >> >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > >> > > > >> > > > >> > > > >> >Please see in line.... > > >> > > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > > >> >> Sent: Friday, October 31, 2003 6:08 PM > > >> >> To: ostokes@extremenetworks.com;=20 > marc.lasserre@riverstonenet.com; > > >> >> l2vpn@ietf.org > > >> >> Cc: pishwar@riverstonenet.com > > >> >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > >> >> > > >> >> > > >> >> hi Stokes, > > >> >> > > >> >> Below is the packet format on the wire as we understand from > > >> >> the draft. > > >> >> We have a few questins on this. > > >> >> > > >> >> Packet for the PING > > >> >> > > >> >> dmac1 (Next hop router) > > >> >> smac1 (Of the originating router) > > >> >> Etype - 8847 > > >> >> Transport label -|__________________ Pseudo wire > > >> >> Vc label ------| > > >> >> dmac2 (of the target mtu/pe to which the ping is targeted) > > >> >> smac2 (of the originating router (PE/MTU)) > > >> >> etype (IP 0x800) > > >> >> ... > > >> >> Mac TLV > > >> >> smac3 -- (??) > > >> >> dmac3 -- (customer's mac/spoke's mac to be pinged). > > >> >> > > >> >> a) Is the above representation correct? > > >> >> > > >> >Here is an internal debug dump of a VPLS ping about to=20 > be sent... > > >> > > > >> > > > >> >00 01 30 05 84 00 Next Hop Router MAC > > >> >00 01 30 08 92 00 Local (originating) Router MAC > > >> > > > >> >88 47 Ethertype =3D MPLS > > >> >cb 00 10 ff Tunnel Label > > >> >8c 00 40 ff VC Label > > >> >00 00 e1 ff OAM Label > > >> > > > >> >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged > > >> >00 01 02 03 04 05 Local Customer MAC > > >> >08 00 Ethertype =3D IP > > >> > > > >> >45 IPv4 > > >> >00 TOS > > >> >00 6c Length > > >> >00 80 ID > > >> >00 00 Offset > > >> >ff TTL > > >> >11 protocol =3D UDP > > >> >cc 31 Header Checksum > > >> >0b 64 64 09 Src IP > > >> >7f 00 00 62 Dst IP > > >> > > > >> >95 80 UDP Src Port =3D 38272 > > >> >0d af UDP Dst Port =3D 3503 > > >> >00 58 UDP Length > > >> >00 00 UDP Checksum > > >> > > > >> >00 01 LSP Ping Version Number =3D 1 > > >> >00 00 Must Be Zero > > >> >01 Message Type =3D MPLS Echo Request > > >> >05 Reply Mode =3D Reply Via a VPLS IPv4 UDP = Packet > > >> >00 Return Code > > >> >00 Return Subcode > > >> >00 04 00 01 Sender's Handle > > >> >00 00 00 61 Sequence Number > > >> >3f a7 5e 0c Timestamp Sent (seconds) > > >> >00 04 ba f0 Timestamp Sent (microseconds) > > >> >00 00 00 00 Timestamp Received (seconds) > > >> >00 00 00 00 Timestamp Received (microseconds) > > >> > > > >> >00 01 Type =3D Target FEC Stack > > >> >00 20 Length > > >> >00 0a Sub-Type =3D Hierarchical L2 Circuit ID > > >> >00 1c Length > > >> >00 00 07 d0 VC ID > > >> >00 05 Encapsulation Type =3D Ethernet > > >> >00 00 Must Be Zero > > >> >00 05 L2 Specific Sub-Type =3D Ethernet > > >> >00 10 Length > > >> >00 01 30 05 84 00 Target Ethernet MAC > > >> >00 00 > > >> >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > > >> > > > >> >00 00 > > >> > > > >> >00 03 Type =3D Pad > > >> >00 08 Length > > >> >02 Copy Pad TLV to Reply > > >> >44 45 41 44 Pad Data > > >> >42 45 45 > > >> > > > >> > > > >> > > > >> > > > >> >> b) What is the value of the smac3 in the TLV. Is it=20 > mandatory ?. > > >> >> Should the reply take the path using the smac3=20 > for lookup > > >> >> (for reply mode 5)? Pseudo Wire Connectivity=20 > verification ?. > > >> > > > >> >This is the MAC to which the reply should be sent. It is > > >included to > > >> >support implementations where the processing is distributed in > > >> >case the MAC > > >> >header is not passed along with the IP packet. > > >> > > > >> >Here is an internal debug dump of a reply to a similar VPLS > > >> >ping about to be > > >> >sent... > > >> > > > >> > > > >> >00 01 30 08 92 00 Next Hop Router MAC > > >> >00 01 30 05 84 00 Local (originating) Router MAC > > >> > > > >> > > > >> >88 47 Ethertype =3D MPLS > > >> >cb 00 10 ff Tunnel Label > > >> >8c 00 30 ff VC Label > > >> >00 00 e1 ff OAM Label > > >> > > > >> >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender > > >> >Ethernet MAC from > > >> >request) > > >> >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target > > >> >Ethernet MAC from > > >> >request) > > >> >08 00 Ethertype =3D IP > > >> > > > >> >45 IPv4 > > >> >00 TOS > > >> >00 78 Length > > >> >00 93 ID > > >> >00 00 Offset > > >> >ff TTL > > >> >11 protocol =3D UDP > > >> >cc 59 Header Checksum > > >> >0b 64 64 08 Src IP > > >> >7f 00 00 1c Dst IP > > >> > > > >> >0d af UDP Src Port =3D 3503 > > >> >95 80 UDP Dst Port =3D 38272 > > >> >00 64 UDP Length > > >> >00 00 UDP Checksum > > >> > > > >> >00 01 LSP Ping Version Number =3D 1 > > >> >00 00 Must Be Zero > > >> >02 Message Type =3D MPLS Echo Reply > > >> >05 Reply Mode =3D Reply Via a VPLS IPv4 UDP = Packet > > >> >00 Return Code > > >> >00 Return Subcode > > >> >00 05 00 01 Sender's Handle > > >> >00 00 00 1b Sequence Number > > >> >3f a7 62 be Timestamp Sent (seconds) > > >> >00 06 8f b0 Timestamp Sent (microseconds) > > >> >3f a7 56 45 Timestamp Received (seconds) > > >> >00 04 ba f0 Timestamp Received (microseconds) > > >> > > > >> >00 01 Type =3D Target FEC Stack > > >> >00 20 Length > > >> >00 0a Sub-Type =3D Hierarchical L2 Circuit ID > > >> >00 1c Length > > >> >00 00 07 d0 VC ID > > >> >00 05 Encapsulation Type =3D Ethernet > > >> >00 00 Must Be Zero > > >> >00 05 L2 Specific Sub-Type =3D Ethernet > > >> >00 10 Length > > >> >00 01 30 05 84 00 Target Ethernet MAC > > >> >00 00 > > >> >00 01 02 03 04 05 Sender Ethernet MAC > > >> >00 00 > > >> > > > >> >00 04 Type =3D Error Code > > >> >00 08 Length > > >> >00 0a Sub-Type =3D Hierarchical L2 Circuit ID > > >> >00 04 Length > > >> >00 01 Error Code =3D Replying router is the Egress > > >> >for the MAC > > >> >00 00 Must Be Zero > > >> > > > >> >00 03 Type =3D Pad > > >> >00 08 Length > > >> >02 Copy Pad TLV to Reply > > >> >44 45 41 44 Pad Data > > >> >42 45 45 > > >> > > > >> >In this example, when the reply is received at the originating > > >> >PE, the OAM label causes the packet to be processed at the > > >> PE and not > > >> >forwarded to the customer. > > >> > > >> Could you please explain/elaborate on how the TTL is > > >> treated in the aforementioned packets? Your packet dump does > > >> not show this. Specifically, what happens to the header + TTL > > >> as the packet traverses the MPLS network between the VPLS bridges > > >> as described in section 8.2.2 of your draft. > > >> > > >> >> c) Is there any relation between smac2 and smac3 ?. > > >> >> > > >> > > > >> >Normally they would be the same. > > >> > > > >> > > > >> > > > >> >> d) We have assumed that the dmac2 is either the mac of the > > >> >> target MTU/PE. This is because if the customer dmac is > > >> >> used the packet would show up at the customer. If the > > >> >> router alert is used the the packet would not go beyond > > >> >> the PE. So is this assumption correct ?. > > >> > > > >> >You need the OAM label to prevent the packet from reaching > > >> >customer devices. > > >> > > >> It should be pointed out that this extra label also adds the > > >> potential for the OAM packets being forwarded along ECMP=20 > paths that > > >> differ from those of the original data packets. I think you > > >> are making the assumption that the VC label is the only one > > >> used for load-share computation. This seems like a serious > > >> deficiency to me as it can result in false results. > > >> > > >> --Tom > > >> > > >> > > >> > > >> >Remember that if dmac2 is not known in the network, the > > >packet may be > > >> >flooded. It would then reach PEs other than the one > > >> >associated with dmac2. > > >> >The OAM label allows these switches to prevent the traffic > > >reaching a > > >> >customer. > > >> > > > >> > > > >> > > > >> >> > > >> >> e) pre-condition: > > >> >> To do a VPLS ping to verify customer MAC sitting at > > >> >> the remote end, we have to have a actual customer > > >> >> traffic flowing on > > >> >> the pseudo-wire, or at least some customer traffic has > > >> >> to be there > > >> >> within the 'L2 age out' time period. > > >> >> For VPLS ping to work, this is a pre-condition. > > >> >> > > >> >> Question is 'Is this a valid pre-condition ?', If > > >> yes, are users > > >> >> OK with this model of OAM ?. > > >> >> > > >> > > > >> >As stated above, if the MAC is unknown, the packet is to be > > >> >flooded as would > > >> >any normal packet. Therefore, the intent that this > > >> >pre-condition should not > > >> >be necessary. > > >> > > > >> > > > >> > > > >> >> > > >> >> thanks > > >> >> hongal > > >> >> > > >> > > > >> > > > >=20 >=20 >=20 From exim@www1.ietf.org Tue Nov 11 01:47:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08883 for ; Tue, 11 Nov 2003 01:47:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSIq-0006Sh-Je for l2vpn-archive@odin.ietf.org; Tue, 11 Nov 2003 01:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB6l4nv024835 for l2vpn-archive@odin.ietf.org; Tue, 11 Nov 2003 01:47:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSIq-0006SU-ED for l2vpn-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 01:47:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08879 for ; Tue, 11 Nov 2003 01:46:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJSIn-0006IV-00 for l2vpn-web-archive@ietf.org; Tue, 11 Nov 2003 01:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJSIm-0006IS-00 for l2vpn-web-archive@ietf.org; Tue, 11 Nov 2003 01:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSIn-0006Rp-1p; Tue, 11 Nov 2003 01:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJSIH-0006R2-07 for l2vpn@optimus.ietf.org; Tue, 11 Nov 2003 01:46:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08854 for ; Tue, 11 Nov 2003 01:46:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJSID-0006I1-00 for l2vpn@ietf.org; Tue, 11 Nov 2003 01:46:25 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJSIC-0006HK-00 for l2vpn@ietf.org; Tue, 11 Nov 2003 01:46:24 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 22:47:46 -0800 Received: from sajassi-w2k4.cisco.com (sjc-vpn4-1093.cisco.com [10.21.84.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAB6jhAu011517; Mon, 10 Nov 2003 22:45:45 -0800 (PST) Message-Id: <4.3.2.7.2.20031110223405.025f9428@airborne.cisco.com> X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 22:45:42 -0800 To: , , , , , , From: Ali Sajassi Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Cc: In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2DDE@i2km07-ukbr.domai n1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 11:26 AM 11/10/2003 +0000, neil.2.harrison@bt.com wrote: >Ali....I agree with what you say here. But have you noticed that you are >effectively contradicting your recent posting to the PWE3 list wrt (in >your view) not retaining the FCS in ethernet? That is, the ethernet FCS >*belongs* to the ethernet client and must be independent of whatever the >server layer is....which is as you correctly note below, ie we must have >layer (in this case OAM) independence. The fact that one may have to do a >linear update of the FCS on a link-connection basis does not alter this >fact. Indeed, from a G.805/809 functional arch perspective, the ethernet >FCS belongs to the client->server adaptation process and obviously applies >on all client layer ethernet link-connections (as provided by server layer >trails). In case of EVPL, do you consider service multiplexing field as part of the client data ? VLAN filed of the EVPL service is analogous to DLCI field of FR service. Yours, Ali >regards, Neil > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: 08 November 2003 03:56 > > To: tnadeau@cisco.com; 'Olen Stokes'; 'Thippanna Hongal'; > > marc.lasserre@riverstonenet.com; l2vpn@ietf.org > > Cc: pishwar@riverstonenet.com > > Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > > > > > > > There are other mechanisms being worked > > >on in the 802.11ad group at the IEEE for testing ENET segment OAM. > > >I recommend that we use the appropriate tools to test the appropriate > > >levels within the network instead of munging things together. > > > > Yes, Ethernet service layer OAM must be completely independent from > > transport layer OAM (e.g., an end to end VPLS service can > > have different > > transport layers - one network segment can be QinQ, another > > can be MPLS, > > and yet another can be L2TPv3). That is why in all the > > different standards > > groups such as ITU, MEF, and IEEE, the fundamental requirement is for > > Ethernet service layer OAM to be independent from transport layer > > OAM. Both ITU and MEF have produced some preliminary drafts > > that may of > > interest to those who want to explore this further. > > > > -Ali > > > > > > > --Tom > > > > > > > > > > > > > > > >Cheers, > > > >Olen > > > > > > > > > > > >> -----Original Message----- > > > >> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > >> Sent: Tuesday, November 04, 2003 11:38 AM > > > >> To: 'Olen Stokes'; 'Thippanna Hongal'; > > > >> marc.lasserre@riverstonenet.com; > > > >> l2vpn@ietf.org > > > >> Cc: pishwar@riverstonenet.com > > > >> Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > >> > > > >> > > > >> > > > >> One question and one comment below. > > > >> > > > >> >-----Original Message----- > > > >> >From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > > > >> >Behalf Of Olen Stokes > > > >> >Sent: Tuesday, November 04, 2003 11:04 AM > > > >> >To: 'Thippanna Hongal'; Olen Stokes; > > > >> >marc.lasserre@riverstonenet.com; l2vpn@ietf.org > > > >> >Cc: pishwar@riverstonenet.com > > > >> >Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > >> > > > > >> > > > > >> > > > > >> >Please see in line.... > > > >> > > > > >> > > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Thippanna Hongal [mailto:hongal@riverstonenet.com] > > > >> >> Sent: Friday, October 31, 2003 6:08 PM > > > >> >> To: ostokes@extremenetworks.com; > > marc.lasserre@riverstonenet.com; > > > >> >> l2vpn@ietf.org > > > >> >> Cc: pishwar@riverstonenet.com > > > >> >> Subject: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt > > > >> >> > > > >> >> > > > >> >> hi Stokes, > > > >> >> > > > >> >> Below is the packet format on the wire as we understand from > > > >> >> the draft. > > > >> >> We have a few questins on this. > > > >> >> > > > >> >> Packet for the PING > > > >> >> > > > >> >> dmac1 (Next hop router) > > > >> >> smac1 (Of the originating router) > > > >> >> Etype - 8847 > > > >> >> Transport label -|__________________ Pseudo wire > > > >> >> Vc label ------| > > > >> >> dmac2 (of the target mtu/pe to which the ping is targeted) > > > >> >> smac2 (of the originating router (PE/MTU)) > > > >> >> etype (IP 0x800) > > > >> >> ... > > > >> >> Mac TLV > > > >> >> smac3 -- (??) > > > >> >> dmac3 -- (customer's mac/spoke's mac to be pinged). > > > >> >> > > > >> >> a) Is the above representation correct? > > > >> >> > > > >> >Here is an internal debug dump of a VPLS ping about to > > be sent... > > > >> > > > > >> > > > > >> >00 01 30 05 84 00 Next Hop Router MAC > > > >> >00 01 30 08 92 00 Local (originating) Router MAC > > > >> > > > > >> >88 47 Ethertype = MPLS > > > >> >cb 00 10 ff Tunnel Label > > > >> >8c 00 40 ff VC Label > > > >> >00 00 e1 ff OAM Label > > > >> > > > > >> >00 01 30 05 84 00 Remote Spoke/Core MAC being pinged > > > >> >00 01 02 03 04 05 Local Customer MAC > > > >> >08 00 Ethertype = IP > > > >> > > > > >> >45 IPv4 > > > >> >00 TOS > > > >> >00 6c Length > > > >> >00 80 ID > > > >> >00 00 Offset > > > >> >ff TTL > > > >> >11 protocol = UDP > > > >> >cc 31 Header Checksum > > > >> >0b 64 64 09 Src IP > > > >> >7f 00 00 62 Dst IP > > > >> > > > > >> >95 80 UDP Src Port = 38272 > > > >> >0d af UDP Dst Port = 3503 > > > >> >00 58 UDP Length > > > >> >00 00 UDP Checksum > > > >> > > > > >> >00 01 LSP Ping Version Number = 1 > > > >> >00 00 Must Be Zero > > > >> >01 Message Type = MPLS Echo Request > > > >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > > > >> >00 Return Code > > > >> >00 Return Subcode > > > >> >00 04 00 01 Sender's Handle > > > >> >00 00 00 61 Sequence Number > > > >> >3f a7 5e 0c Timestamp Sent (seconds) > > > >> >00 04 ba f0 Timestamp Sent (microseconds) > > > >> >00 00 00 00 Timestamp Received (seconds) > > > >> >00 00 00 00 Timestamp Received (microseconds) > > > >> > > > > >> >00 01 Type = Target FEC Stack > > > >> >00 20 Length > > > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > > > >> >00 1c Length > > > >> >00 00 07 d0 VC ID > > > >> >00 05 Encapsulation Type = Ethernet > > > >> >00 00 Must Be Zero > > > >> >00 05 L2 Specific Sub-Type = Ethernet > > > >> >00 10 Length > > > >> >00 01 30 05 84 00 Target Ethernet MAC > > > >> >00 00 > > > >> >00 01 02 03 04 05 Sender Ethernet MAC (local customer MAC) > > > >> > > > > >> >00 00 > > > >> > > > > >> >00 03 Type = Pad > > > >> >00 08 Length > > > >> >02 Copy Pad TLV to Reply > > > >> >44 45 41 44 Pad Data > > > >> >42 45 45 > > > >> > > > > >> > > > > >> > > > > >> > > > > >> >> b) What is the value of the smac3 in the TLV. Is it > > mandatory ?. > > > >> >> Should the reply take the path using the smac3 > > for lookup > > > >> >> (for reply mode 5)? Pseudo Wire Connectivity > > verification ?. > > > >> > > > > >> >This is the MAC to which the reply should be sent. It is > > > >included to > > > >> >support implementations where the processing is distributed in > > > >> >case the MAC > > > >> >header is not passed along with the IP packet. > > > >> > > > > >> >Here is an internal debug dump of a reply to a similar VPLS > > > >> >ping about to be > > > >> >sent... > > > >> > > > > >> > > > > >> >00 01 30 08 92 00 Next Hop Router MAC > > > >> >00 01 30 05 84 00 Local (originating) Router MAC > > > >> > > > > >> > > > > >> >88 47 Ethertype = MPLS > > > >> >cb 00 10 ff Tunnel Label > > > >> >8c 00 30 ff VC Label > > > >> >00 00 e1 ff OAM Label > > > >> > > > > >> >00 01 02 03 04 05 Remote Spoke/Core/Customer MAC (Sender > > > >> >Ethernet MAC from > > > >> >request) > > > >> >00 01 30 05 84 00 Local Spoke/Core/Customer MAC (Target > > > >> >Ethernet MAC from > > > >> >request) > > > >> >08 00 Ethertype = IP > > > >> > > > > >> >45 IPv4 > > > >> >00 TOS > > > >> >00 78 Length > > > >> >00 93 ID > > > >> >00 00 Offset > > > >> >ff TTL > > > >> >11 protocol = UDP > > > >> >cc 59 Header Checksum > > > >> >0b 64 64 08 Src IP > > > >> >7f 00 00 1c Dst IP > > > >> > > > > >> >0d af UDP Src Port = 3503 > > > >> >95 80 UDP Dst Port = 38272 > > > >> >00 64 UDP Length > > > >> >00 00 UDP Checksum > > > >> > > > > >> >00 01 LSP Ping Version Number = 1 > > > >> >00 00 Must Be Zero > > > >> >02 Message Type = MPLS Echo Reply > > > >> >05 Reply Mode = Reply Via a VPLS IPv4 UDP Packet > > > >> >00 Return Code > > > >> >00 Return Subcode > > > >> >00 05 00 01 Sender's Handle > > > >> >00 00 00 1b Sequence Number > > > >> >3f a7 62 be Timestamp Sent (seconds) > > > >> >00 06 8f b0 Timestamp Sent (microseconds) > > > >> >3f a7 56 45 Timestamp Received (seconds) > > > >> >00 04 ba f0 Timestamp Received (microseconds) > > > >> > > > > >> >00 01 Type = Target FEC Stack > > > >> >00 20 Length > > > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > > > >> >00 1c Length > > > >> >00 00 07 d0 VC ID > > > >> >00 05 Encapsulation Type = Ethernet > > > >> >00 00 Must Be Zero > > > >> >00 05 L2 Specific Sub-Type = Ethernet > > > >> >00 10 Length > > > >> >00 01 30 05 84 00 Target Ethernet MAC > > > >> >00 00 > > > >> >00 01 02 03 04 05 Sender Ethernet MAC > > > >> >00 00 > > > >> > > > > >> >00 04 Type = Error Code > > > >> >00 08 Length > > > >> >00 0a Sub-Type = Hierarchical L2 Circuit ID > > > >> >00 04 Length > > > >> >00 01 Error Code = Replying router is the Egress > > > >> >for the MAC > > > >> >00 00 Must Be Zero > > > >> > > > > >> >00 03 Type = Pad > > > >> >00 08 Length > > > >> >02 Copy Pad TLV to Reply > > > >> >44 45 41 44 Pad Data > > > >> >42 45 45 > > > >> > > > > >> >In this example, when the reply is received at the originating > > > >> >PE, the OAM label causes the packet to be processed at the > > > >> PE and not > > > >> >forwarded to the customer. > > > >> > > > >> Could you please explain/elaborate on how the TTL is > > > >> treated in the aforementioned packets? Your packet dump does > > > >> not show this. Specifically, what happens to the header + TTL > > > >> as the packet traverses the MPLS network between the VPLS bridges > > > >> as described in section 8.2.2 of your draft. > > > >> > > > >> >> c) Is there any relation between smac2 and smac3 ?. > > > >> >> > > > >> > > > > >> >Normally they would be the same. > > > >> > > > > >> > > > > >> > > > > >> >> d) We have assumed that the dmac2 is either the mac of the > > > >> >> target MTU/PE. This is because if the customer dmac is > > > >> >> used the packet would show up at the customer. If the > > > >> >> router alert is used the the packet would not go beyond > > > >> >> the PE. So is this assumption correct ?. > > > >> > > > > >> >You need the OAM label to prevent the packet from reaching > > > >> >customer devices. > > > >> > > > >> It should be pointed out that this extra label also adds the > > > >> potential for the OAM packets being forwarded along ECMP > > paths that > > > >> differ from those of the original data packets. I think you > > > >> are making the assumption that the VC label is the only one > > > >> used for load-share computation. This seems like a serious > > > >> deficiency to me as it can result in false results. > > > >> > > > >> --Tom > > > >> > > > >> > > > >> > > > >> >Remember that if dmac2 is not known in the network, the > > > >packet may be > > > >> >flooded. It would then reach PEs other than the one > > > >> >associated with dmac2. > > > >> >The OAM label allows these switches to prevent the traffic > > > >reaching a > > > >> >customer. > > > >> > > > > >> > > > > >> > > > > >> >> > > > >> >> e) pre-condition: > > > >> >> To do a VPLS ping to verify customer MAC sitting at > > > >> >> the remote end, we have to have a actual customer > > > >> >> traffic flowing on > > > >> >> the pseudo-wire, or at least some customer traffic has > > > >> >> to be there > > > >> >> within the 'L2 age out' time period. > > > >> >> For VPLS ping to work, this is a pre-condition. > > > >> >> > > > >> >> Question is 'Is this a valid pre-condition ?', If > > > >> yes, are users > > > >> >> OK with this model of OAM ?. > > > >> >> > > > >> > > > > >> >As stated above, if the MAC is unknown, the packet is to be > > > >> >flooded as would > > > >> >any normal packet. Therefore, the intent that this > > > >> >pre-condition should not > > > >> >be necessary. > > > >> > > > > >> > > > > >> > > > > >> >> > > > >> >> thanks > > > >> >> hongal > > > >> >> > > > >> > > > > >> > > > > > > > > > > From exim@www1.ietf.org Tue Nov 11 06:08:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26991 for ; Tue, 11 Nov 2003 06:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJWNR-0003gw-8c for l2vpn-archive@odin.ietf.org; Tue, 11 Nov 2003 06:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABB851G014161 for l2vpn-archive@odin.ietf.org; Tue, 11 Nov 2003 06:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJWNR-0003gB-2U for l2vpn-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 06:08:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26968 for ; Tue, 11 Nov 2003 06:07:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJWNN-0001EF-00 for l2vpn-web-archive@ietf.org; Tue, 11 Nov 2003 06:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJWNM-0001EC-00 for l2vpn-web-archive@ietf.org; Tue, 11 Nov 2003 06:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJWNN-0003fS-O4; Tue, 11 Nov 2003 06:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJWNA-0003dJ-4G for l2vpn@optimus.ietf.org; Tue, 11 Nov 2003 06:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26963 for ; Tue, 11 Nov 2003 06:07:34 -0500 (EST) From: neil.2.harrison@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJWN6-0001E4-00 for l2vpn@ietf.org; Tue, 11 Nov 2003 06:07:44 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150] helo=i2kc02-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AJWN5-0001Dj-01 for l2vpn@ietf.org; Tue, 11 Nov 2003 06:07:43 -0500 Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by i2kc02-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:07:11 +0000 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Nov 2003 11:07:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt Date: Tue, 11 Nov 2003 11:07:11 -0000 Message-ID: <0536FC9B908BEC4597EE721BE6A3538904EF2DF9@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt thread-index: AcOoH3YVgnqDMLFGTJGAeBmmX9bvyAAJHXVg To: , , , , , Cc: X-OriginalArrivalTime: 11 Nov 2003 11:07:11.0395 (UTC) FILETIME=[F472DF30:01C3A843] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ali Sajassi wrote 11 November 2003 06:46 >=20 > At 11:26 AM 11/10/2003 +0000, neil.2.harrison@bt.com wrote: > >Ali....I agree with what you say here. But have you noticed=20 > that you are=20 > >effectively contradicting your recent posting to the PWE3=20 > list wrt (in=20 > >your view) not retaining the FCS in ethernet? That is, the=20 > ethernet FCS=20 > >*belongs* to the ethernet client and must be independent of=20 > whatever the=20 > >server layer is....which is as you correctly note below, ie=20 > we must have=20 > >layer (in this case OAM) independence. The fact that one=20 > may have to do a=20 > >linear update of the FCS on a link-connection basis does not=20 > alter this=20 > >fact. Indeed, from a G.805/809 functional arch perspective,=20 > the ethernet=20 > >FCS belongs to the client->server adaptation process and=20 > obviously applies=20 > >on all client layer ethernet link-connections (as provided=20 > by server layer=20 > >trails). >=20 > In case of EVPL, do you consider service multiplexing field=20 > as part of the=20 > client data ? VLAN filed of the EVPL service is analogous to=20 > DLCI field of=20 > FR service. >=20 > Yours, > Ali Ali, What do you mean by a 'service muxing field'....the VLAN ID? The = key issue here is that some of the client O/H belongs to the trail = termination function and some belongs to the client/server adaptation = function. If there is a FCS present and it covers the link-connection = ID field then this belongs to the client/server adpatation function, and = so must have a linear update for each client/server link-connection ID = change. If there is a FCS present and it does not cover the = link-connection ID then IMO it should belong to the trail term function = (and is obviously not updated on each link connection change). However, if you want a definitive answer to this I would ask someone = like Maarten Vissers....and I'll check internally with my func experts. regards, Neil From exim@www1.ietf.org Wed Nov 12 17:46:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14058 for ; Wed, 12 Nov 2003 17:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3kQ-0006C5-Az for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 17:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMk24h023791 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3kP-0006BU-Vi for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:46:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14007 for ; Wed, 12 Nov 2003 17:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3kN-0000HG-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 17:45:59 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AK3j3-00009c-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 17:44:37 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AK3U2-0006aO-U5 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 17:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3Tx-0004Ox-Dm; Wed, 12 Nov 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3TM-0004NE-Kf for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 17:28:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13374 for ; Wed, 12 Nov 2003 17:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3TJ-0007mW-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 17:28:21 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AK3T6-0007kf-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 17:28:08 -0500 Received: from default.comcast.net (dyn130-128.ietf58.ietf.org[130.129.130.128]) by comcast.net (sccrmhc11) with SMTP id <2003111222271701100qiv1se> (Authid: andymalis@comcast.net); Wed, 12 Nov 2003 22:27:17 +0000 Message-Id: <6.0.0.22.2.20031112172638.02c10970@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 12 Nov 2003 17:26:41 -0500 To: l2vpn@ietf.org From: "Andrew G. Malis" Subject: ARP mediation to working group draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Based on Vach's comments in the L2VPN meeting, I would like to request that draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll also get it back into the I-D directory. :-) Thanks, Andy From exim@www1.ietf.org Wed Nov 12 17:53:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14330 for ; Wed, 12 Nov 2003 17:53:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3rD-0006p0-C4 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 17:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMr3W8026216 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 17:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3rD-0006ol-8a for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:53:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14315 for ; Wed, 12 Nov 2003 17:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3rA-0000NP-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 17:53:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK3rA-0000NM-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 17:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3rB-0006nL-Di; Wed, 12 Nov 2003 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2yH-0001wY-ML for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 16:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11935 for ; Wed, 12 Nov 2003 16:56:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2yF-0007AF-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 16:56:15 -0500 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1AK2yE-00079a-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 16:56:14 -0500 Received: from default.comcast.net (dyn132-177.ietf58.ietf.org[130.129.132.177]) by comcast.net (rwcrmhc13) with SMTP id <2003111221554201500i4907e> (Authid: andymalis@comcast.net); Wed, 12 Nov 2003 21:55:42 +0000 Message-Id: <6.0.0.22.2.20031112164342.0336d708@po1.vivacenetworks.com> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 12 Nov 2003 16:54:41 -0500 To: l2vpn@ietf.org From: "Andrew G. Malis" Subject: ARP mediation to working group draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Based on Vach's comments in the L2VPN meeting, I would like to request that draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll also get it back into the I-D directory. :-) Thanks, Andy From exim@www1.ietf.org Wed Nov 12 18:23:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16820 for ; Wed, 12 Nov 2003 18:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4KG-0000nJ-HR for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 18:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACNN4VQ003047 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 18:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4KG-0000n4-8V for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 18:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16807 for ; Wed, 12 Nov 2003 18:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4KD-0000sA-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 18:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK4KC-0000s7-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 18:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4KD-0000mC-8u; Wed, 12 Nov 2003 18:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK4K3-0000lq-0L for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 18:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16798 for ; Wed, 12 Nov 2003 18:22:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK4Jz-0000rj-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 18:22:47 -0500 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1AK4Jz-0000rg-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 18:22:47 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id hACNMjsw016290; Wed, 12 Nov 2003 18:22:46 -0500 (EST) Message-ID: <3FB2C0AB.FEAF800@alcatel.com> Date: Wed, 12 Nov 2003 18:22:19 -0500 From: Mustapha Aissaoui Organization: Alcatel Networks Corporaton X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Andrew G. Malis" CC: l2vpn@ietf.org Subject: Re: ARP mediation to working group draft References: <6.0.0.22.2.20031112164342.0336d708@po1.vivacenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andy, I have the following comment on this draft. Section 4.2 does not seem to be right. An ethernet attached CE cannot discover the IP address of the remote CE using an ARP request since it does not know this very IP address. Instead, it can make its own IP address known to the PE by broadcasting a gratuitous ARP. The PE can also make the learned IP address of the remote CE known by also generating a gratuitous ARP associating the remote IP address with its own MAC address. Mustapha. ------------- "Andrew G. Malis" wrote: > > Based on Vach's comments in the L2VPN meeting, I would like to request that > draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll > also get it back into the I-D directory. :-) > > Thanks, > Andy From exim@www1.ietf.org Wed Nov 12 19:18:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19002 for ; Wed, 12 Nov 2003 19:18:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5BW-00059u-4E for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 19:18:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD0I67L019824 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 19:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5BV-00059f-Tz for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 19:18:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18990 for ; Wed, 12 Nov 2003 19:17:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5BU-0001mj-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 19:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK5BU-0001mg-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 19:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5BR-00058H-DG; Wed, 12 Nov 2003 19:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5BK-000585-Nf for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 19:17:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18971 for ; Wed, 12 Nov 2003 19:17:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5BJ-0001mY-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 19:17:53 -0500 Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 1AK5BI-0001ll-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 19:17:52 -0500 Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 01:54:31 +0200 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 01:54:33 +0200 Message-ID: From: Sasha Vainshtein To: "'Andrew G. Malis'" , l2vpn@ietf.org Subject: RE: ARP mediation to working group draft Date: Thu, 13 Nov 2003 01:54:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-8" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I concur. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Thursday, November 13, 2003 12:27 AM > To: l2vpn@ietf.org > Subject: ARP mediation to working group draft > > > Based on Vach's comments in the L2VPN meeting, I would like > to request that > draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG > draft. That'll > also get it back into the I-D directory. :-) > > Thanks, > Andy > > From exim@www1.ietf.org Wed Nov 12 19:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19169 for ; Wed, 12 Nov 2003 19:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5HI-0005Li-7g for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 19:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD0O4hK020556 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 19:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5HI-0005LT-2h for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 19:24:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19158 for ; Wed, 12 Nov 2003 19:23:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5HG-0001r9-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 19:24:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK5HG-0001r6-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 19:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5HE-0005Kn-Nc; Wed, 12 Nov 2003 19:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK5H2-0005Jw-Rf for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 19:23:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19137 for ; Wed, 12 Nov 2003 19:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK5H1-0001qd-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 19:23:47 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AK5H0-0001q1-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 19:23:46 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAD0N8X18395 for ; Wed, 12 Nov 2003 19:23:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 19:23:09 -0500 Message-ID: From: "Hamid Ould-Brahim" To: l2vpn@ietf.org Subject: distributed vpls... Date: Wed, 12 Nov 2003 19:23:08 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach, I actually missed your question in the meeting on distributed VPLS issue. Would you mind sending it again to the list? Thanks. Hamid. From exim@www1.ietf.org Wed Nov 12 21:30:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22948 for ; Wed, 12 Nov 2003 21:30:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7FH-0003aD-L2 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 21:30:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD2U7OF013767 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 21:30:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7FH-0003Zy-FU for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 21:30:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22945 for ; Wed, 12 Nov 2003 21:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7FE-0003ZN-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 21:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7FE-0003ZK-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 21:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7FB-0003ZG-T3; Wed, 12 Nov 2003 21:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Eh-0003Yj-D9 for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 21:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22936 for ; Wed, 12 Nov 2003 21:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7Ee-0003Z4-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 21:29:28 -0500 Received: from mdmail.ciena.com ([63.118.39.25] helo=mdmxb01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 1AK7Ee-0003Z0-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 21:29:28 -0500 Received: by mdmxb01.ciena.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 21:29:21 -0500 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB06D44D4@w2kmaexg01.ciena.com> From: "Shah, Himanshu" To: "'Mustapha Aissaoui'" , "Andrew G. Malis" Cc: l2vpn@ietf.org Subject: RE: ARP mediation to working group draft Date: Wed, 12 Nov 2003 21:29:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , CE does not post ARP request until he knows the IP address of the remote CE. Hence, the draft says that during discovery process, Group addressed IP frames should be propagated. For example, OSPF hello packets (addressed to multicast IP address) are forwarded to remote CE. This allows Ethernet CE to learn his neighbor's IP address. Once IP address is known, Ethernet CE would do ARP to that IP address to initiate database exchange. Hope this clears up the importance of allowing multicast traffic flow during CE discovery phase. /himanshu -----Original Message----- From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] Sent: Wednesday, November 12, 2003 6:22 PM To: Andrew G. Malis Cc: l2vpn@ietf.org Subject: Re: ARP mediation to working group draft Andy, I have the following comment on this draft. Section 4.2 does not seem to be right. An ethernet attached CE cannot discover the IP address of the remote CE using an ARP request since it does not know this very IP address. Instead, it can make its own IP address known to the PE by broadcasting a gratuitous ARP. The PE can also make the learned IP address of the remote CE known by also generating a gratuitous ARP associating the remote IP address with its own MAC address. Mustapha. ------------- "Andrew G. Malis" wrote: > > Based on Vach's comments in the L2VPN meeting, I would like to request that > draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll > also get it back into the I-D directory. :-) > > Thanks, > Andy From exim@www1.ietf.org Wed Nov 12 21:40:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23121 for ; Wed, 12 Nov 2003 21:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Ox-0004Jt-CD for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 21:40:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD2e7dx016599 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 21:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Ow-0004JW-BG for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 21:40:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23107 for ; Wed, 12 Nov 2003 21:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7Ot-0003fx-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 21:40:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7Ot-0003fu-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 21:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7Os-0004I4-KB; Wed, 12 Nov 2003 21:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7OL-0004Dh-CM for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 21:39:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23080 for ; Wed, 12 Nov 2003 21:39:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7OI-0003fN-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 21:39:26 -0500 Received: from mdmail.ciena.com ([63.118.39.25] helo=mdmxb01.ciena.com) by ietf-mx with esmtp (Exim 4.12) id 1AK7OI-0003fK-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 21:39:26 -0500 Received: by mdmxb01.ciena.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 Nov 2003 21:39:26 -0500 Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB06D44D5@w2kmaexg01.ciena.com> From: "Shah, Himanshu" To: "'l2vpn@ietf.org'" Subject: IPLS as WG Date: Wed, 12 Nov 2003 21:39:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Just so that it is clear (some people asked me after the meeting), draft-shah-l2vpn-ipls-02.txt has been accepted as working group doc. Due to draft submission blackout, draft-ietf-l2vpn-ipls-00.txt has not been posted on the web. I will follow it up after the blackout period to make sure that draft is available. thanks, himanshu From exim@www1.ietf.org Wed Nov 12 22:39:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25198 for ; Wed, 12 Nov 2003 22:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8Jz-0008D2-Mr for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 22:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3d3hD031550 for l2vpn-archive@odin.ietf.org; Wed, 12 Nov 2003 22:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8Jz-0008Cn-IS for l2vpn-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25154 for ; Wed, 12 Nov 2003 22:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8Jw-0004Ye-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 22:39:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK8Jv-0004Yb-00 for l2vpn-web-archive@ietf.org; Wed, 12 Nov 2003 22:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8Jx-0008CH-0u; Wed, 12 Nov 2003 22:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8J7-00089N-2D for l2vpn@optimus.ietf.org; Wed, 12 Nov 2003 22:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25138 for ; Wed, 12 Nov 2003 22:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8J3-0004YD-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 22:38:05 -0500 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1AK8J2-0004YA-00 for l2vpn@ietf.org; Wed, 12 Nov 2003 22:38:04 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id hAD3c2Wj026383; Wed, 12 Nov 2003 22:38:03 -0500 (EST) Message-ID: <3FB2FC7F.D1EB5702@alcatel.com> Date: Wed, 12 Nov 2003 22:37:35 -0500 From: Mustapha Aissaoui Organization: Alcatel Networks Corporaton X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shah, Himanshu" CC: Andy Malis , l2vpn@ietf.org Subject: Re: ARP mediation to working group draft References: <8162DD929D7AD24CAD3FC5317CE41FB06D44D4@w2kmaexg01.ciena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Himanshu, see below. Mustapha. --------- "Shah, Himanshu" wrote: > > CE does not post ARP request until he knows > the IP address of the remote CE. Hence, the draft Well this is not what Section 4.2 says. I guess what you need to explain in this section is that the PE will learn the IP address of the Ethernet attached CE when it receives the ARP message from this CE. But the Ethernet attached CE is generating this ARP message not to learn the remote CE IP address, which it has already learned, but the MAC address to associate with it. > says that during discovery process, Group addressed > IP frames should be propagated. > > For example, OSPF hello packets (addressed to multicast > IP address) are forwarded to remote CE. This allows > Ethernet CE to learn his neighbor's IP address. Once > IP address is known, Ethernet CE would do ARP to that > IP address to initiate database exchange. > > Hope this clears up the importance of allowing multicast > traffic flow during CE discovery phase. > > /himanshu > > -----Original Message----- > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > Sent: Wednesday, November 12, 2003 6:22 PM > To: Andrew G. Malis > Cc: l2vpn@ietf.org > Subject: Re: ARP mediation to working group draft > > Andy, > I have the following comment on this draft. Section 4.2 does not > seem to be right. An ethernet attached CE cannot discover the IP > address of the remote CE using an ARP request since it does not know > this very IP address. Instead, it can make its own IP address known > to the PE by broadcasting a gratuitous ARP. The PE can also make the > learned IP address of the remote CE known by also generating a > gratuitous ARP associating the remote IP address with its own MAC > address. > > Mustapha. > ------------- > "Andrew G. Malis" wrote: > > > > Based on Vach's comments in the L2VPN meeting, I would like to request that > > draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll > > also get it back into the I-D directory. :-) > > > > Thanks, > > Andy From exim@www1.ietf.org Thu Nov 13 00:59:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29883 for ; Thu, 13 Nov 2003 00:59:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAVS-00083F-Us for l2vpn-archive@odin.ietf.org; Thu, 13 Nov 2003 00:59:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD5x2ps030943 for l2vpn-archive@odin.ietf.org; Thu, 13 Nov 2003 00:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAVS-000830-QI for l2vpn-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 00:59:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29874 for ; Thu, 13 Nov 2003 00:58:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKAVP-0006fQ-00 for l2vpn-web-archive@ietf.org; Thu, 13 Nov 2003 00:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKAVP-0006fN-00 for l2vpn-web-archive@ietf.org; Thu, 13 Nov 2003 00:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAVQ-00082U-M3; Thu, 13 Nov 2003 00:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKAV1-00081p-7u for l2vpn@optimus.ietf.org; Thu, 13 Nov 2003 00:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29871 for ; Thu, 13 Nov 2003 00:58:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKAUy-0006fG-00 for l2vpn@ietf.org; Thu, 13 Nov 2003 00:58:32 -0500 Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx with esmtp (Exim 4.12) id 1AKAUx-0006ej-00 for l2vpn@ietf.org; Thu, 13 Nov 2003 00:58:31 -0500 Received: from default.comcast.net (dyn130-128.ietf58.ietf.org[130.129.130.128]) by comcast.net (rwcrmhc11) with SMTP id <2003111305580101300elbqre> (Authid: andymalis@comcast.net); Thu, 13 Nov 2003 05:58:01 +0000 Message-Id: <6.0.0.22.2.20031113005531.02f08108@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 13 Nov 2003 00:57:31 -0500 To: Mustapha Aissaoui From: "Andrew G. Malis" Subject: Re: ARP mediation to working group draft Cc: "Shah, Himanshu" , Andy Malis , l2vpn@ietf.org In-Reply-To: <3FB2FC7F.D1EB5702@alcatel.com> References: <8162DD929D7AD24CAD3FC5317CE41FB06D44D4@w2kmaexg01.ciena.com> <3FB2FC7F.D1EB5702@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mustapha, Once this is a working group draft, we'll make sure this point is clarified. Thanks, Andy ----------- At 11/12/2003 10:37 PM -0500, Mustapha Aissaoui wrote: >Himanshu, >see below. > >Mustapha. >--------- >"Shah, Himanshu" wrote: > > > > CE does not post ARP request until he knows > > the IP address of the remote CE. Hence, the draft > >Well this is not what Section 4.2 says. I guess what you need to >explain in this section is that the PE will learn the IP address of >the Ethernet attached CE when it receives the ARP message from this >CE. But the Ethernet attached CE is generating this ARP message not >to learn the remote CE IP address, which it has already learned, but >the MAC address to associate with it. > > > says that during discovery process, Group addressed > > IP frames should be propagated. > > > > For example, OSPF hello packets (addressed to multicast > > IP address) are forwarded to remote CE. This allows > > Ethernet CE to learn his neighbor's IP address. Once > > IP address is known, Ethernet CE would do ARP to that > > IP address to initiate database exchange. > > > > Hope this clears up the importance of allowing multicast > > traffic flow during CE discovery phase. > > > > /himanshu > > > > -----Original Message----- > > From: Mustapha Aissaoui [mailto:mustapha.aissaoui@alcatel.com] > > Sent: Wednesday, November 12, 2003 6:22 PM > > To: Andrew G. Malis > > Cc: l2vpn@ietf.org > > Subject: Re: ARP mediation to working group draft > > > > Andy, > > I have the following comment on this draft. Section 4.2 does not > > seem to be right. An ethernet attached CE cannot discover the IP > > address of the remote CE using an ARP request since it does not know > > this very IP address. Instead, it can make its own IP address known > > to the PE by broadcasting a gratuitous ARP. The PE can also make the > > learned IP address of the remote CE known by also generating a > > gratuitous ARP associating the remote IP address with its own MAC > > address. > > > > Mustapha. > > ------------- > > "Andrew G. Malis" wrote: > > > > > > Based on Vach's comments in the L2VPN meeting, I would like to > request that > > > draft-shah-ppvpn-arp-mediation-03.txt become a l2vpn WG draft. That'll > > > also get it back into the I-D directory. :-) > > > > > > Thanks, > > > Andy From exim@www1.ietf.org Thu Nov 13 12:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10776 for ; Thu, 13 Nov 2003 12:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLfR-00005Z-Ec for l2vpn-archive@odin.ietf.org; Thu, 13 Nov 2003 12:54:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADHs5M6000337 for l2vpn-archive@odin.ietf.org; Thu, 13 Nov 2003 12:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLfR-00005M-8G for l2vpn-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 12:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10766 for ; Thu, 13 Nov 2003 12:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLfP-0001v3-00 for l2vpn-web-archive@ietf.org; Thu, 13 Nov 2003 12:54:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKLfP-0001v0-00 for l2vpn-web-archive@ietf.org; Thu, 13 Nov 2003 12:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLfN-0008WP-5K; Thu, 13 Nov 2003 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLf5-0008W6-KY for l2vpn@optimus.ietf.org; Thu, 13 Nov 2003 12:53:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10754 for ; Thu, 13 Nov 2003 12:53:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLf3-0001uq-00 for l2vpn@ietf.org; Thu, 13 Nov 2003 12:53:41 -0500 Received: from web109.biz.mail.yahoo.com ([216.136.174.219]) by ietf-mx with smtp (Exim 4.12) id 1AKLf3-0001un-00 for l2vpn@ietf.org; Thu, 13 Nov 2003 12:53:41 -0500 Message-ID: <20031113175340.87803.qmail@web109.biz.mail.yahoo.com> Received: from [130.129.128.108] by web109.biz.mail.yahoo.com via HTTP; Thu, 13 Nov 2003 09:53:40 PST Date: Thu, 13 Nov 2003 09:53:40 -0800 (PST) From: Rick Wilder Subject: RE: ARP mediation to working group draft To: l2vpn@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , There is clearly interest in this document. This starts a 3 week comment period on making this a WG document. Barring any new input to the contrary, we'll then rename it and give a permament home. Rick --- Sasha Vainshtein wrote: > I concur. > > ---------------------------------------------------------------------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > > > -----Original Message----- > > From: Andrew G. Malis > [mailto:andymalis@comcast.net] > > Sent: Thursday, November 13, 2003 12:27 AM > > To: l2vpn@ietf.org > > Subject: ARP mediation to working group draft > > > > > > Based on Vach's comments in the L2VPN meeting, I > would like > > to request that > > draft-shah-ppvpn-arp-mediation-03.txt become a > l2vpn WG > > draft. That'll > > also get it back into the I-D directory. :-) > > > > Thanks, > > Andy > > > > > From exim@www1.ietf.org Fri Nov 14 15:30:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28399 for ; Fri, 14 Nov 2003 15:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkZx-0006OD-VG for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 15:30:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEKU5Bi024557 for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 15:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkZx-0006O0-Hw for l2vpn-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 15:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28393 for ; Fri, 14 Nov 2003 15:29:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkZw-0003qR-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 15:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKkZv-0003qN-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 15:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkZt-0006NM-UM; Fri, 14 Nov 2003 15:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkYv-0006Lt-JJ for l2vpn@optimus.ietf.org; Fri, 14 Nov 2003 15:29:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28365 for ; Fri, 14 Nov 2003 15:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkYu-0003pe-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 15:29:00 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1AKkYt-0003pa-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 15:28:59 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 12:28:27 -0800 Reply-To: From: "Vach Kompella" To: "'Hamid Ould-Brahim'" , Subject: RE: distributed vpls... Date: Fri, 14 Nov 2003 12:26:24 -0800 Organization: Alcatel USA Message-ID: <01b601c3aaed$940766f0$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Nov 2003 20:28:27.0885 (UTC) FILETIME=[DC70B1D0:01C3AAED] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think the section on distributed VPLS in draft-ietf-l2vpn-signaling is not required. -Vach=20 > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On=20 > Behalf Of Hamid Ould-Brahim > Sent: Wednesday, November 12, 2003 4:23 PM > To: l2vpn@ietf.org > Subject: distributed vpls... >=20 >=20 > Vach, >=20 > I actually missed your question in the meeting on distributed=20 > VPLS issue. =20 >=20 > Would you mind sending it again to the list? >=20 > Thanks. > Hamid. >=20 From exim@www1.ietf.org Fri Nov 14 15:32:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28554 for ; Fri, 14 Nov 2003 15:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkbr-0006W2-1w for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 15:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEKW3sA025040 for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 15:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkbq-0006Vn-Tu for l2vpn-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 15:32:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28523 for ; Fri, 14 Nov 2003 15:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkbp-0003vK-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 15:32:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKkbp-0003vD-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 15:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkbp-0006UM-I1; Fri, 14 Nov 2003 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKkbU-0006TG-69 for l2vpn@optimus.ietf.org; Fri, 14 Nov 2003 15:31:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28496 for ; Fri, 14 Nov 2003 15:31:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKkbS-0003ub-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 15:31:38 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1AKkbS-0003t0-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 15:31:38 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 12:31:04 -0800 Reply-To: From: "Vach Kompella" To: "'Rick Wilder'" , Subject: RE: ARP mediation to working group draft Date: Fri, 14 Nov 2003 12:29:00 -0800 Organization: Alcatel USA Message-ID: <01b701c3aaed$f1483c40$0101010a@eng.timetra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <20031113175340.87803.qmail@web109.biz.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Nov 2003 20:31:04.0333 (UTC) FILETIME=[39B0C3D0:01C3AAEE] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In terms of making a WG draft, I spoke with both Tom and Alex, and did not hear a "not in charter" concern. Could both of you please make your positions clear on the mailing list? There was some confusion regarding that point. Again, arp-mediation is only applicable to IP traffic. There MUST be no attempt in the IETF to support any other form of interworking. -Vach=20 > -----Original Message----- > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On=20 > Behalf Of Rick Wilder > Sent: Thursday, November 13, 2003 9:54 AM > To: l2vpn@ietf.org > Subject: RE: ARP mediation to working group draft >=20 >=20 >=20 > There is clearly interest in this document. This > starts a 3 week comment period on making this a WG > document. Barring any new input to the contrary, we'll > then rename it and give a permament home. >=20 > Rick >=20 > --- Sasha Vainshtein wrote: > > I concur. > >=20 > > > -------------------------------------------------------------- > -------------- > > -------- > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com =20 > > phone: +972-3-7659993 (office) > > +972-8-9254948 (home) > > +972-58-674833 (cellular) > >=20 > >=20 > > > -----Original Message----- > > > From: Andrew G. Malis > > [mailto:andymalis@comcast.net] > > > Sent: Thursday, November 13, 2003 12:27 AM > > > To: l2vpn@ietf.org > > > Subject: ARP mediation to working group draft > > >=20 > > >=20 > > > Based on Vach's comments in the L2VPN meeting, I > > would like > > > to request that > > > draft-shah-ppvpn-arp-mediation-03.txt become a > > l2vpn WG > > > draft. That'll > > > also get it back into the I-D directory. :-) > > >=20 > > > Thanks, > > > Andy > > >=20 > > >=20 > >=20 >=20 >=20 From exim@www1.ietf.org Fri Nov 14 18:12:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04263 for ; Fri, 14 Nov 2003 18:12:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKn6i-0001Xz-15 for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 18:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAENC36H005941 for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 18:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKn6h-0001Xk-SM for l2vpn-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 18:12:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04160 for ; Fri, 14 Nov 2003 18:11:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKn6f-00067I-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 18:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKn6e-00067F-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 18:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKn6e-0001Wf-RT; Fri, 14 Nov 2003 18:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKn5x-0001VK-W2 for l2vpn@optimus.ietf.org; Fri, 14 Nov 2003 18:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04033 for ; Fri, 14 Nov 2003 18:11:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKn5v-00066G-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 18:11:15 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1AKn5u-00065T-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 18:11:14 -0500 Received: from default.comcast.net (h0010db1abb41.ne.client2.attbi.com[24.61.134.169]) by comcast.net (rwcrmhc12) with SMTP id <2003111423103801400pmoife> (Authid: andymalis@comcast.net); Fri, 14 Nov 2003 23:10:42 +0000 Message-Id: <6.0.0.22.2.20031114175833.028d8498@mail.comcast.net> X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 14 Nov 2003 18:10:02 -0500 To: From: "Andrew G. Malis" Subject: RE: ARP mediation to working group draft Cc: "'Rick Wilder'" , In-Reply-To: <01b701c3aaed$f1483c40$0101010a@eng.timetra.com> References: <20031113175340.87803.qmail@web109.biz.mail.yahoo.com> <01b701c3aaed$f1483c40$0101010a@eng.timetra.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach, Agreed. By definition, ARP mediation is for IP only. We're just doing mediation between RFCs 826, 1332, 2225, and 2390. Cheers, Andy ---------- At 11/14/2003 12:29 PM -0800, Vach Kompella wrote: >In terms of making a WG draft, I spoke with both Tom and Alex, and did >not hear a "not in charter" concern. Could both of you please make your >positions clear on the mailing list? There was some confusion regarding >that point. > >Again, arp-mediation is only applicable to IP traffic. There MUST be no >attempt in the IETF to support any other form of interworking. > >-Vach > > > -----Original Message----- > > From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On > > Behalf Of Rick Wilder > > Sent: Thursday, November 13, 2003 9:54 AM > > To: l2vpn@ietf.org > > Subject: RE: ARP mediation to working group draft > > > > > > > > There is clearly interest in this document. This > > starts a 3 week comment period on making this a WG > > document. Barring any new input to the contrary, we'll > > then rename it and give a permament home. > > > > Rick > > > > --- Sasha Vainshtein wrote: > > > I concur. > > > > > > > > -------------------------------------------------------------- > > -------------- > > > -------- > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > phone: +972-3-7659993 (office) > > > +972-8-9254948 (home) > > > +972-58-674833 (cellular) > > > > > > > > > > -----Original Message----- > > > > From: Andrew G. Malis > > > [mailto:andymalis@comcast.net] > > > > Sent: Thursday, November 13, 2003 12:27 AM > > > > To: l2vpn@ietf.org > > > > Subject: ARP mediation to working group draft > > > > > > > > > > > > Based on Vach's comments in the L2VPN meeting, I > > > would like > > > > to request that > > > > draft-shah-ppvpn-arp-mediation-03.txt become a > > > l2vpn WG > > > > draft. That'll > > > > also get it back into the I-D directory. :-) > > > > > > > > Thanks, > > > > Andy > > > > > > > > > > > > > > > From exim@www1.ietf.org Fri Nov 14 19:35:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06854 for ; Fri, 14 Nov 2003 19:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoP2-0007EM-PG for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 19:35:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAF0Z43V027788 for l2vpn-archive@odin.ietf.org; Fri, 14 Nov 2003 19:35:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoP2-0007E7-Gb for l2vpn-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 19:35:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06845 for ; Fri, 14 Nov 2003 19:34:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKoP0-00075L-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 19:35:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKoP0-00075I-00 for l2vpn-web-archive@ietf.org; Fri, 14 Nov 2003 19:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoOz-0007DS-OW; Fri, 14 Nov 2003 19:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKoOf-0007Cv-8q for l2vpn@optimus.ietf.org; Fri, 14 Nov 2003 19:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06828 for ; Fri, 14 Nov 2003 19:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKoOd-00074k-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 19:34:39 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AKoOd-00074V-00 for l2vpn@ietf.org; Fri, 14 Nov 2003 19:34:39 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAF0Y8a14640 for ; Fri, 14 Nov 2003 19:34:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 19:34:09 -0500 Message-ID: From: "Hamid Ould-Brahim" To: vach.kompella@alcatel.com, l2vpn@ietf.org Subject: RE: distributed vpls... Date: Fri, 14 Nov 2003 19:34:08 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vach, > > > > I think the section on distributed VPLS in > draft-ietf-l2vpn-signaling is > not required. > I think it is. The model has been documented in the framework document (reflecting some previous drafts done in this area) and addresses specific deployment scenario which is as well addressed in the bgp-based solution case. In addition to that the mechanism described in the signaling draft for distributed vpls has applicability to the inter-provider ldp-vpls scenario case (as documented). I think we should leave it there. Hamid. From exim@www1.ietf.org Mon Nov 24 15:35:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28011 for ; Mon, 24 Nov 2003 15:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONQb-00076D-F5 for l2vpn-archive@odin.ietf.org; Mon, 24 Nov 2003 15:35:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKZPUr027288 for l2vpn-archive@odin.ietf.org; Mon, 24 Nov 2003 15:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONQb-000763-Bl for l2vpn-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:35:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27970 for ; Mon, 24 Nov 2003 15:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONQa-00048Y-00 for l2vpn-web-archive@ietf.org; Mon, 24 Nov 2003 15:35:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONQZ-00048U-00 for l2vpn-web-archive@ietf.org; Mon, 24 Nov 2003 15:35:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONQD-00071I-RH; Mon, 24 Nov 2003 15:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONPK-0006wT-37 for l2vpn@optimus.ietf.org; Mon, 24 Nov 2003 15:34:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27839; Mon, 24 Nov 2003 15:33:51 -0500 (EST) Message-Id: <200311242033.PAA27839@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: l2vpn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-ipls-00.txt Date: Mon, 24 Nov 2003 15:33:50 -0500 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : IP-Only LAN Service (IPLS) Author(s) : H. Shah Filename : draft-ietf-l2vpn-ipls-00.txt Pages : 18 Date : 2003-11-24 A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear to those systems as if they are interconnected on a private LAN. The systems which are interconnected in this way may themselves be LAN switches. If, however, the interconnected systems are NOT LAN switches, but rather are IP hosts or IP routers, certain simplifications are possible. We call this simplified type of virtual private LAN service an ?Ip-only LAN Service? (IPLS). In IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their MAC Destination Addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the ?MAC Address Learning? procedures of IEEE 802.1D. Further, Address Resolution Protocol (ARP) messages are proxied, rather than being carried transparently. This draft specifies the protocols and procedures for support of the IPLS service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-l2vpn-ipls-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@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-ipls-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-24152753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-ipls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-ipls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-24152753.I-D@ietf.org> --OtherAccess-- --NextPart--