From kireeti@juniper.net Tue Jan 3 12:52:55 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA3911E810F for ; Tue, 3 Jan 2012 12:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toZmGodDGses for ; Tue, 3 Jan 2012 12:52:54 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 56A8711E810C for ; Tue, 3 Jan 2012 12:52:54 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTwNqniouqaVXK1hqe0m6DuFayW2zy2jX@postini.com; Tue, 03 Jan 2012 12:52:54 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 Jan 2012 12:50:54 -0800 From: Kireeti Kompella To: "Bocci, Matthew (Matthew)" Date: Tue, 3 Jan 2012 12:50:51 -0800 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: AczKWWJfJsYS1O0jQp6qioinhl/4rg== Message-ID: <0EDAB141-EE2B-4DE4-98BF-64697BAB33D3@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 03 Jan 2012 12:59:19 -0800 Cc: Kireeti Kompella , "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:52:55 -0000 Hi Matthew, On Sep 26, 2011, at 6:39 , Bocci, Matthew (Matthew) wrote: > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review. The purpose of the = review is to provide assistance to the Routing ADs. For more information ab= out the Routing Directorate, please see http://www.ietf.org/iesg/directorat= e/routing.html >=20 > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. Thanks for your review! See below for specific responses. > Document: draft-kompella-l2vpn-l2vpn-07.txt=20 > Reviewer: Matthew Bocci=20 > Review Date: 26-09-11=20 > IETF LC End Date: 26-09-11=20 > Intended Status: Informational >=20 > Summary: >=20 > I have some major concerns about this document, and some minor concerns t= hat I think should be resolved before the document is published.=20 >=20 >=20 > Comments: >=20 > Major Issues: >=20 > - Relationship to published and on-going work in the L2VPN and PWE3 worki= ng groups. This draft describes an alternative to the procedures for signal= ling PW labels used in pt-pt layer 2 VPNs (VPWS) and for auto-discovery of = endpoints participating in a L2VPN. The existing IETF-approved technologies= use LDP for the signalling (as described in RFC4447) and a combination of = that with BGP for auto-discovery (RFC6074). Since this draft describes an a= lternative that was rejected by the L2VPN WG, I would suggest adding a disc= laimer to the abstract and introduction, as per the recommendation of RFC57= 42, along the lines of "The IETF technology for this function is specified = in RFC6074 and RFC4447", in addition to the suggestions on the list that im= plementations of this draft must also comply to these RFCs. =20 I had a discussion with Andy Malis about this, and we came to this conclusi= on: "The draft currently has the following (2nd last para in the Introduction): It may be instructive to compare the approach in [RFC4447] with the one described here, keeping in mind that the solution described therein does not include auto-discovery. If it's acceptable to you, I can change that to: It may be instructive to compare the approach in [RFC4447] with the one described here, keeping in mind that the solution described therein does not include auto-discovery. Devices implementing the solution described in this document MUST also implement the approach in [RFC4447]. and move RFC 4447 to a normative reference." (which he agreed with) I could further change that to: It may be instructive to compare the approach in [RFC4447] and [RFC6074] (these are the IETF approved technologies for the functions described in this document, albeit using two separate protocols) with the one described here. Devices implementing the solution described in this document MUST also implement the approach in [RFC4447] and [RFC6074]. > - Section 9: IANA Considerations. This section requests a registry be cre= ated with standards action code points. I believe this is not appropriate a= s this is an informational draft. There has already been some discussion on= this point on the list, and that is noted as a part of this review. I'll be happy to change that to Expert Review. > - Section 5: Layer 2 VPN interworking. This section introduces a layer 2 = transport service for IP packet. However, just encapsulating IP packets bet= ween PEs will not be sufficient for a layer 2 VPN service between the CEs. = You also need to support something to allow L2 address resolution between t= he CEs, for example translation of the neighbour discover protocols (e.g. A= RP over Ethernet and InvARP over FR). Since this is describing the L2VPN, a= nd not just the PW encapsulation, I think this section should either say ho= w this is done with BGP (draft-ietf-l2vpn-arp-mediation uses LDP) or just s= ay it is out of scope of this particular draft and the L2 address is static= ally configured. Okay. > Minor Issues: >=20 > General: > - The draft mainly discussed pt-pt L2VPNs. The general term for this is V= PWS, but this term is not mentioned anywhere. It would help to clarify with= a statement in the introduction that this the subject of the draft. Okay. > - It would help if the figures showing the TLV structures showed the deta= iled structure, throughout, including bit fields, etc, in line with common = practice in IETF RFCs. I'll change Figure 2; I'm not sure this is particularly helpful. When you = say "throughout", what are other places are your referring to? > - 1. Introduction, 5th paragraph: > "Technically, the approach proposed here uses the concepts and > solution and described in [RFC4761], which describes VPLS, a > particular form of a Layer 2 VPN." >=20 > This reads as if RFC4761 is *the* description of VPLS. This is not the ca= se and the IETF has standardised two VPLS methods. I propose modifying this= to "=85which describes a method for VPLS,=85". Okay. > - 1.1 Terminology. Final paragraph. > "These will be referred to as Attachment > Circuits (ACs), following [RFC4447]. Similarly, the entity that > connects two attachment circuits across the Service Provider network > is called a pseudo-wire (PW)." >=20 > RFC3985 is probably the correct reference. > Also:=20 > s/pseudo-wire/pseudowire Okay. > - 1.2.5: PE Scaling > This section spends a lot of time discussing the scaling issues of L3 VPN= s. I am not sure why this is required in a BGP L2VPN draft, unless the issu= e is that because the control plane is the same, many of the same scaling c= onsiderations apply. Please can you clarify if this is true, and if so make= such a note in the text? The point of sections 1.2 and 1.3 is to give SPs and their customers things= to consider when choosing between a L2 or a L3 VPN. SPs in particular may= want to understand considerations for the PE's RIB and FIB in offering the= se two types of VPNs; the choice of BGP does influence that. More generally, these two sections were of help to VPN customers to underst= and the implications of L2 vs. L3 VPNs, as evidenced by their comments to m= e; as such, I would prefer to leave them in. > - 1.3: Advantages of Layer 3 VPNs > I do not think this adds any value to a draft on L2 VPNs. The content may= be useful elsewhere, but I think it would be better if this was removed fr= om this draft.=20 >=20 > - 3: Operation of Layer 2 VPNs > "In what follows, Frame Relay serves as the Layer 2 medium, and each > CE has multiple DLCIs to its PE, each to connect to another CE in the > VPN. If the Layer 2 medium were ATM, then each CE would have > multiple VPI/VCIs to connect to other CEs. " >=20 > I think I know what you mean by "medium" I.e. The underlying link layer, = where each group of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as = a demarkation of a L2VPN service between the PE and CE. If so, I think it w= ould help to add this clarification. Would it help if I changed "medium" to "media", which seems to be more comm= on, if somewhat non-grammatical? > - 6.3: IP-Only Layer 2 Interworking: >=20 > +----------------------------+ > | Tunnel | VPN | IP | VPN label is the > | Encap | Label | Packet | demultiplexing field > +----------------------------+ >=20 > Figure 3: Format of IP-only Layer 2 interworking packet >=20 > I think the field marked "Tunnel Encap" should instead be labelled "PSN T= ransport Header" or "MPLS Transport Header", in common with the other encap= sulation RFCs that you have referenced. Okay, PSN T H it is. Regards, Kireeti. > Best regards >=20 > Matthew From matthew.bocci@alcatel-lucent.com Wed Jan 4 02:41:49 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF12B21F8679 for ; Wed, 4 Jan 2012 02:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DccXAbuKYTFj for ; Wed, 4 Jan 2012 02:41:48 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4021F8670 for ; Wed, 4 Jan 2012 02:41:48 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q04AeA9g030651 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jan 2012 11:41:46 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 4 Jan 2012 11:41:30 +0100 From: "Bocci, Matthew (Matthew)" To: Kireeti Kompella Date: Wed, 4 Jan 2012 11:41:25 +0100 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: AczKzWrXwGk0DKC6SDCrNDv3S6Q0Kg== Message-ID: In-Reply-To: <0EDAB141-EE2B-4DE4-98BF-64697BAB33D3@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 10:41:49 -0000 Hi Kireeti, Thanks for your responses. Please see below. Regards Matthew On 03/01/2012 20:50, "Kireeti Kompella" wrote: >Hi Matthew, > >On Sep 26, 2011, at 6:39 , Bocci, Matthew (Matthew) wrote: > >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this >>draft. The Routing Directorate seeks to review all routing or >>routing-related drafts as they pass through IETF last call and IESG >>review. The purpose of the review is to provide assistance to the >>Routing ADs. For more information about the Routing Directorate, please >>see http://www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, >>it would be helpful if you could consider them along with any other IETF >>Last Call comments that you receive, and strive to resolve them through >>discussion or by updating the draft. > >Thanks for your review! See below for specific responses. > >> Document: draft-kompella-l2vpn-l2vpn-07.txt >> Reviewer: Matthew Bocci >> Review Date: 26-09-11 >> IETF LC End Date: 26-09-11 >> Intended Status: Informational >>=20 >> Summary: >>=20 >> I have some major concerns about this document, and some minor concerns >>that I think should be resolved before the document is published. >>=20 >>=20 >> Comments: >>=20 >> Major Issues: >>=20 >> - Relationship to published and on-going work in the L2VPN and PWE3 >>working groups. This draft describes an alternative to the procedures >>for signalling PW labels used in pt-pt layer 2 VPNs (VPWS) and for >>auto-discovery of endpoints participating in a L2VPN. The existing >>IETF-approved technologies use LDP for the signalling (as described in >>RFC4447) and a combination of that with BGP for auto-discovery >>(RFC6074). Since this draft describes an alternative that was rejected >>by the L2VPN WG, I would suggest adding a disclaimer to the abstract and >>introduction, as per the recommendation of RFC5742, along the lines of >>"The IETF technology for this function is specified in RFC6074 and >>RFC4447", in addition to the suggestions on the list that >>implementations of this draft must also comply to these RFCs. > >I had a discussion with Andy Malis about this, and we came to this >conclusion: > >"The draft currently has the following (2nd last para in the >Introduction): > > It may be instructive to compare the approach in [RFC4447] with the > one described here, keeping in mind that the solution described > therein does not include auto-discovery. > >If it's acceptable to you, I can change that to: > > It may be instructive to compare the approach in [RFC4447] with the > one described here, keeping in mind that the solution described > therein does not include auto-discovery. Devices implementing the > solution described in this document MUST also implement the approach > in [RFC4447]. > >and move RFC 4447 to a normative reference." > >(which he agreed with) > >I could further change that to: > > It may be instructive to compare the approach in [RFC4447] and [RFC6074] > (these are the IETF approved technologies for the functions described in > this document, albeit using two separate protocols) with the one > described here. Devices implementing the solution described in this > document MUST also implement the approach in [RFC4447] and [RFC6074]. This paragraph is fine with me. Thanks! > >> - Section 9: IANA Considerations. This section requests a registry be >>created with standards action code points. I believe this is not >>appropriate as this is an informational draft. There has already been >>some discussion on this point on the list, and that is noted as a part >>of this review. > >I'll be happy to change that to Expert Review. Fine with me. > >> - Section 5: Layer 2 VPN interworking. This section introduces a layer >>2 transport service for IP packet. However, just encapsulating IP >>packets between PEs will not be sufficient for a layer 2 VPN service >>between the CEs. You also need to support something to allow L2 address >>resolution between the CEs, for example translation of the neighbour >>discover protocols (e.g. ARP over Ethernet and InvARP over FR). Since >>this is describing the L2VPN, and not just the PW encapsulation, I think >>this section should either say how this is done with BGP >>(draft-ietf-l2vpn-arp-mediation uses LDP) or just say it is out of scope >>of this particular draft and the L2 address is statically configured. > >Okay. > >> Minor Issues: >>=20 >> General: >> - The draft mainly discussed pt-pt L2VPNs. The general term for this is >>VPWS, but this term is not mentioned anywhere. It would help to clarify >>with a statement in the introduction that this the subject of the draft. > >Okay. > >> - It would help if the figures showing the TLV structures showed the >>detailed structure, throughout, including bit fields, etc, in line with >>common practice in IETF RFCs. > >I'll change Figure 2; I'm not sure this is particularly helpful. When >you say "throughout", what are other places are your referring to? If you can just change Figure 2, then this is fine with me. > >> - 1. Introduction, 5th paragraph: >> "Technically, the approach proposed here uses the concepts and >> solution and described in [RFC4761], which describes VPLS, a >> particular form of a Layer 2 VPN." >>=20 >> This reads as if RFC4761 is *the* description of VPLS. This is not the >>case and the IETF has standardised two VPLS methods. I propose modifying >>this to "=8Awhich describes a method for VPLS,=8A". > >Okay. > >> - 1.1 Terminology. Final paragraph. >> "These will be referred to as Attachment >> Circuits (ACs), following [RFC4447]. Similarly, the entity that >> connects two attachment circuits across the Service Provider network >> is called a pseudo-wire (PW)." >>=20 >> RFC3985 is probably the correct reference. >> Also:=20 >> s/pseudo-wire/pseudowire > >Okay. > >> - 1.2.5: PE Scaling >> This section spends a lot of time discussing the scaling issues of L3 >>VPNs. I am not sure why this is required in a BGP L2VPN draft, unless >>the issue is that because the control plane is the same, many of the >>same scaling considerations apply. Please can you clarify if this is >>true, and if so make such a note in the text? > >The point of sections 1.2 and 1.3 is to give SPs and their customers >things to consider when choosing between a L2 or a L3 VPN. SPs in >particular may want to understand considerations for the PE's RIB and FIB >in offering these two types of VPNs; the choice of BGP does influence >that. > >More generally, these two sections were of help to VPN customers to >understand the implications of L2 vs. L3 VPNs, as evidenced by their >comments to me; as such, I would prefer to leave them in. OK=20 > >> - 1.3: Advantages of Layer 3 VPNs >> I do not think this adds any value to a draft on L2 VPNs. The content >>may be useful elsewhere, but I think it would be better if this was >>removed from this draft. >>=20 >> - 3: Operation of Layer 2 VPNs >> "In what follows, Frame Relay serves as the Layer 2 medium, and each >> CE has multiple DLCIs to its PE, each to connect to another CE in the >> VPN. If the Layer 2 medium were ATM, then each CE would have >> multiple VPI/VCIs to connect to other CEs. " >>=20 >> I think I know what you mean by "medium" I.e. The underlying link >>layer, where each group of DLCIs is an AC in the RFC3985 sense, plus >>DLCI acts as a demarkation of a L2VPN service between the PE and CE. If >>so, I think it would help to add this clarification. > >Would it help if I changed "medium" to "media", which seems to be more >common, if somewhat non-grammatical? OK. =20 > >> - 6.3: IP-Only Layer 2 Interworking: >>=20 >> +----------------------------+ >> | Tunnel | VPN | IP | VPN label is the >> | Encap | Label | Packet | demultiplexing field >> +----------------------------+ >>=20 >> Figure 3: Format of IP-only Layer 2 interworking packet >>=20 >> I think the field marked "Tunnel Encap" should instead be labelled "PSN >>Transport Header" or "MPLS Transport Header", in common with the other >>encapsulation RFCs that you have referenced. > >Okay, PSN T H it is. Thanks > >Regards, >Kireeti. > >> Best regards >>=20 >> Matthew From kireeti@juniper.net Tue Jan 10 10:46:35 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F192F21F8655 for ; Tue, 10 Jan 2012 10:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt0nadTdDYgX for ; Tue, 10 Jan 2012 10:46:34 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE221F8631 for ; Tue, 10 Jan 2012 10:46:34 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTwyHb6szhFNi5CbI9NNBj3zn0yDpmkqB@postini.com; Tue, 10 Jan 2012 10:46:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 10 Jan 2012 10:45:01 -0800 From: Kireeti Kompella To: "Bocci, Matthew (Matthew)" , "Andrew G. Malis" Date: Tue, 10 Jan 2012 10:45:00 -0800 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: AczPx/VsgHAoHauRSPSTq5SPSLgJng== Message-ID: <454C4294-7B0D-40F4-8400-B61A34E80A8F@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Jan 2012 11:08:17 -0800 Cc: Kireeti Kompella , "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:46:35 -0000 Hi Matthew, Andy: On Jan 4, 2012, at 2:41 , Bocci, Matthew (Matthew) wrote: >> I could further change that to: >>=20 >> It may be instructive to compare the approach in [RFC4447] and [RFC6074] >> (these are the IETF approved technologies for the functions described in >> this document, albeit using two separate protocols) with the one >> described here. Devices implementing the solution described in this >> document MUST also implement the approach in [RFC4447] and [RFC6074]. >=20 > This paragraph is fine with me. Thanks! A couple of comments came out of a discussion among the authors: a) The "MUST" in the above para should be a "must", as neither 4447 & 6074 = is required for implementing or interoperating with an implementation of th= is document. b) Making 4447 a normative reference likewise appears to be confusing ... o= ne does not have to read RFC 4447 in order to understand or implement this = document. (This is more for Andy rather than Matthew.) The suggestion is to make the MUST into a must and move 4447 back to an inf= ormative reference. Other than that, we are good to go. Kireeti. From matthew.bocci@alcatel-lucent.com Wed Jan 11 09:13:20 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D021F874A for ; Wed, 11 Jan 2012 09:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Gv6PEXDbHDD for ; Wed, 11 Jan 2012 09:13:20 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 32DF121F8747 for ; Wed, 11 Jan 2012 09:13:20 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0BHDHA8024683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jan 2012 18:13:18 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 11 Jan 2012 18:13:17 +0100 From: "Bocci, Matthew (Matthew)" To: Kireeti Kompella , "Andrew G. Malis" Date: Wed, 11 Jan 2012 18:13:15 +0100 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: AczQhE8sNQCUN1FDTOC9eDu1tYk2tw== Message-ID: In-Reply-To: <454C4294-7B0D-40F4-8400-B61A34E80A8F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:13:21 -0000 Hi Kireeti, I am fine with your proposed changes. I also discussed this with Andy, and he agrees. Best regards, Matthew On 10/01/2012 18:45, "Kireeti Kompella" wrote: >Hi Matthew, Andy: > >On Jan 4, 2012, at 2:41 , Bocci, Matthew (Matthew) wrote: > >>> I could further change that to: >>>=20 >>> It may be instructive to compare the approach in [RFC4447] and >>>[RFC6074] >>> (these are the IETF approved technologies for the functions described >>>in >>> this document, albeit using two separate protocols) with the one >>> described here. Devices implementing the solution described in this >>> document MUST also implement the approach in [RFC4447] and [RFC6074]. >>=20 >> This paragraph is fine with me. Thanks! > >A couple of comments came out of a discussion among the authors: > >a) The "MUST" in the above para should be a "must", as neither 4447 & >6074 is required for implementing or interoperating with an >implementation of this document. > >b) Making 4447 a normative reference likewise appears to be confusing ... >one does not have to read RFC 4447 in order to understand or implement >this document. (This is more for Andy rather than Matthew.) > >The suggestion is to make the MUST into a must and move 4447 back to an >informative reference. > >Other than that, we are good to go. > >Kireeti. > From adrian@olddog.co.uk Wed Jan 11 10:38:54 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8472811E80B7 for ; Wed, 11 Jan 2012 10:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-2.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWCVuuqG6hqv for ; Wed, 11 Jan 2012 10:38:52 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 65B8F11E80AC for ; Wed, 11 Jan 2012 10:38:52 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0BIcedq002488 for ; Wed, 11 Jan 2012 18:38:42 GMT Received: from 950129200 (adsl-62-167-106-87.adslplus.ch [62.167.106.87]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0BIcVsL002392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Jan 2012 18:38:38 GMT From: "Adrian Farrel" To: Date: Wed, 11 Jan 2012 18:38:28 -0000 Message-ID: <01c001ccd090$3c4848e0$b4d8daa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczQkA9fiPvxUPb6S1CdlwIAHqt+xA== Content-Language: en-gb Subject: [RTG-DIR] Welcome Les Ginsberg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:38:54 -0000 Please welcome Les to your august ranks. Deborah and Dan, please add Les to your processing. He is now subscribed to the mailing list. Les, you can see details of the Directorate (currently in the process of updating) at http://www.ietf.org/iesg/directorate/routing.html Cheers, Adrian From kireeti@juniper.net Wed Jan 11 11:28:24 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE24D21F875C for ; Wed, 11 Jan 2012 11:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz0HUH6KbK9f for ; Wed, 11 Jan 2012 11:28:24 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 38DBD21F8755 for ; Wed, 11 Jan 2012 11:28:23 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTw3iykEAlRCJj2Z6MohL4kz9vYXvdI/3@postini.com; Wed, 11 Jan 2012 11:28:24 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 11 Jan 2012 11:27:48 -0800 From: Kireeti Kompella To: "Bocci, Matthew (Matthew)" Date: Wed, 11 Jan 2012 11:27:46 -0800 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: AczQlxn/X7vajLycR5eygtpWhc11sQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Jan 2012 11:46:08 -0800 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "Andrew G. Malis" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:28:25 -0000 Thanks for the quick response! I should have an updated version tonight.=20 Kireeti=20 On Jan 11, 2012, at 9:13, "Bocci, Matthew (Matthew)" wrote: > Hi Kireeti, >=20 > I am fine with your proposed changes. I also discussed this with Andy, an= d > he agrees. >=20 > Best regards, >=20 > Matthew >=20 >=20 > On 10/01/2012 18:45, "Kireeti Kompella" wrote: >=20 >> Hi Matthew, Andy: >>=20 >> On Jan 4, 2012, at 2:41 , Bocci, Matthew (Matthew) wrote: >>=20 >>>> I could further change that to: >>>>=20 >>>> It may be instructive to compare the approach in [RFC4447] and >>>> [RFC6074] >>>> (these are the IETF approved technologies for the functions described >>>> in >>>> this document, albeit using two separate protocols) with the one >>>> described here. Devices implementing the solution described in this >>>> document MUST also implement the approach in [RFC4447] and [RFC6074]. >>>=20 >>> This paragraph is fine with me. Thanks! >>=20 >> A couple of comments came out of a discussion among the authors: >>=20 >> a) The "MUST" in the above para should be a "must", as neither 4447 & >> 6074 is required for implementing or interoperating with an >> implementation of this document. >>=20 >> b) Making 4447 a normative reference likewise appears to be confusing ..= . >> one does not have to read RFC 4447 in order to understand or implement >> this document. (This is more for Andy rather than Matthew.) >>=20 >> The suggestion is to make the MUST into a must and move 4447 back to an >> informative reference. >>=20 >> Other than that, we are good to go. >>=20 >> Kireeti. >>=20 >=20 From akr@cisco.com Tue Jan 24 14:58:15 2012 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA7E21F85B7 for ; Tue, 24 Jan 2012 14:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-4y53bx3cjo for ; Tue, 24 Jan 2012 14:58:14 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B952821F85B5 for ; Tue, 24 Jan 2012 14:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akr@cisco.com; l=3538; q=dns/txt; s=iport; t=1327445894; x=1328655494; h=message-id:date:from:mime-version:to:cc:subject; bh=3vYQpAk4diOFE4Vqz2sF8pAIk1oqZZ+vy2xwt5/+3BA=; b=VLFIFPHdg6ThaNL7y5JLiZefCNOTg5J97J76jjRQ3ndXe/etO2aDb+GK xJQnjV+BmnOm6tWji7Dg/XtODHVDEoX5oX9OBJjzvHetlZ4KJ8iAasBDT CxSdjISmRVx8ocJG0k18fBTiL1OctNVhWysCMn9/k+GOaZLguo9Cu4cpF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN02H0+rRDoI/2dsb2JhbABCrjWBBYILAWUBHxANFhgDAgECAVgBBwEBBRmHYpoOAZ4TiQQiAgEKAiKCXBcIBQQBFkMBAQgDAQESHYMcBIg/jF6Sbw X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208,217";a="25281061" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 24 Jan 2012 22:58:14 +0000 Received: from dhcp-171-70-224-102.cisco.com (dhcp-171-70-224-102.cisco.com [171.70.224.102]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0OMwDaS003368; Tue, 24 Jan 2012 22:58:13 GMT Message-ID: <4F1F3785.6070005@cisco.com> Date: Tue, 24 Jan 2012 14:58:13 -0800 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------000408050907070207020204" Cc: rtg-dir@ietf.org, draft-ietf-dime-pmip6-lr.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-dime-pmip6-lr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:58:15 -0000 This is a multi-part message in MIME format. --------------000408050907070207020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-dime-pmip6-lr-06.txt Reviewer: Abhay Roy Review Date: 1/24/2012 IETF LC End Date: 1/24/2012 Intended Status: Standards Track *Summary: * No issues found. This document is ready for publication. *Comments: * This draft is very clearly written and contains detailed description of proposed signaling flows and state machines. *Major Issues: * No major issues found. *Minor Issues: * No minor issues found. --------------000408050907070207020204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-dime-pmip6-lr-06.txt
Reviewer: Abhay Roy
Review Date: 1/24/2012
IETF LC End Date: 1/24/2012
Intended Status: Standards Track 

Summary:

No issues found. This document is ready for publication.

Comments:

This draft is very clearly written and contains detailed description of  proposed signaling flows and state machines.

Major Issues:

No major issues found.

Minor Issues:

No minor issues found.

--------------000408050907070207020204--