From lmartini@cisco.com Tue Jun 2 13:17:29 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACDF3A7048; Tue, 2 Jun 2009 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qOt3BJwsf6J; Tue, 2 Jun 2009 13:17:28 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 845863A7024; Tue, 2 Jun 2009 13:17:28 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n52KHGd9011344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 14:17:17 -0600 (MDT) Message-ID: <4A2588CC.2030502@cisco.com> Date: Tue, 02 Jun 2009 14:17:16 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Sherry Xue Subject: Re: Some comments on draft-ietf-pwe3-segmented-pw-11 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: l2vpn@ietf.org, pwe3@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 20:17:29 -0000 Sherry Xue wrote: > Hi, > I have reviewed the draft-ietf-pwe3-segmented-pw-11, and have some comments, > please find below. > > 1) Section 4, some confused about figure 2, there are two "emulated > service" identifiers, between the egress of CE1 and ingress of CE2, also > between the ingress of PE1 and the egress of PE4.Does some amendment should > be done to avoid the reduplicate emulated service? > > yes, it a mistake in the picture it now says: "Multi-Segment Pseudowire" at the top. > 2) Section 4, in the penultimate paragraph, "this document describes > procedures for building multi-segment pseudo wires using manual > configuration of the switching point PE2", the Switching point" PE2" should > be "S-PE "which will be coincident with figure 3. And the identifier of the > Switch point in the sentence should be consistent with figure 3. > > it needs to be "PE1" I fixed it. > 3) Section 4, in the last paragraph, " no control messages are > exchanged yet as the S-PE PE dose not have.", there are a redundant "PE", > please delete it. > > done. > 4) Section 4, in the last paragraph, sentence as "first the S-PE is > configured to switch a SS-PW from a specific peer to another SS-PW destined > for a different peer". > I have some confusion about SS-PW definition used in the MS-PW as PW > segment role. SS-PW is defined as "a PW setup directly between two T-PE > devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that > connects the two T-PEs." in the terminology section of [segmented-pw]. But > yes, it seems that the definition in rfc5254 is incorrect. > SS-PW is defined "a PW setup directly between two PE devices. Each direction > of an SS-PW traverses one PSN tunnel that connects the two PEs" in RFC5254. > They are different, because SS-PW is terminated on different PE roles, T-PE > in former case, T-PE or S-PE in latter case. > IMO, SS-PW should be setup between TWO T-PE devices, there are some > differences between SS-PW and PW segment. If it is right, the SS-PW could > not be used the same as PW segment. So the sentence should be restructured > as "first the S-PE is configured to switch a PW segment from a specific peer > to another PW segment destined for a different peer...". And concerted > action should be taken in the draft. > > yes , this is correct , I will change it. I also corrected this later in the status section. > 5) Section 7, in the first paragraph, the nomenclature should be > identical with figure 3, such as PE2, PE3 should be amended as S-PE and > T-PE, etc. > > yes this was already fixed as pointed out by Stewart. ( I have not yet sent out the revised version.) > 6) Section 7.4, in the second sentence, Should the"PW switching point > TLV" in line 3 be "S-PE TLV"? In the fourth and fifth paragraphs, should the > "PW switching point TLV" in line 1 be "S-PE TLV"? > > no, it's a personal editing choice, either way it's fine. > 7) Section 7.4.1, The title of section 7.4.1 should be accordant with > the title of section 7.4, so "S-PE sub-TLV" may be better? > > I changed sec 7 , as strictly speaking i cannot use the abbreviation in the title. the RFC editor would have corrected that. > 8) Section 8, the title, "MPLS-PW to PW-L2TPv3 control plane switching" > may be amended as "MPLS-PW to L2TPv3-PW control plane switching" > > yes, fixed. > 9) Section 8.4.1, I have some confused about the session establishment. > In the two example exchanges of message, I understand that the MS-PW is > setup in one direction totally, and then the other direction. Dose I make a > mistake? Now I have a question, take L2TPv2 PW- MPLS PW for example, whether > the L2tpv3 ICRP must be send after the LDP label mapping receiving from the > PE3? Should the PW switching node, map to LDP Label mapping forward and send > L2TPv3 ICRP backwards simultaneity? > > Both cases work fine. It really depends who starts the process first : the L2TPv3 side or the MPLS side. > And I have a question, which is why VCCV CC type 2 is not supported for > MS-PW? I think the reason is that the P device, which is neither S-PE nor > T-PE, is not responsible to inspect the VCCV message? That is right? > > No. The problem is in processing the router attention label ( label 1). Also the real reason is that this mode is redundant , and was only supported to accommodate hardware limitations at the time when the VCCV document was written. This is no mode is longer necessary. Thanks for all your good comments ! I really appreciate a fresh set of eyes reading this document. Luca > Regards > > Sherry > > > > From davari@broadcom.com Tue Jun 2 15:53:02 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101D53A6DC5 for ; Tue, 2 Jun 2009 15:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9Mjv6nR9IYF for ; Tue, 2 Jun 2009 15:53:01 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id E1EE13A6D98 for ; Tue, 2 Jun 2009 15:53:00 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 02 Jun 2009 15:52:45 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 2 Jun 2009 15:52:45 -0700 From: "Shahram Davari" To: "l2vpn@ietf.org" Date: Tue, 2 Jun 2009 15:52:43 -0700 Subject: draft-ietf-l2vpn-pbb-vpls-interop-00 Thread-Topic: draft-ietf-l2vpn-pbb-vpls-interop-00 Thread-Index: Acnj1NcmW3rc9R7sRsma7+EswPEw9g== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD66EDA982DAE@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 663B72B73BO41051151-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD66EDA982DAESJEXCHCCR02co_ X-Mailman-Approved-At: Tue, 02 Jun 2009 16:08:30 -0700 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 22:53:02 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD66EDA982DAESJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Shane, What happened to this draft? did it get updated? I have the following obser= vations regarding this draft: - This draft seems to list 9 different possibilities, some of which don't s= olve the problem stated, which is improving VPLS scalability. - Some of the options are very complex and very unlikely to be used, such a= s a case which require simultaneous operation of IB-BEB, B-BEB, PBB and VPL= S on the same node. - There is no new protocol and there is no enforcement or even recommendtio= n of which option to use. Therefore it doesn't seem to be a candidate for standard RFC. It could be an Informational RFC. Given the above what is the plan for this draft? Thanks, Shahram ************** Hi Everyone, This concludes the call to made this a WG draft. There appears to be good s= upport to make this a WG draft. Would the authors please re- publish the cu= rrent -01 version as follows: draft-ietf-l2vpn-pbb-vpls-interop-00 ... please address and, if necessary incorporate, changes suggested by WG m= embers (Peng He, Alexander Shafir and others), during this thread into the = next revision of the WG draft (-01). Two other suggestions: 1) We should really add an "Applicability Statement", similar to PWE3 & oth= er drafts, near the very top of this draft. This would make it more clear t= o the IESG & readers why (& when) this draft is required to fulfill the nee= ds of SP's. My suggested layout for the beginning of this draft would be as= follows: - Abstract - Section 1: Introduction -- I would suggest leaving the first paragraph an= d, perhaps, the second to last and last paragraphs of the existing "Introdu= ction" and try to clean it up a bit by reducing the number of acronyms used= . - Section 2: Applicability -- I would suggest taking the rest of the exis= ting Introduction and moving it in this section. Furthermore, the Applicabi= lity section should briefly & clearly point out which of the following four= categories are relevant to this draft: + PBB "just works" with VPLS + PBB may not work with VPLS + PBB works with VPLS, but not efficiently + PBB won't work with VPLS - Section 3: Terminology 2) We should also look at reducing the number of acronyms used in the Abstr= act and Introduction, in order to improve it's readability. It's good that = there is Section 2, Terminology, in there to help provide a Glossary ... ho= wever, that comes *after* the Abstract & Introduction, so it would be good = to tone-down things in those sections until people get to the Terminology s= ection. We should also look at adding an Applicability Statement section to the oth= er PBB WG draft (draft-ietf-l2vpn-pbb-vpls-pe-model-00) as well, for the sa= me reasons as stated above. Thanks, -shane --_000_2C2F1EBA8050E74EA81502D5740B4BD66EDA982DAESJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable 
Hi Shane,
 
What happened to this draft? did it get updated? I have the fo=
llowing observations regarding this draft:
 
- This draft seems to list 9 different possibilities, some of =
which don't solve the problem stated, which is improving VPLS=

scalability.
 
- Some of =
the options are very complex and very unlikely to be used, such as a case w=
hich require simultaneous operation of IB-BEB, B-BEB, PBB and VPLS on the s=
ame node.
 
- There is no new pr=
otocol and there is no enforcement or even recommendtion of which option to=
 use. Therefore it doesn't
seem to be a candidate for st=
andard RFC. It could be an Informational RFC.
 
Given the above what is the plan for this draft?
 
Thanks,
Shahram
= 
=
 
 
 
**************
Hi Everyone, This concludes the call to made this a WG draft. There appears to= be good support to make this a WG draft. Would the authors please= re- publish the current -01 version as follows: 
draft-ietf-l2vpn-pbb-vpls-interop-00
... please address and, if necessary incorporate, changes suggest= ed by WG members (Peng He, Alexander Shafir and others), during th= is thread into the next revision of the WG draft (-01). 
Two other suggestions:
1) We should really add an "Applicability Statement", similar to = PWE3 & other drafts, near the very top of this draft. This wou= ld make it more clear to the IESG & readers why (& when) t= his draft is required to fulfill the needs of SP's. My suggested l= ayout for the beginning of this draft would be as follows: - Abstract - Section 1: Introduction -- I would suggest leaving the first paragraph and, perhaps, the second to last and last paragraphs of th= e existing "Introduction" and try to clean it up a bit by reducing= the number of acronyms used. - Section 2: Applicability = -- I would suggest taking the rest of the existing Introduction an= d moving it in this section. Furthermore, the Applicability sectio= n should briefly & clearly point out which of the following fo= ur categories are relevant to this draft: 
	=
+ PBB "just works" with VPLS
	+ PBB may not work with VPLS
	+ PBB works with VPLS, but not efficiently
	+ PBB won't work with VPLS
  - Section 3: Terminology
2) We should also look at reducing the number of acronyms used in= the Abstract and Introduction, in order to improve it's readabili= ty. It's good that there is Section 2, Terminology, in there to he= lp provide a Glossary ... however, that comes *after* the Abstract= & Introduction, so it would be good to tone-down things in th= ose sections until people get to the Terminology section. We should also look at adding an Applicab= ility Statement section to the other PBB WG draft (draft-ietf-l2vp= n-pbb-vpls-pe-model-00) as well, for the same reasons as stated ab= ove. 
Thanks,

-shane
--_000_2C2F1EBA8050E74EA81502D5740B4BD66EDA982DAESJEXCHCCR02co_-- From davarish@yahoo.com Tue Jun 2 17:33:20 2009 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339923A6A01 for ; Tue, 2 Jun 2009 17:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdCMGosOCz4Y for ; Tue, 2 Jun 2009 17:33:19 -0700 (PDT) Received: from web88413.mail.re1.yahoo.com (web88413.mail.re1.yahoo.com [69.147.97.237]) by core3.amsl.com (Postfix) with SMTP id 07E893A69CD for ; Tue, 2 Jun 2009 17:33:18 -0700 (PDT) Received: (qmail 86371 invoked by uid 60001); 3 Jun 2009 00:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243989189; bh=GZdOk4V9YbCApwF5pmYFZBSCh7o0wYcAPE4euujPngk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=SMDnQT01cOFuckBpcchGUWS+1I0penkH9ZKGBxLq85YVDQUmpVyub8+SVYGI3ON4sVW4v5exLqEeEgt0JwScpN7EFak2WCemFJwhSTRgACWwZO6ZBZufC1x+EYyBE4iZN2Y/uZjQKtlpe8VNfK3c+xquK/wmrWbsMtYKHjj+sNA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=abiQsQXCUvC8kYKXcp/weY29MDnLG7w8jFFQIole5EBC0Yu7IRUwE5qGVxipK5qF+our+t98sCeepUbAIy/seX9hkow748WXSJmBc3o3i4PBsCvEFk4TLbpU7vJ4MqKrGabSHMNJYsXuPeGTItpHZjrGjqvO6Edya/Fww09L8Tc=; Message-ID: <730886.81302.qm@web88413.mail.re1.yahoo.com> X-YMail-OSG: eF9rMEYVM1lKviU5LlV2mMQuyCXukqtqOOfuoFY9W2Mg8EqSs.kTR3HDl98yCadhMfL3U60pGMhA7jY1FJ8mu_NUeTV_OOg5tpDMixUZP_OXBhA62WFgoVLe9QMkBA62briOhP9UmEcheGqPLw8DYN_dBZweDU5XRpgriPV6uQbqfehA.Dn9S_1NyALFeFfK272JtO4DS9IFjCbxNc3qzk9hR8FhXv1lk_jWo_lP2gT70k85ZltwbCw7_pdNFz2D2rxJkixWJmGZ18dfZOV02QE3wG3nsQxJGvy5HJQA Received: from [216.31.219.19] by web88413.mail.re1.yahoo.com via HTTP; Tue, 02 Jun 2009 17:33:09 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 Date: Tue, 2 Jun 2009 17:33:09 -0700 (PDT) From: davarish Subject: Fw: draft-ietf-l2vpn-pbb-vpls-interop-00 To: l2vpn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-350557814-1243989189=:81302" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: davarish List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 00:33:20 -0000 --0-350557814-1243989189=:81302 Content-Type: text/plain; charset=us-ascii Hi Shane, What happened to this draft? did it get updated? I have the following observations regarding this draft: - This draft seems to list 9 different possibilities, some of which don't solve the problem stated, which is improving VPLS scalability. - Some of the options are very complex and very unlikely to be used, such as a case which require simultaneous operation of IB-BEB, B-BEB, PBB and VPLS on the same node. - There is no new protocol and there is no enforcement or even recommendtion of which option to use. Therefore it doesn't seem to be a candidate for standard RFC. It could be an Informational RFC. Given the above what is the plan for this draft? Thanks, Shahram ************** Hi Everyone, This concludes the call to made this a WG draft. There appears to be good support to make this a WG draft. Would the authors please re- publish the current -01 version as follows: draft-ietf-l2vpn-pbb-vpls-interop-00 ... please address and, if necessary incorporate, changes suggested by WG members (Peng He, Alexander Shafir and others), during this thread into the next revision of the WG draft (-01). Two other suggestions: 1) We should really add an "Applicability Statement", similar to PWE3 & other drafts, near the very top of this draft. This would make it more clear to the IESG & readers why (& when) this draft is required to fulfill the needs of SP's. My suggested layout for the beginning of this draft would be as follows: - Abstract - Section 1: Introduction -- I would suggest leaving the first paragraph and, perhaps, the second to last and last paragraphs of the existing "Introduction" and try to clean it up a bit by reducing the number of acronyms used. - Section 2: Applicability -- I would suggest taking the rest of the existing Introduction and moving it in this section. Furthermore, the Applicability section should briefly & clearly point out which of the following four categories are relevant to this draft: + PBB "just works" with VPLS + PBB may not work with VPLS + PBB works with VPLS, but not efficiently + PBB won't work with VPLS - Section 3: Terminology 2) We should also look at reducing the number of acronyms used in the Abstract and Introduction, in order to improve it's readability. It's good that there is Section 2, Terminology, in there to help provide a Glossary ... however, that comes *after* the Abstract & Introduction, so it would be good to tone-down things in those sections until people get to the Terminology section. We should also look at adding an Applicability Statement section to the other PBB WG draft (draft-ietf-l2vpn-pbb-vpls-pe-model-00) as well, for the same reasons as stated above. Thanks, -shane --0-350557814-1243989189=:81302 Content-Type: text/html; charset=us-ascii 


Hi Shane,
 
What happened to this draft? did it get updated? I have the following observations regarding this draft:
 
- This draft seems to list 9 different possibilities, some of which don't solve the problem stated, which is improving VPLS
scalability.
 
- Some of the options are very complex and very unlikely to be used, such as a case which require simultaneous operation of IB-BEB, B-BEB, PBB and VPLS on the same node.
 
- There is no new protocol and there is no enforcement or even recommendtion of which option to use. Therefore it doesn't
seem to be a candidate for standard RFC. It could be an Informational RFC.
 
Given the above what is the plan for this
 draft?
 
Thanks,
Shahram
 
 
 
**************
Hi Everyone,

This concludes the call to made this a WG draft. There appears to be good support to make this a WG draft. Would the authors please re- publish the current -01 version as follows: 
draft-ietf-l2vpn-pbb-vpls-interop-00

... please address and, if necessary incorporate, changes suggested by WG members (Peng He, Alexander Shafir and others), during this thread into the next revision of the WG draft (-01). 
Two other suggestions:
1) We should really add an "Applicability Statement", similar to PWE3 & other drafts, near the very top of this draft. This would make it more clear to the IESG & readers why (& when) this draft is required to fulfill the needs of SP's. My suggested layout for the beginning of this draft would be as follows: 
  - Abstract
- Section 1: Introduction -- I would suggest leaving the first paragraph and, perhaps, the second to last and last paragraphs of the existing "Introduction" and try to clean it up a bit by reducing the
 number of acronyms used. - Section 2: Applicability -- I would suggest taking the rest of the existing Introduction and moving it in this section. Furthermore, the Applicability section should briefly & clearly point out which of the following four categories are relevant to this draft: 
	+ PBB "just works" with VPLS
	+ PBB may not work with VPLS
	+ PBB works with VPLS, but not efficiently
	+ PBB won't work with VPLS
  - Section 3: Terminology
2) We should also look at reducing the number of acronyms used in the Abstract and Introduction, in order to improve it's readability. It's good that there is Section 2, Terminology, in there to help provide a Glossary ... however, that comes *after* the Abstract & Introduction, so it would be good to tone-down things in those sections until people get to the
 Terminology section. 
We should also look at adding an Applicability Statement section to the other PBB WG draft (draft-ietf-l2vpn-pbb-vpls-pe-model-00) as well, for the same reasons as stated above. 
Thanks,

-shane

--0-350557814-1243989189=:81302--

From yljiang@huawei.com  Thu Jun  4 02:52:48 2009
Return-Path: 
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD363A6DE7 for ; Thu,  4 Jun 2009 02:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.879
X-Spam-Level: *
X-Spam-Status: No, score=1.879 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqP7rEzFB6dW for ; Thu,  4 Jun 2009 02:52:46 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C2BA63A6C31 for ; Thu,  4 Jun 2009 02:52:45 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKP00I26KQS88@szxga04-in.huawei.com> for l2vpn@ietf.org; Thu, 04 Jun 2009 17:52:05 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKP005W2KQS0I@szxga04-in.huawei.com> for l2vpn@ietf.org; Thu, 04 Jun 2009 17:52:04 +0800 (CST)
Received: from j59929 ([10.70.77.90]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKP007ADKQSR4@szxml04-in.huawei.com> for l2vpn@ietf.org; Thu, 04 Jun 2009 17:52:04 +0800 (CST)
Date: Thu, 04 Jun 2009 17:52:03 +0800
From: Jiang Yuan-long 
Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"
To: "Dutta, Pranjal K (Pranjal)" 
Message-id: <008301c9e4fa$1d53adf0$5a4d460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: multipart/alternative; boundary="Boundary_(ID_gOSwDVDfzGogQMHTCahBug)"
X-Priority: 3
X-MSMail-priority: Normal
References: <002801c9d3be$f72fed10$3b4d460a@china.huawei.com>  <005901c9de6e$1b179930$3b4d460a@china.huawei.com> 
X-Mailman-Approved-At: Thu, 04 Jun 2009 09:51:10 -0700
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Jun 2009 09:52:48 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_gOSwDVDfzGogQMHTCahBug)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi, Pranjal,

IMHO, I think this sentence is unnecessary as it is not explicit in RFC 4762. 
Furthermore, as you pointed out, for the first case, PE3-rs can generate 
the message. Even in the second case, MTU-s sending flush message may not be 
the best method.

As I know, some disadvantages in this mechanism:
1) PE3-rs must pre-bind the LDP sessions associated with spoke PW and hub 
   PWs together, so that it knows how to forward these messages in the 
   control plane;
2) PE3-rs must forward the withdraw message by PE-rs, which may loop arround 
   other PEs in the VPLS as noted in draft-pkwok-l2vpn-vpls-macflush-ld-00.

IMO, though PE3-rs may not know it is hosting a backup path, it should be
aware of the fact that the spoke PW becomes active, so activity of the spoke 
PW can be used as a trigger for PE3-rs to send out the flush message. So in 
both cases, PE3-rs can be the sole source of the message, thus the above two 
disadvantages are avoided.
Any comments?


  Thanks

Yuanlong Jiang

  ----- Original Message ----- 
  From: Dutta, Pranjal K (Pranjal) 
  To: Jiang Yuan-long 
  Cc: l2vpn@ietf.org 
  Sent: Saturday, May 30, 2009 7:36 AM
  Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"


  Hi,

           Both the interpretations are correct and desired flushing affect is same. PE3-rs can generate 

  mac flush if it is H-VPLS aware (means it knows that it is hosting a backup path) in case of which 

  It is not necessary for MTU to trigger mac flush. That is possible if PW standby/active status signaling

  In implemented between MTU and PE3-rs. If PE3-rs is H-VPLS agnostic then the control is in MTU alone

  and so MTU needs to trigger mac flush towards PE3-rs.

   

  Thanks,

  Pranjal

   


------------------------------------------------------------------------------

  From: Jiang Yuan-long [mailto:yljiang@huawei.com] 
  Sent: Tuesday, May 26, 2009 6:55 PM
  To: Dutta, Pranjal K (Pranjal)
  Cc: l2vpn@ietf.org
  Subject: Re: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

   

  Pranjal,

   

  Thank you for the explanation on the PE-ID, it helps me to understand what is 

  beyond the texts, I sincerely appreciate it:)

   

  Another question, section 5.2, at the bottom of page 12, it says:

   

     By default, MTU-2 should still trigger MAC flush as currently  
     defined in [RFC4762] after the backup PW is made active by RSTP.  

  The same text is also found in draft-ietf-pwe3-redundancy-bit.

   

  But in RFC 4762, it is not the MTU-s but the PE that should send out the flush msg.

  As the only description on this mechanism is at the bottom of page 22:

                                                    [...]. To enable faster
     convergence, the PE3-rs where the secondary PW got activated may send
     out a flush message (as explained in Section 6.2), [...]

   

  I wonder is there anything I missed?

   

   

   Best regards

   

  Yuanlong Jiang

   

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

    From: Dutta, Pranjal K (Pranjal) 

    To: Jiang Yuan-long ; Dutta, Pranjal K (Pranjal) 

    Cc: l2vpn@ietf.org 

    Sent: Tuesday, May 26, 2009 1:51 PM

    Subject: RE: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

     

    Hi,

           Please refer to my answer inline to your comments.

     

    Thanks,

    Pranjal

     


----------------------------------------------------------------------------

    From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jiang Yuan-long
    Sent: Wednesday, May 13, 2009 4:36 AM
    To: Dutta, Pranjal K (Pranjal)
    Cc: l2vpn@ietf.org
    Subject: Comments on "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

     

    Hi Dutta,

     

    I have a few comments on this draft:

     

    1. From the description in the draft, it seems only one PE-ID is needed 

    for your mechanism. But in the definition of PE-ID TLV in section 4, 

    a list of one or more PE-ID may be included, but do we really need more 

    than one PE-ID element? Can you give some clues on its usage?
    IMO, this definition is also in contradiction to the prior sentence 

    "The PE-ID TLV carries the unique identifier of a generic PW endpoint".  

     

    [Pranjal]

          Yes, that's correct. PE-ID TLV can accommodate a LIST of PE-ID Elements. Today implementations 

           can send a list of FEC Elements within a FEC TLV sent in the MAC flush message. A common network

           event may trigger failure of primary PWs for a set of VPLS instances together, which requires to send mac flush 

           for all those instances. Sending an individual LDP MAC flush message per VPLS instance is sub-optimal and

           so MAC flush for a set of VPLS instances are bundled in a  single message. Same applies to optimized

           MAC flush with PE-ID as well.

     

     

     

    2. The length of the FEC-128 specific PE-ID element is given as 2 octets, 

    should the correct length be 8?

     

    [Pranjal]

          That's right. It's a typo. It should have been 8 octets. We will correct it in the next revision.

     

     

    3. Maybe the FEC-129 specific PE-ID Element needs another extra field 

    for PE address, as AII TLVs can only be null according to RFC 4762 in 

    section 6.1.1, while AGI TLV can only give you information on VPLS 

    instance. 

     

    [Pranjal]

         RFC 4762 also specifies that use of non-null SAII and TAII would be addressed in future revision.

         Today, FEC 129 is used in VPLS provisioned with BGP-AD where SAII/TAII always carry valid 

         end-point identifiers (VS-ID) as per l2vpn signaling draft below.

     

         http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt

     

         RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non BGP-AD deployments to replace FEC 128. 

         

         But if you see AGI definition in RFC 4446 (that carries vpls-id as per RFC 4762), only one type is allocated to be used 

         in BGP-AD provisioned VPLS from  L2 VPN signaling draft. 

     

    4. I think this mechanism only works properly in a scenario where the 

    MTU-s, PE-1 and PE-2 all play in harmony, otherwise, if MTU-s sends 

    out a RFC4762 compatiable flushing msg, while PE-1 sends out a flushing 

    msg with PE-ID, then other PEs in the VPLS will process both msgs and 

    the result is flushing all MACs. So maybe this should be pointed out in 

    the applicability section.

     

[Pranjal]  Following is stated in the section  5. Application of PE-ID TLV in Optimized MAC Flush  

     

   However the inclusion of the FEC-TLV should be     based on what would be the desired effect should the PE-ID not be     understood by the receiver.  In cases where the desired action when     the PE-ID is not understood would be to behave as described in     [RFC4762], then the FEC TLV SHOULD be included.  In cases where the     desired action when the PE-ID is not understood is to take no     action, then the FEC TLV SHOULD NOT be included.  Are you suggesting for more explanation in that section? 

     

    5. Some random corrections:
    s/ignored/ignored by/

    page 6, "...So the MAC addresses that require flushing and relearning at 

    PE-2 are only the MAC addresses those have been learned on the PW 

    connected to PE-1." is redundant, maybe it is better to say "...So the MAC 

    addresses that require flushing and relearning at PE-2 are only those 

    MAC addresses learned on the PW connected to PE-1.".

     

    [Pranjal] Sure, we would address this in the next revision.

     

    Thanks

     

    Yuanlong Jiang

--Boundary_(ID_gOSwDVDfzGogQMHTCahBug)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable









Hi,=20
Pranjal,


 


IMHO, I think this=20
sentence is unnecessary as it is not explicit in RFC 4762. =



Furthermore, as you=20
pointed out, for the first case, PE3-rs can generate =



the message.=20
Even in the=20
second case, MTU-s sending flush message may not be 


the best method.


 


As I know, some=20
disadvantages in this mechanism:


1) PE3-rs must pre-bind=20
the LDP sessions associated with spoke PW and hub =



   PWs=20
together, so that it knows how to forward these messages in the=20



   control=20
plane;


2) PE3-rs must forward=20
the withdraw message by PE-rs, which may loop arround =



   other PEs=20
in the VPLS=20
as noted in=20
draft-pkwok-l2vpn-vpls-macflush-ld-00.


 


IMO, though PE3-rs=20
may not know it is hosting a backup path, it should =
be


aware of the fact that=20
the spoke PW becomes active, so activity of the spoke =



PW can be =
used as a trigger for PE3-rs=20
to send out the flush message. So in 


both cases, =
PE3-rs can be the sole=20
source of the message, thus the above two 


disadvantages are=20
avoided.


Any=20
comments?


 


 


 =20
Thanks


 


Yuanlong=20
Jiang


 



  
----- Original Message ----- =


  
  
  
  
Sent: Saturday, May =
30, 2009 7:36 AM

  
Subject: RE: Comments =
on=20
  "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

  


  

  
Hi,

  
        =20
  Both the interpretations are correct and desired flushing affect is =
same.=20
  PE3-rs can generate 

  
mac flush =
if it is=20
  H-VPLS aware (means it knows that it is hosting a backup path) in case =
of=20
  which 

  
It is not =
necessary=20
  for MTU to trigger mac flush. That is possible if PW standby/active =
status=20
  signaling

  
In =
implemented=20
  between MTU and PE3-rs. If PE3-rs is H-VPLS agnostic then the control =
is in=20
  MTU alone

  
and so MTU =
needs to=20
  trigger mac flush towards PE3-rs.

  
 

  
Thanks,

  
Pranjal

  
 

  

  

  

  

  
From: Jiang=20
  Yuan-long [mailto:yljiang@huawei.com] 
Sent: Tuesday, May 26, 2009 =
6:55=20
  PM
To: =
Dutta, Pranjal K (Pranjal)
Cc: l2vpn@ietf.org
Subject: Re: Comments on=20
  "draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

  
 

  

  
Pranjal,

  

  
 

  

  
Thank you for the explanation on the=20
  PE-ID, it helps me to understand =
what is=20
  

  

  
beyond the texts, I sincerely appreciate=20
  it:)

  

  
 

  

  
Another question, section 5.2, at the bottom =
of page=20
  12, it says:

  

  
 

  

  
   By default, MTU-2 should =
still trigger=20
  MAC flush as currently  
   defined in [RFC4762] after =
the backup PW=20
  is made active by RSTP.  

  

  

  
The=20
  same text is also found =
in draft-ietf-pwe3-redundancy-bit.

  

  
 

  

  
But=20
  in RFC 4762, it is not the MTU-s but the PE that should send out the =
flush=20
  msg.

  

  
As the only description on this =
mechanism is=20
  at the bottom of page 22:

  

  
           =
;            =
            &=
nbsp;           &n=
bsp;  [...]. To enable=20
  faster
   convergence, the PE3-rs =
where the=20
  secondary PW got activated may send
   out a flush message (as =
explained in=20
  Section 6.2), [...]

  

  
 

  

  
I=20
  wonder is there anything I missed?

  

  
 

  

  
 

  

  
 Best =
regards

  

  
 

  

  
Yuanlong Jiang

  

  
 

  
    

    
----- Original Message -----=20
    

    
    

    
To: Jiang Yuan-long ; Dutta, Pranjal K =
(Pranjal)=20
    

    
    

    
Sent: Tuesday, May 26, 2009 1:51=20
    PM

    

    
Subject: RE: Comments on=20
    =
"draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

    

    
 

    
Hi,

    
  =20
        Please refer to my answer inline to your=20
    comments.

    
 

    
Thanks,

    
Pranjal

    
 

    

    

    

    

    
From: l2vpn-bounces@ietf.org=20
    [mailto:l2vpn-bounces@ietf.org] On Behalf=20
    Of Jiang Yuan-long
Sent: Wednesday, May 13, 2009 =
4:36=20
    AM
To: =
Dutta, Pranjal K (Pranjal)
Cc: l2vpn@ietf.org
Subject: Comments on=20
    =
"draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt"

    
 

    

    
Hi=20
    Dutta,

    

    
 

    

    
I have a =
few=20
    comments on this draft:

    

    
 

    

    
1. From =
the=20
    description in the draft, it seems only one PE-ID is needed=20
    

    

    
for your =
mechanism.=20
    But in the definition of PE-ID TLV in section 4,=20
    

    

    
a list of =
one or=20
    more PE-ID may be included, but do we really need more=20
    

    

    
than one =
PE-ID=20
    element? Can you give some clues on its usage?
IMO, this =
definition is=20
    also in contradiction to the prior sentence=20
    

    

    
"The PE-ID =
TLV=20
    carries the unique identifier of a generic PW endpoint". =20
    

    

    
 

    
[Pranjal]

    
     =20
    Yes, that=92s correct. PE-ID TLV can accommodate a LIST of PE-ID =
Elements.=20
    Today implementations 

    
      =20
    can send a list of FEC Elements within a FEC TLV sent in the MAC =
flush=20
    message. A common network

    
      =20
    event may trigger failure of primary PWs for a set of VPLS instances =

    together, which requires to send mac flush =


    
      =20
    for all those instances. Sending an individual LDP MAC flush message =
per=20
    VPLS instance is sub-optimal and

    
      =20
    so MAC flush for a set of VPLS instances are bundled in a  =
single=20
    message. Same applies to optimized

    
      =20
    MAC flush with PE-ID as well.

    
 

    
 

    
 

    

    
2. The =
length of the=20
    FEC-128 specific PE-ID element is given as 2 octets,=20
    

    

    
should the =
correct=20
    length be 8?

    
 

    
[Pranjal]

    
     =20
    That=92s right. It=92s a typo. It should have been 8 octets. We will =
correct it=20
    in the next revision.

    
 

    

    
 

    

    
3. Maybe =
the FEC-129=20
    specific PE-ID Element needs another extra field=20
    

    

    
for PE =
address, as=20
    AII TLVs can only be null according to RFC 4762 in=20
    

    

    
section =
6.1.1, while=20
    AGI TLV can only give you information on VPLS=20
    

    

    
instance.=20
    

    
 

    
[Pranjal]

    
    =20
    RFC 4762 also specifies that use of non-null SAII and TAII would be=20
    addressed in future revision.

    
    =20
    Today, FEC 129 is used in VPLS provisioned with BGP-AD where =
SAII/TAII=20
    always carry valid 

    
    =20
    end-point identifiers (VS-ID) as per l2vpn signaling draft=20
    below.

    
 

    
   =20
     http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.t=
xt

    
 

    
    =20
    RFC 4762 kept a provision for NULL SAII/TAII if FEC 129 is used non =
BGP-AD=20
    deployments to replace FEC 128. 

    
    =20
    

    
    =20
    But if you see AGI definition in RFC 4446 (that carries vpls-id as =
per RFC=20
    4762), only one type is allocated to be used =


    
    =20
    in BGP-AD provisioned VPLS from  L2 VPN signaling draft.=20
    

    

    
 

    

    
4. I think =
this=20
    mechanism only works properly in a scenario where the=20
    

    

    
MTU-s, =
PE-1 and PE-2=20
    all play in harmony, otherwise, if MTU-s sends=20
    

    

    
out a =
RFC4762=20
    compatiable flushing msg, while PE-1 sends out a flushing=20
    

    

    
msg with =
PE-ID, then=20
    other PEs in the VPLS will process both msgs and=20
    

    

    
the result =
is=20
    flushing all MACs. So maybe this should be pointed out in=20
    

    

    
the =
applicability=20
    section.

    
 
[Pranjal]  Following is stated in the section =

 
5. Application of PE-ID =
TLV in Optimized MAC Flush 

    
 

    
 
   However the =
inclusion of the FEC-TLV should be  =

   based on what =
would be the desired effect should the PE-ID not be  =

   understood by =
the receiver.  In cases where the desired action when  =

   the PE-ID is =
not understood would be to behave as described in  =

   [RFC4762], =
then the FEC TLV SHOULD be included.  In cases where the  =

   desired =
action when the PE-ID is not understood is to take no  =

   action, then =
the FEC TLV SHOULD NOT be =
included.
 
 Are you suggesting for =
more explanation in that section?

    
 

    

    
 

    

    
5. Some =
random=20
    corrections:
s/ignored/ignored =
by/

    

    
page 6, =
"...So the=20
    MAC addresses that require flushing and relearning at=20
    

    

    
PE-2 are =
only the=20
    MAC addresses those have been learned on the PW=20
    

    

    
connected =
to PE-1."=20
    is redundant, maybe it is better to say "...So the MAC=20
    

    

    
addresses =
that=20
    require flushing and relearning at PE-2 are only those=20
    

    

    
MAC =
addresses=20
    learned on the PW connected to PE-1.".

    
 

    
[Pranjal] =
Sure, we=20
    would address this in the next =
revision.

    

    
 

    

    
Thanks

    

    
 

    

    
Yuanlong=20
    =
Jiang
<=
/BODY>

--Boundary_(ID_gOSwDVDfzGogQMHTCahBug)--

From root@core3.amsl.com  Thu Jun  4 14:30:02 2009
Return-Path: 
X-Original-To: l2vpn@ietf.org
Delivered-To: l2vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 204823A6DD6; Thu,  4 Jun 2009 14:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-12.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090604213002.204823A6DD6@core3.amsl.com>
Date: Thu,  4 Jun 2009 14:30:02 -0700 (PDT)
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Jun 2009 21:30:02 -0000

--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		: ARP Mediation for IP Interworking of Layer 2 VPN
	Author(s)	: E. Rosen, H. Shah, G. Heron, V. Kompella
	Filename	: draft-ietf-l2vpn-arp-mediation-12.txt
	Pages		: 30
	Date		: 2009-6-4
	
The VPWS service [L2VPN-FRM] provides point-to-point connections 
     between pairs of Customer Edge (CE) devices.  It does so by 
     binding two Attachment Circuits (each connecting a CE device 
     with a Provider Edge, PE, device) to a pseudowire (connecting 
     the two PEs).  In general, the Attachment Circuits must be of 
     the same technology (e.g., both Ethernet, both ATM), and the 
     pseudowire must carry the frames of that technology.  However, 
     if it is known that the frames' payload consists solely of IP 
     datagrams, it is possible to provide a point-to-point connection 
     in which the pseudowire connects Attachment Circuits of 
     different technologies. This requires the PEs to perform a 
     function known as "ARP Mediation". ARP Mediation refers to the 
     process of resolving Layer 2 addresses when different resolution 
     protocols are used on either Attachment Circuit. The methods 
     described in this document are applicable even when the CEs run 
     a routing protocol between them, as long as the routing protocol 
     runs over IP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-12.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-l2vpn-arp-mediation-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-6-4142824.I-D@ietf.org>


--NextPart--


From tochio@jp.fujitsu.com  Tue Jun  9 04:21:21 2009
Return-Path: 
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7FA43A6898 for ; Tue,  9 Jun 2009 04:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.601
X-Spam-Level: 
X-Spam-Status: No, score=-98.601 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6v4oTJpIvXB for ; Tue,  9 Jun 2009 04:21:20 -0700 (PDT)
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37]) by core3.amsl.com (Postfix) with ESMTP id 945613A67A3 for ; Tue,  9 Jun 2009 04:21:20 -0700 (PDT)
Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n59BLOf1032672 for  (envelope-from tochio@jp.fujitsu.com); Tue, 9 Jun 2009 20:21:25 +0900
Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 9636C45DD72 for ; Tue,  9 Jun 2009 20:21:24 +0900 (JST)
Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 6396545DE4F for ; Tue,  9 Jun 2009 20:21:24 +0900 (JST)
Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 2BDA11DB8047 for ; Tue,  9 Jun 2009 20:21:24 +0900 (JST)
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id C04711DB8041 for ; Tue,  9 Jun 2009 20:21:23 +0900 (JST)
Received: from vs.kawasaki.flab.fujitsu.co.jp (vs.kawasaki.flab.fujitsu.co.jp [10.25.192.38]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.2/8.14.2/080219-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id n59BLNpg006738 for ; Tue, 9 Jun 2009 20:21:23 +0900 (JST)
X-AuditID: 0a19c026-0000000600000215-8d-4a2e45b346ef
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vs.kawasaki.flab.fujitsu.co.jp (Symantec Mail Security) with ESMTP id 5A76A29820 for ; Tue,  9 Jun 2009 20:21:23 +0900 (JST)
Received: from [127.0.0.1] (dhcp78.dream.flab.fujitsu.co.jp [10.25.144.177]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.2/8.14.2/080219-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id n59BLMQ3006727 for ; Tue, 9 Jun 2009 20:21:23 +0900 (JST)
Message-ID: <4A2E45A8.9080306@jp.fujitsu.com>
Date: Tue, 09 Jun 2009 20:21:12 +0900
From: Yuji Tochio 
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: l2vpn@ietf.org
Subject: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: tochio@labs.fujitsu.com
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Jun 2009 11:21:21 -0000

Dear Editors and all,

FYI:
Here are my comments on this I-D through offline discussion with Yuji
(Mr. Kamite) though some had been posted by Greg

<>
I-D says:
As far as synchronization in a PSN environment is concerned,
different mechanisms can be considered to provide frequency and phase
clock

"clock" should be replaced by "synchronization"
Or in generic manner, "to provide frequency and phase clock " may be
removed.


<>
In general, It seems that contents of those clauses are overlapped
to each other so that editorial clean up should be required.

I think first these sentences are enough in 6.1.2 and the rest
of those in 6.1.2 with figure 2 should be merged to 6.4

A solution MUST support multiple sender topologies in one VPMS
instance, where a common receiver group is reachable from two or more
senders. This means that a solution needs to support having multiple
P2MP topologies in the backbone whose roots are located apart in a
common service. Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4 too).


And even if in clause 6.1.2., more clarification of Figure 2 should be
considered. The most important is to clarify AC3 & 4 or PE3 & PE4.
AC3 or 4 seems to share VPMS instance from either PE1 or
PE2. This point should be clarified.

For example, proposed is

Replace

Note that every receiver has only to have one AC connected to
each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4 too).

by

Note that every receiver has only to have one AC connected to
each PE to receive traffic. In the case of Figure 2, PE3 and PE4
should select traffic from PE1 or PE2 and AC3 and AC4 should be
single as attached to PE3 and PE4 respectively.
Thus a solution will also need to support protection
and restoration mechanism combining these multiple P2MP
topologies. (See section 6.4.2 too).

Of cource, this could be better in align with 6.4.1.2


<>
I-D says:
　The simplest way to accomplish this is to provide
　different VPMS instances for reverse traffic, i.e. a sender CE is a
　receiver of another VPMS instance.

Since there are some alternatives for this way such that providing
multiple VPWS (as reverse) or mp2p instance
So I ask for relaxing the descrption, i.e. replace "the simplest way" by
"the example"

I-D says:
Such bi-directional instances can be easily created if two distinct
ACs are provisioned for sending and receiving exclusively

I am not sure this assumption (= exclusively) is easiest.
I also ask for relaxing the descrption.


<>
In general, I think these subclauses should focus on
- Protetion/redundancy topology support as 6.1.4.1
- Traffic support in Protetion/redundancy as 6.1.4.1
As I wrote above, this is overlapped with 6.1.2
Figure 2 should be moved here and text should be merged with latter
of 6.1.2


<>
There are some areas that form protection/redundancy:
(1) (Sender) CE to (Sender/Ingress) PEs
(2) VPMS instances or inside PSN
(3) (Receiver) PEs to Receiver CE

This clause should indicate this point, where protection/redundancy
is required. (The use of dual home may miss (2))


<>
As I wrote above, this is overlapped with 6.1.2
Figure 2 should be moved to this clause here and text should be merged
with latter of 6.1.2


Regards,
Yuji Tochio



From dhanalakshmithavva@gmail.com  Mon Jun 15 10:39:55 2009
Return-Path: 
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F9F3A6860 for ; Mon, 15 Jun 2009 10:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.563
X-Spam-Level: 
X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tWOFXbviQdB for ; Mon, 15 Jun 2009 10:39:54 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id B09373A67E3 for ; Mon, 15 Jun 2009 10:39:54 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so1359884wfd.1 for ; Mon, 15 Jun 2009 10:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Fldp7flHXRWax5Ivly2TDJjLqJ75HMHppx05epxLwkeEKC8qvbWSf0JbGGSXVG+PKc tLWLKvHFXOpu74EcmYGE8iQ/sDS1OlssW2uLFnBkXJmEReR1brAGyoIoncpTgUgkp+T+ c0JpbfJ7iyhRi4hMchHORUzDwaP89p7f9zzmE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WKbA2oFUz0fxCKpoETNZa+JAHb4AFINERrCrT8jEjlVu7Ai5JY8/W+MPJw5dmmp3bf GcyKQLX0dywu7AEfXqJXdBRnVvQ9XcLWS0bsmQ7WbsuZkhzWnT0QK518JImqmOhkpqc6 J8ABzxDCLEVrKSKJZ+39uz+JmNX0xEA5bVawo=
MIME-Version: 1.0
Received: by 10.142.135.16 with SMTP id i16mr3411146wfd.86.1245087605130; Mon,  15 Jun 2009 10:40:05 -0700 (PDT)
Date: Mon, 15 Jun 2009 23:10:05 +0530
Message-ID: <2fec757c0906151040o73adba19t87ee9ca189e3192c@mail.gmail.com>
Subject: 'draft-ietf-l2vpn-vpls-pim-snooping-01.txt'
From: Dhana Lakshmi 
To: l2vpn@core3.amsl.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2009 17:39:55 -0000


From shane@castlepoint.net  Wed Jun 24 19:59:44 2009
Return-Path: 
X-Original-To: l2vpn@core3.amsl.com
Delivered-To: l2vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B7C3A6F91; Wed, 24 Jun 2009 19:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level: 
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPPNbfm8Dq7i; Wed, 24 Jun 2009 19:59:43 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7D6F028C407; Wed, 24 Jun 2009 19:59:39 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id E2C0E2684EA; Wed, 24 Jun 2009 20:59:26 -0600 (MDT)
Received: from mbpw.castlepoint.net (71-215-80-228.hlrn.qwest.net [71.215.80.228]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 24 Jun 2009 20:59:26 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.80.228; client-port=4790; syn-fingerprint=65535:55:1:64:M1452,N,W3,N,N,T,S; data-bytes=0
Message-Id: 
From: Shane Amante 
To: l3vpn@ietf.org, l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Results of Poll on BGP IPv4 Address Specific Extended Community
Date: Wed, 24 Jun 2009 20:59:11 -0600
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2009 02:59:44 -0000

Hello,

The following are the results and recommendation regarding the  
conflicting assignment for the BGP IPv4 Address Specific Extended  
Community, as per the following e-mail: .

The following are the results of the survey and subsequent questions  
I've asked of the respondents:
1)  We received a total of 4 responses.
2)  There are a total of 4 implementations, two for /each/ draft:
  + draft-ietf-l2vpn-signaling: 2 implementations
  + draft-ietf-l3vpn-2547bis-mcast-bgp: 2 implementations
3)  I've confirmed with all respondents that all of the above  
implementations have implemented the 0x010A BGP IPv4 Address Specific  
Extended Community.
4)  Finally, I've asked the implementers to list the date their  
implementations were "Generally Available", as a 'proxy' toward  
answering how long deployments have existed in the field, (responses  
anonymized as per the respondents request):
  a)  draft-ietf-l2vpn-signaling:
      - Implementation X: 1Q/2007 -- 2.5 years ago
      - Implementation Y: 1Q/2008 -- 1.5 years ago
      ============================================
      Average Age of Above Implementations: ~2 years old
  b)  draft-ietf-l3vpn-2547bis-mcast-bgp:
      - Implementation M: 3Q/2007 -- 2 years ago
      - Implementation N: 2Q/2009 -- 0 months ago
      ============================================
      Average Age of Above Implementations: ~1 years old

In summary:
- The "average age" of the implementations of draft-ietf-l2vpn- 
signaling is 1 year greater than draft-ietf-l3vpn-2547bis-mcast-bgp;  
and,
- draft-ietf-l2vpn-signaling was developed and released approximately  
6 months prior to draft-ietf-l3vpn-2547bis-mcast-bgp

Given the above, it is our recommendation that IANA should assign the  
0x010A BGP IPv4 Address Specific Extended Community to draft-ietf- 
l2vpn-signaling.  Furthermore, IANA should then allocate a new BGP  
IPv4 Address Specific Extended Community to draft-ietf-l3vpn-2547bis- 
mcast-bgp.

Finally, FWIW, we have informed the AD's of both WG's of the results  
of the survey and our recommendation contained above, as well, and  
have not heard any feedback that they disagree with the survey or our  
recommendation.

-shane