From IHussain@infinera.com Mon Jul 2 17:52:14 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F521F85A7 for ; Mon, 2 Jul 2012 17:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=-2.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6] 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 hNs2RuhuqhIq for ; Mon, 2 Jul 2012 17:52:12 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4995D21F85A5 for ; Mon, 2 Jul 2012 17:52:12 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0283.003; Mon, 2 Jul 2012 17:52:18 -0700 From: Iftekhar Hussain To: "curtis@occnc.com" Subject: RE: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework) Thread-Topic: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework) Thread-Index: AQHNTwNRmYB4eN29o0WExVbcU9uKP5cWygBg Date: Tue, 3 Jul 2012 00:52:16 +0000 Message-ID: References: <201206201639.q5KGdU6J074798@gateway.ipv6.occnc.com> In-Reply-To: <201206201639.q5KGdU6J074798@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: RTGWG X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 00:52:14 -0000 Curtis, Sorry for the delayed response. I was off work for few days. Please see in= line. -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Wednesday, June 20, 2012 9:40 AM To: Iftekhar Hussain Cc: curtis@occnc.com; RTGWG Subject: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework= ) Iftekhar, In a prior message my reply included: Actually it is not difficult in principle to provide cross references but it is somewhat time consuming. It also turns out that it isn't very useful. The reason is that documents covering many topics must consider certain groups of requirements such as backward compatibility and general network management. I did the exercise briefly, but didn't expand the text yet. I'll post diffs if it seems to add more clarity than bloat. Below are diffs that add cross references to the named groups of requiremen= ts in "Brief Review of Requirements" (Section 7.1). For each document or d= ocument topic called for in "Required Document Coverage" (Section 7.2) ther= e are cross references to those groups of requirements. Another change is dropping the subsection "Component Group Metric" and addi= ng the text (one paragraph) to the prior subsection "Component Link Groupin= g". Please comment on this change as well. The first diff chunk just adds comments that number the requirement groups.= The remaining long diff chunk includes most of "Required Document Coverag= e" (Section 7.2) where the diffs are mostly addition of comments giving jus= t the requirement groups cited and then a brief paragraph making the citati= on, referring directly to the requirement group names. =20 The diffs at the very end drop the cross references to the "Component Group= Metric" subsection (anchor=3Dr.metric) which always accompany a cross refe= rence to the "Component Link Grouping" subsection (r.bundle), the subsectio= n that this paragraph was combined into. Again, if you thik this adds more clarity rather than added bloat, then I w= ill keep the diffs. Otherwise, I will back out the diffs. Now that I've done this I can see where this could be a useful reminder to = authors and reviewers of specific later documents, somewhat like a checklis= t that needs to be considered to see if the document completely addresses t= he requirements relevant to the topic. If this is considered very useful, then I'll change the requirement groups = from a list with named entries into subsections so that I can use the XML a= nchor and xref to automate the cross references. [Iftekhar] I believe it adds clarity. Also adding a checklist sounds like a= good idea. Thanks, Iftekhar Curtis cvs diff: Diffing . Index: draft-so-yong-rtgwg-cl-framework.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-= framework.xml,v retrieving revision 1.15 diff -w -U20 -r1.15 draft-so-yong-rtgwg-cl-framework.xml --- draft-so-yong-rtgwg-cl-framework.xml 15 Jun 2012 19:34:10 -0000 1.15 +++ draft-so-yong-rtgwg-cl-framework.xml 20 Jun 2012 16:11:58 -0000 @@ -1875,91 +1875,100 @@ This section first summarizes and groups requirements. A set of documents coverage groupings are proposed with existing works-in-progress noted where applicable. The set of extensions are then grouped by protocol affected as a convenience to implementors. =20
=20 The following list provides a categorization of requirements specified in along with a short phrase indication what topic the requirement covers. =20 + FR#1 (routing summarization), FR#20 (composite link may be a component of another composite link) + FR#2 (restoration speed meeting NPO), FR#12 (minimally disruptive load rebalance), DR#6 (fast convergence), DR#7 (fast worst case failure convergence) + FR#3 (automatic load distribution), FR#5 (must not oscillate), FR#11 (dynamic placement of flows), FR#12 (minimally disruptive load rebalance), FR#13 (bounded rearrangement frequency), FR#18 (flow placement must satisfy NPO), FR#19 (flow identification finer than per top level LSP), MR#6 (operator initiated flow rebalance) + FR#4 (smooth incremental deployment), FR#6 (management and diagnostics must continue to function), DR#1 (extend existing protocols), DR#2 (extend LDP, no LDP TE) + FR#7 (expose lower layer measured delay), FR#8 (precision of latency reporting), FR#9 (limit latency on per LSP basis), FR#15 (minimum delay path), FR#16 (bounded delay path), FR#17 (bounded jitter path) + FR#10 (admission control, preemption), FR#14 (packet ordering), FR#21 (ingress specification of path), FR#22 (path symmetry), DR#3 (IP and LDP traffic), MR#3 (management specification of path) + DR#4 (IGP extensions allowed within single domain), DR#5 (IGP extensions disallowed in multiple domain case) + MR#1 (polling, configuration, and notification), MR#2 (activation and de-activation) + MR#4 (path trace), MR#5 (connectivity verification) =20 The above list is not intended as a substitute for , but rather as a concise grouping and reminder or requirements to serve as a means of more easily determining requirements coverage of a set of protocol documents. =20
=20
=20 @@ -1990,412 +1999,674 @@ An index is needed that if included in an ERO would indicate the need to place the LSP on any one component within the group. A second index is needed that if included in an ERO would indicate the need to balance flows within the LSP across all components of the group. This is equivalent to the "all-ones" component for the entire bundle. can be extended to include multipath treatment capabilities. An ISIS solution is also needed. An extension of RSVP-TE signaling is needed to indicate multipath treatment preferences. =20 -
+ + If a component group is allowed to support all of the + parameters of a link bundle, then a group TE metric would + be accommodated. This can be supported with the component + TLV (C-TLV) defined in . + =20 -
+ =20 - If a group is allowed to support all of the parameters of - a link bundle, then a group TE metric would be - accommodated. This can be supported with the component - TLV (C-TLV) defined in . + The primary focus of this document, among the sets of + requirements listed in + is the "routing information aggregation" set of + requirements. The "restoration speed", "backward + compatibility and migration", and "general network + management" requirements must also be considered. =20
=20
=20 A extension is needed in the IGP-TE advertisement to support delay and delay variation for links, link bundles, and forwarding adjacencies. Whatever mechanism is described must take precautions that insure that route oscillations cannot occur. may be a good starting point. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "delay and delay variation" set of requirements. + The "restoration speed", "backward compatibility and + migration", and "general network management" requirements + must also be considered. + +
=20
=20 Path selection and admission control changes must be documented in each document that proposes a protocol extension that advertises a new capability or parameter that must be supported by changes in path selection and admission control. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are the "load distribution, stability, minimal disruption" + and "admission control, preemption, traffic engineering" + sets of requirements. The "restoration speed" and "path + determination, connectivity verification" requirements + must also be considered. The "backward compatibility and + migration", and "general network management" requirements + must also be considered. + +
=20
=20 FR#11 explicitly calls for dynamic load balancing similar to existing adaptive multipath. In implementations where flow identification uses a coarse granularity, the adjustments would have to be equally coarse, in the worst case moving entire LSP. The impact of flow identification granularity and potential adaptive multipath approaches may need to be documented in greater detail than provided here. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are the "restoration speed" and the "load distribution, + stability, minimal disruption" sets of requirements. The + "path determination, connectivity verification" + requirements must also be considered. The "backward + compatibility and migration", and "general network + management" requirements must also be considered. + +
=20
=20 IGP-TE and RSVP-TE extensions are needed to support frequency of load balancing rearrangement called for in FR#13, and FR#15-FR#17. Constraints are not defined in RSVP-TE, but could be modeled after administrative attribute affinities in RFC3209 and elsewhere. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "load distribution, stability, minimal disruption" + set of requirements. The "path determination, + connectivity verification" must also be considered. The + "backward compatibility and migration" and "general + network management" requirements must also be considered. + +
=20
=20 Lower layer to upper layer communication called for in FR#7 and FR#20. This is addressed for a subset of parameters related to packet ordering in where layers are MPLS. Remaining parameters, specifically delay and delay variation, need to be addressed. Passing information from a lower non-MPLS layer to an MPLS layer needs to be addressed, though this may largely be generic advice encouraging a coupling of MPLS to lower layer management plane or control plane interfaces. This topic can be addressed in each document proposing a protocol extension, where applicable. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "restoration speed" set of requirements. The + "backward compatibility and migration" and "general + network management" requirements must also be considered. + +
=20
=20 A document is needed to define extensions supporting various packet ordering requirements, ranging from requirements to preservce microflow ordering only, to requirements to preservce full LSP ordering (as in MPLS-TP). This is covered by and . =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are the "admission control, preemption, traffic + engineering" and the "path determination, connectivity + verification" sets of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + +
=20
=20 The behavior of hash methods used in classic multipath needs to be described in terms of FR#12 which calls for minimally disruptive load adjustments. For example, reseeding the hash violates FR#12. Using modulo operations is significantly disruptive if a link comes or goes down, as pointed out in . In addition, backwards compatibility with older hardware needs to be accommodated. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "load distribution, stability, minimal disruption" + set of requirements. + +
=20
=20 Protocol extensions are needed to support dynamic load balance as called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic placement of flows). Currently path symmetry can only be supported in link bundling if the path is pinned. When a flow is moved both ingress and egress must make the move as close to simultaneously as possible to satisfy FR#22 and FR#12 (minimally disruptive load rebalance). If a group of flows are identified using a hash, then the hash must be identical on the pair of LSR at the endpoint, using the same hash seed and with one side swapping source and destination. If the label stack is used, then either the entire label stack must be a special case flow identification, since the set of labels in either direction are not correlated, or the two LSR must conspire to use the same flow identifier. For example, using a common entropy label value, and using only the entropy label in the flow identification would satisfy this requirement. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are the "load distribution, stability, minimal disruption" + and the "admission control, preemption, traffic + engineering" sets of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. Path + symetry simplifies support for the "path determination, + connectivity verification" set of requirements, but with + significant complexity added elsewhere. + +
=20
=20 A separate document providing analysis of performance, scalability, and stability impacts of changes may be needed. The topic of traffic adjustment oscillation must also be covered. If sufficient coverage is provided in each document covering a protocol extension, a separate document would not be needed. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "restoration speed" set of requirements. This is + not a simple topic and not a topic that is well served by + scattering it over multiple documents, therefore it may be + best to put this in a separate document and put citations + in documents called for in + , + , + , + , + , + , + , and + . + Citation may also be helpful in + , and + . + +
=20
=20 A document is needed to define the use of measurements native IP and native LDP traffic levels to reduce link advertised bandwidth amounts. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are the "load distribution, stability, minimal disruption" + and the "admission control, preemption, traffic + engineering" set of requirements. The "path + determination, connectivity verification" must also be + considered. The "backward compatibility and migration" + and "general network management" requirements must also be + considered. + +
=20
=20 Extending LDP is called for in DR#2. LDP can be extended to couple FEC admission control to local resource availability without providing LDP traffic engineering capability. Other LDP extensions such as signaling a bound on microflow size and LDP LSP requirements would provide useful information without providing LDP traffic engineering capability. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "admission control, preemption, traffic + engineering" set of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + +
=20
=20 PW extensions such as signaling a bound on microflow size and PW requirements would provide useful information. =20 + + + + The primary focus of this document, among the sets of + requirements listed in + is the "admission control, preemption, traffic + engineering" set of requirements. The "backward + compatibility and migration" and "general network + management" requirements must also be considered. + +
=20
=20 DR#5 calls for Composite Link to span multiple network topologies. Component LSP may already span multiple network topologies, though most often in practice these are LDP signaled. Component LSP which are RSVP-TE signaled may also span multiple network topologies using at least three existing methods (per domain , BRPC , PCE ). When such component links are combined in a Composite Link, the Composite Link spans multiple network topologies. It is not clear in which document this needs to be described or whether this description in the framework is sufficient. The authors and/or the WG may need to discuss this. DR#5 mandates that IGP-TE extension cannot be used. This would disallow the use of or in conjunction with . =20 + + + + The primary focus of this document, among the sets of + requirements listed in + are "single vs multiple domain" and "admission control, + preemption, traffic engineering". The "routing + information aggregation" and "load distribution, + stability, minimal disruption" requirements need attention + due to their use of the IGP in single domain Composite + Link. Other requirements such as "delay and delay + variation", can more easily be accomodated by carrying + metrics within BGP. The "path determination, connectivity + verification" requirements need attention due to + requirements to restrict disclosure of topology + information across domains in multi-domain deployments. + The "backward compatibility and migration" and "general + network management" requirements must also be considered. + +
=20 =20
=20 Note to co-authors: This section needs to be reduced to an empty section and then removed. =20 The following topics in the requirements document are not addressed. Since they are explicitly mentioned in the requirements document some mention of how they are supported is needed, even if to say nother needed to be done. If we conclude any particular topic is irrelevant, maybe the topic should be removed from the requirement document. At that point we could add the management requirements that have come up and were missed. L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC 4761, RFC 4762 and VPMS VPMS Framework (draft-ietf-l2vpn-vpms-frmwk-requirements). It is not clear what additional Composite Link requirements these references imply, if any. If no additional requirements are implied, then these references are considered to be informational only. + Migration may not be adequately covered in . It might also be necessary to - say more here on performance, scalability, and - stability. Comments on this from co-authors or the WG? + say more here on performance, scalability, and stability + as it related to migration. Comments on this from + co-authors or the WG? + We may need a performance section in this document to specifically address #DR6 (fast convergence), and #DR7 (fast worst case failure convergence), though we do already have scalability discussion. The performance section would have to say "no worse than before, except were there was no alternative to make it very slightly worse" (in a bit more detail than that). It would also have to better define the nature of the performance criteria. + =20
=20
=20 As an aid to implementors, this section summarizes requirement coverage listed in by protocol or LSR functionality affected. =20 Some documentation may be purely informational, proposing no changes and proposing usage at most. This includes , , , and . =20 may require a new protocol. =20
=20 Many of the changes listed in require IGP-TE changes, though most are small extensions to provide additional information. This set includes , , , , , and . An adjustment to - existing advertised parameters is suggested in . + target=3D"r.delay" />, , + , and . An adjustment to existing advertised parameters is + suggested in . =20
=20
=20 The only suggestion of pseudowire (PW) extensions is in . =20
=20
=20 Potential LDP extensions are described in . =20
=20
=20 RSVP-TE protocol extensions are called for in , , , , and - . + target=3D"r.bundle" />, , + , and . =20
=20
=20 calls for path selection to be addressed in individual documents that require change. These changes would include those proposed in , , , , , and . =20
=20
=20 When a change is needed to path selection, a corresponding change is needed in admission control. The same set of sections applies: , , , , and . - Some resource changes such as a link delay change might - trigger preemption. The rules of preemption remain - unchanged, still based on holding priority. + target=3D"r.delay" />, , and + . Some resource changes such as + a link delay change might trigger preemption. The rules + of preemption remain unchanged, still based on holding + priority. =20
=20
=20 The following describe either the state of the art in flow identification and traffic balance or propose changes: , , , and . =20
=20
=20 From bashandy@cisco.com Mon Jul 9 11:29:49 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220C711E8102; Mon, 9 Jul 2012 11:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 KfvmittRKzX5; Mon, 9 Jul 2012 11:29:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0A36E11E80D0; Mon, 9 Jul 2012 11:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=8966; q=dns/txt; s=iport; t=1341858613; x=1343068213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=MKDnFXkbmi02ByGRf9igwLo1MRPv75pc4aU3FSSdQ00=; b=fIAeuVwl2JhJ7/uU59VLHkI9vVXfSPuaDBUvaGwzXI9dVXHxFke1fVLY hlcv+8wehnXvac/E58VhoBRQFC/f1ZuU/EjxTC0nUCq3RZp64xwlwk1WK Qh8RaDrFoKynrksjWm1kEbf/oFT97i3GxOu5LHJiujVsy4bmG8OYcQQtJ s=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,553,1336348800"; d="asc'?scan'208,217";a="51465529" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Jul 2012 18:30:13 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q69IUD3g028887; Mon, 9 Jul 2012 18:30:13 GMT Message-ID: <4FFB2330.4020809@cisco.com> Date: Mon, 09 Jul 2012 11:30:08 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" , rtgwg@ietf.org Subject: Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> In-Reply-To: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD26DE787B37BEC29F385B464" Cc: "Nagendra Kumar \(naikumar\)" , "Maciek Konstantynowicz \(mkonstan\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:29:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD26DE787B37BEC29F385B464 Content-Type: multipart/alternative; boundary="------------060306050304010908050809" This is a multi-part message in MIME format. --------------060306050304010908050809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The draft proposes a new method for BGP FRR. The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back All comments are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date: Sun, 8 Jul 2012 07:05:43 -0700 From: To: CC: , A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. Filename: draft-bashandy-bgp-frr-vector-label Revision: 00 Title: BGP FRR Protection against Edge Node Failure Using Vector Labels= Creation date: 2012-07-07 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-bashandy-bgp-f= rr-vector-label-00.txt Status: http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-v= ector-label Htmlized: http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector= -label-00 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity or complicating provisioning effort. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes, (3) re-routing traffic without waiting for re-convergence must not cause loops, (4) provisioning effort should be kept at minimum, and (5) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the label stack on the packet must allow the repair PEj to correctly forward the packet and (7) there must not be any need to perform more than one label lookup on any edge or core router during steady state = =20 The IETF Secretariat --------------060306050304010908050809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The draft proposes a new method for BGP FRR.

The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back

All comments are most welcomed

Thanks

Ahmed

-------- Original Message --------
Sub= ject: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt
Dat= e: Sun, 8 Jul 2012 07:05:43 -0700
Fro= m: <internet-drafts@ietf.org>
To:= <bashandy@cisco.com>
CC:= <naikumar@cisco.com>, <mkonstan@cisco.com><= /td> 


A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.t=
xt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.

Filename:	 draft-bashandy-bgp-frr-vector-label
Revision:	 00
Title:		 BGP FRR Protection against Edge Node Failure Using Vector Labels=

Creation date:	 2012-07-07
WG ID:		 Individual Submission
Number of pages: 32
URL:             http:/=
/www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt<=
/a>
Status:          http://datatracke=
r.ietf.org/doc/draft-bashandy-bgp-frr-vector-label
Htmlized:        http://tools.ietf.o=
rg/html/draft-bashandy-bgp-frr-vector-label-00


Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/m via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it is desirable for a core router "P"
carrying traffic to the failed edge router PEi to immediately restore
traffic by re-tunneling packets originally tunneled to PEi and
destined to the prefix P/m to one of the other edge routers that
advertised P/m, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity or complicating provisioning
effort. Thus (1) a core router should not be required to learn any
BGP prefix, (2) the size of the forwarding and routing tables in the
core routers should be independent of the number of BGP prefixes, (3)
re-routing traffic without waiting for re-convergence must not cause
loops, (4) provisioning effort should be kept at minimum, and (5)
there should be no restrictions on what edge routers advertise what
prefixes. For labeled prefixes, (6) the label stack on the packet
must allow the repair PEj to correctly forward the packet and (7)
there must not be any need to perform more than one label lookup on
any edge or core router during steady state

                                                                         =
        =20


The IETF Secretariat



--------------060306050304010908050809-- --------------enigD26DE787B37BEC29F385B464 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFP+yM0+G19kFA5zIYRAhPdAJ4tf3wMVCY92lLCJGgEyEIkEISUPwCfWpFY 7OLjd9yiNrGatlan+uWWtU8= =WHrf -----END PGP SIGNATURE----- --------------enigD26DE787B37BEC29F385B464-- From akatlas@gmail.com Tue Jul 10 11:26:27 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5121F86CF for ; Tue, 10 Jul 2012 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 U1sVNAd9KYWG for ; Tue, 10 Jul 2012 11:26:27 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D321F8694 for ; Tue, 10 Jul 2012 11:26:26 -0700 (PDT) Received: by ggnc4 with SMTP id c4so334776ggn.31 for ; Tue, 10 Jul 2012 11:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=namdvsPUFpjUFFfoMJTHTs1HH3WprnlO0E4/KkpiDQ0=; b=nKZiB3Na2fcUELg8VzayARORz6GubuhM23vBsGKmfS01NzYGk7yVxjW97d3c5mbZiY kYWbLA5eMnMmQhChYFEHB3RDzFfydrsyyGRUCq9ncO3JdL1Wv0VNMH4Lvi+Dr9k/PYWM e0Oaoy9bQyO0K78PGh3e7AEBOImz/pV969LHflAUrBxLYUB8nkDxCIIJOtl5/y+P22Oa s6qjMZAidTBkPkVdRNpCK4Zp2Ux9LUSlfO3j1JI/Xg8kUZ523wZQB1GRkEo7Bind7UxU sXKFxbJicWGHhPGXLZL//rQqE3w76xNOYDCoLpq3ckJUy6FyOm94ggZuBjk/zREN3m8v aUWA== MIME-Version: 1.0 Received: by 10.42.163.4 with SMTP id a4mr23628579icy.27.1341944814473; Tue, 10 Jul 2012 11:26:54 -0700 (PDT) Received: by 10.50.6.193 with HTTP; Tue, 10 Jul 2012 11:26:54 -0700 (PDT) Date: Tue, 10 Jul 2012 14:26:54 -0400 Message-ID: Subject: drafts accepted as WG drafts From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:26:28 -0000 Based on the polled responses, draft-karan-mofrr-02 draft-so-yong-rtgwg-cl-framework-06 draft-symmvo-rtgwg-cl-use-cases-01 are all accepted as RTGWG drafts. As soon as possible (once the tools accept -00 drafts again), please republish them as WG drafts named: draft-ietf-rtgwg-mofrr draft-ietf-rtgwg-cl-framework draft-ietf-rtgwg-cl-use-cases The polled responses were generally fairly low - more readers and comments would be appreciated. Alia From akatlas@gmail.com Tue Jul 10 11:31:52 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD9B11E80D2 for ; Tue, 10 Jul 2012 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0QceDuwg33-M for ; Tue, 10 Jul 2012 11:31:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC0811E80A2 for ; Tue, 10 Jul 2012 11:31:22 -0700 (PDT) Received: by yenq13 with SMTP id q13so334302yen.31 for ; Tue, 10 Jul 2012 11:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hDWAXJaMZhsHvq39Cg/gMtT8m67vNUAHtLMvwTmpRxU=; b=0s6ZpGVRj5Q+/UejteZbtY6mCcwyavZNwIG9m1Ahs/TlGR6h8JTaj+a9WU5eOPa+dH /U1Ro7orjvND+SiNw/Om+uSpOkVDei/TUpbyWsDi429EHmM4wxPtTMXZKfu9jUZcSnbc OGCTs4eutPHWLOOVDzRlhzpFWuSVnwBRsbP8FSR9PWyGnxqzDlDCMsWy58F8ykKyjbP3 Vm+gYLVi2qpG4D6x7MIp4f2OQAD5XfKKlcb0rvwLmxUtPePG0adKWD4blpP2Fj33xCab Q+AYZAA6WZNAGdX/vEdaiEY8X9hRVzL+n2hNXdERm+WvsIUhIDLrE2xTGnYxZ/eJLjne IYWQ== MIME-Version: 1.0 Received: by 10.50.178.102 with SMTP id cx6mr12387981igc.14.1341945110252; Tue, 10 Jul 2012 11:31:50 -0700 (PDT) Received: by 10.50.6.193 with HTTP; Tue, 10 Jul 2012 11:31:50 -0700 (PDT) Date: Tue, 10 Jul 2012 14:31:50 -0400 Message-ID: Subject: agenda items for IETF 84 RTGWG From: Alia Atlas To: rtgwg@ietf.org, alvaro.retana@hp.com Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:31:53 -0000 RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50 (Afternoon Session II). Please send all agenda requests to myself and Alvaro. Presentations are requested before IETF starts (by Friday July 27). Thanks, Alia From robert@raszuk.net Sun Jul 15 02:46:20 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B935A21F85E3 for ; Sun, 15 Jul 2012 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_INVITATION=-2] 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 bLEgr-rXPylm for ; Sun, 15 Jul 2012 02:46:19 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9668D21F8565 for ; Sun, 15 Jul 2012 02:46:19 -0700 (PDT) Received: (qmail 31232 invoked by uid 399); 15 Jul 2012 09:46:59 -0000 Received: from unknown (HELO ?10.53.7.165?) (pbs:robert@raszuk.net@80.187.201.11) by mail1310.opentransfer.com with ESMTPM; 15 Jul 2012 09:46:59 -0000 X-Originating-IP: 80.187.201.11 Message-ID: <5002918F.3010107@raszuk.net> Date: Sun, 15 Jul 2012 02:46:55 -0700 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ahmed Bashandy Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> In-Reply-To: <4FFB2330.4020809@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 09:46:20 -0000 Hi Ahmed, Encouraged by your kind invitation let me first try to clarify few things reg the proposal. > ii. If "rL" is per-VRF, then pop *two* labels and forward the > packet based on the contents under the two popped labels I am afraid this does not work. VRF lookup on any rPE would still contain the the original best path towards the PE which failed. This is for any AFI/SAFI. Remember the BGP best path has not executed yet to eliminate the BGP best path which can be influenced by local preference or MED. Your case mistakenly assumed that locally received EBGP route always win, however this is not the case in BGP. You re referring to per VRF lookup option in many places of the draft - that needs to be deleted. Only per-CE label where "last hop" rPE does not perform IP lookup may work. > a. Acting as a rPE, PE1 allocates (on per-CE basis) and > advertises a repair label rL1=3100 with the prefixes > 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers Another issue in your proposal is that you assume that rPE will be a protecting PE for everyone. Again in BGP this is not the case as during best path iPEs will consider BGP next hop metric. Therefor for the identical destination the same PE can be rPE for some iPEs while in the same time it can be pPE for other iPEs. I do not see how in any BGP today you could signal both types of labels (even if the label is per CE). > . When does the penultimate hop stop advertising pNH as its > own prefix? The penultimate hop should continue to > advertise pNH long enough for iPE's to re-converge. > Advertising pNH longer than necessary is harmless because > iPE's would have already re-converged to a new BGP next- > hop and hence no traffic will be attracted to the non- > existing pNH. The specific period length can be subject > to configuration but the default value may be in the > order of 2-3 minutes I really do not think this section is necessary. I do not understand how we can stop advertising pNH from PHP node. If we stop when do we start again ? > 3. Penultimate Hop > a. Receives a packet with top label bound to pNH > b. Pops *three* labels *all the time*. Are you sure that current LSRs can pop more then one label on the stack? Since the early days of MPLS it was my understanding that except the special labels (null labels) MPLS LSRs do not POP more then one label. I am not sure if this is spelled out in any of the MPLS specifications, but I think it would be great to have some sort of assurance that this is doable not only in theory but also in practice > 3. Overview of the BGP FRR using Vector Labels in an IP Core > > This section describes the BGP FRR using vector labels solution in an > IP core for both labeled (AFI/SAFI 1/4, 2/4, 1/128, and 2/128) and > unlabeled (AFI/SAFI 1/1, 2/1, 1/2, and 2/2) protected prefixes. + > The pPE needs to advertise the mapping (bgpNH,pNH). iPE also needs to > allocate a vector label for each known rPE and advertise the mapping > (pNH,rNH,vL) I am not following this section. Let's consider SAFI 1/1. What is the "rL" if I am not running MPLS ? Same for vector label "vL" ? What protocol distributes those labels ? > a. Assume that PE0 uses "Loopback0" as the BGP next-hop, PE0 > automatically picks Loopback2 as the pNH. As such PE0 > advertises (bgpNH,pNH)=(1.1.1.1,1.1.1.2) to all iBGP peers > including the iPE PE11. When you say that PE0 advertises pair of next hops ? How is this encoded ? What is the semantics of this encoding ? > a. On receiving the repair labels 3100 and 3200 from PE1 and > PE2, respectively, PE0 detects that there are two rPEs: PE1 > and PE2. AS such PE0 assigns two vector labels vL1 = 1100 > and vL2 = 1200 to PE1 and PE2, respectively How can PE0 receive the repair labels from PE1 and PE2 if we take SAFI 1/1 and no add-paths ? Anyhow we do not even know that the rL is for SAFI 1/1 yet :) For VPNs you assume different RD per VRF. That still does not work as I mentioned above. The rPE will be a primary PPE for some ingress PEs. Best regards, R. > Hi, > > The draft proposes a new method for BGP FRR. > > The approach is very scalable as it does not require injecting any > prefixes into the core, no re-advertisement of BGP prefixes, and no > state replication. At the same time, it is transparent to the operator > in the sense that if it is enabled by default, there is no need for > human intervention due to any reason including internal and external > topology changes or even when switching from MPLS to IP core and back > > All comments are most welcomed > > Thanks > Ahmed From bashandy@cisco.com Mon Jul 16 16:28:14 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7CE11E82BD; Mon, 16 Jul 2012 16:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8] 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 Q0ofwMvZkE6B; Mon, 16 Jul 2012 16:28:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8D82211E82B8; Mon, 16 Jul 2012 16:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=10132; q=dns/txt; s=iport; t=1342481336; x=1343690936; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0VsWR3gt2cbZvxY6OpFlkrJbg3UpJivs9Ttp5FS+aXU=; b=iu5uvJIaddmKUiWEvVjsB6qJf2aycB/44i2rJdzYb+Q0Qkxt6JodAG29 3PjxI5H8gT0V9ApEvELuCQIvdYw9igyN19LzKZL7QapvbbaK2dru/9KMg wbWDKLlfltm+4FWd+bgox3NH6dRDdALe5NGiJHH3zIeoVplMcN+DU+GUt 8=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="asc'?scan'208";a="49535936" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 23:28:56 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6GNSupR031241; Mon, 16 Jul 2012 23:28:56 GMT Message-ID: <5004A3B2.4040606@cisco.com> Date: Mon, 16 Jul 2012 16:28:50 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> In-Reply-To: <5002918F.3010107@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEBB26429791D2718491B2673" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:28:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEBB26429791D2718491B2673 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks a lot for the comments. See Inline. Look for "AB:" Thanks Ahmed On 7/15/2012 2:46 AM, Robert Raszuk wrote: > Hi Ahmed, > > Encouraged by your kind invitation let me first try to clarify few > things reg the proposal. > >> ii. If "rL" is per-VRF, then pop *two* labels and forward the >> packet based on the contents under the two popped labels > > I am afraid this does not work. > > VRF lookup on any rPE would still contain the the original best path > towards the PE which failed. This is for any AFI/SAFI. Remember the > BGP best path has not executed yet to eliminate the BGP best path > which can be influenced by local preference or MED. > > Your case mistakenly assumed that locally received EBGP route always > win, however this is not the case in BGP. AB: I thought it is understandable because the draft talks about a pre-calculated repair path. But it looks like I should say something like: The behavior explained in this document requires the support for multipath, such as best external or add-path. I'll also add a statement as follows: rPE advertises "rL" with a labeled prefix P/m only if it has an external path for the prefix and rPE is administratively permitted to protect the prefix. For unlabeled prefixes, rL is only needed if one of the best paths chosen by rPE is not an external path. The label "rL" is associated with the external path(s) only. > > > You re referring to per VRF lookup option in many places of the draft > - that needs to be deleted. Only per-CE label where "last hop" rPE > does not perform IP lookup may work. AB: If I add the statement mentioning that rL is only associated with external path, then it becomes an implementation detail to say that a router only considers external paths for packets arriving with rL even if the router makes an IP lookup to determine the next-hop. But I agree with you that per-CE rL is better and simpler to implement. I will not be so hung up on the per-VRF option if people think that per-CE is sufficient > >> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >> advertises a repair label rL1=3D3100 with the prefixes >> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers > > Another issue in your proposal is that you assume that rPE will be a > protecting PE for everyone. > AB: As I mentioned above, I will add a statement mentioning that multi-path support is required and that rPE advertises rL for prefixes to which rPE has an external path and is administratively allowed to do s= o. > Again in BGP this is not the case as during best path iPEs will > consider BGP next hop metric. Therefor for the identical destination > the same PE can be rPE for some iPEs while in the same time it can be > pPE for other iPEs. > > I do not see how in any BGP today you could signal both types of > labels (even if the label is per CE). AB: I do not understand "both types" refers to which types. But anyway, for a router support any type of fast convergence, such as BGP-PIC or PE-CE link protection, it has to support the notion of more than one path= =2E > > >> . When does the penultimate hop stop advertising pNH as its >> own prefix? The penultimate hop should continue to >> advertise pNH long enough for iPE's to re-converge. >> Advertising pNH longer than necessary is harmless because >> iPE's would have already re-converged to a new BGP next- >> hop and hence no traffic will be attracted to the non- >> existing pNH. The specific period length can be subject >> to configuration but the default value may be in the >> order of 2-3 minutes > > I really do not think this section is necessary. I do not understand > how we can stop advertising pNH from PHP node. If we stop when do we > start again ? AB: Again I though it is clear. But I agree with you that the bullet needs to explain two things: what are the conditions where PHP must advertise pNH and what are the conditions where PHP is allowed to withdraw pNH BTW, the statement does not imply any specific time to stop advertising pNH and the PHP may very well continue advertising pNH for ever. IMO, the statement is necessary to indicate that the PHP must continue to advertise pNH after pPE disappearance for a period long enough to avoid traffic disruption And to answer your question "If we stop when do we start again ?" The condition to start advertising pNH after stopping is the same condition to start advertising pNH for the first time. So PHP will start to advertise pNH again when gets the message (pNH) from the pPE again. > > >> 3. Penultimate Hop >> a. Receives a packet with top label bound to pNH >> b. Pops *three* labels *all the time*. > > Are you sure that current LSRs can pop more then one label on the > stack? Since the early days of MPLS it was my understanding that > except the special labels (null labels) MPLS LSRs do not POP more then > one label. I am not sure if this is spelled out in any of the MPLS > specifications, but I think it would be great to have some sort of > assurance that this is doable not only in theory but also in practice AB: This is a question about an implementation detail. But to keep the answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have been doing a lot more than this at line rate for a long period of time > > >> 3. Overview of the BGP FRR using Vector Labels in an IP Core >> >> This section describes the BGP FRR using vector labels solution in = an >> IP core for both labeled (AFI/SAFI 1/4, 2/4, 1/128, and 2/128) and >> unlabeled (AFI/SAFI 1/1, 2/1, 1/2, and 2/2) protected prefixes. > + >> The pPE needs to advertise the mapping (bgpNH,pNH). iPE also needs = to >> allocate a vector label for each known rPE and advertise the mappin= g >> (pNH,rNH,vL) > > I am not following this section. Let's consider SAFI 1/1. What is the > "rL" if I am not running MPLS ? Same for vector label "vL" ? What > protocol distributes those labels ? AB: First, there is a small typo. The first word in the second sentence needs to be "pPE". Second, the response to your first comment at the beginning of this email explains the usage of "rL" with unlabeled prefixe= s Now let me answer the questions about this paragraph, which I believe they are specific to unlabeled prefixes First question: What is "rL" if I am not running MPLS? rL is a label that informs rPE to always send the packet to an external path. rL has no semantics in the core at all. So the protocol running in the core is totally irrelevant to "rL" Second question: What is "vL" in a pure IP core? Section 3.1 talks about the case where all core routers, including the repairing router "rP", do not understand MPLS. In that case, vL is not use at all. If it is mentioned, then it is probably a mistake Section 3.2 talks about the case where the repairing core router "rP" understands MPLS but the rest of the core routers does not. In that case, "vL" is used the similar to how it is used in MPLS core Third question: What protocol distributes those labels ? Only "vL" needs to be distributed to the core. An optional TLV in ISIS or OSPF can be used to distribute "vL". > >> a. Assume that PE0 uses "Loopback0" as the BGP next-hop, PE0 >> automatically picks Loopback2 as the pNH. As such PE0 >> advertises (bgpNH,pNH)=3D(1.1.1.1,1.1.1.2) to all iBGP peers= >> including the iPE PE11. > > When you say that PE0 advertises pair of next hops ? How is this > encoded ? What is the semantics of this encoding ? AB: The actual syntax for advertising (bgpNH,pNH) is still work in progress. But, as I mentioned in page 9 item 2 (f), we can use a method similar to RFC5512. The semantics (bgpNH,pNH) is explained in item 4(a) in page 10 and in more details in the last bullet at the bottom of page 1= 0. > >> a. On receiving the repair labels 3100 and 3200 from PE1 and >> PE2, respectively, PE0 detects that there are two rPEs: PE1 >> and PE2. AS such PE0 assigns two vector labels vL1 =3D 1100 >> and vL2 =3D 1200 to PE1 and PE2, respectively > > How can PE0 receive the repair labels from PE1 and PE2 if we take SAFI > 1/1 and no add-paths ? Anyhow we do not even know that the rL is for > SAFI 1/1 yet :) For VPNs you assume different RD per VRF. That still > does not work as I mentioned above. The rPE will be a primary PPE for > some ingress PEs. > AB: This is back to the same comment about a router understanding multipath and associating "rL" with external paths only. As mentioned before, at least this document requires supporting multipath. > Best regards, > R. > >> Hi, >> >> The draft proposes a new method for BGP FRR. >> >> The approach is very scalable as it does not require injecting any >> prefixes into the core, no re-advertisement of BGP prefixes, and no >> state replication. At the same time, it is transparent to the operator= >> in the sense that if it is enabled by default, there is no need for >> human intervention due to any reason including internal and external >> topology changes or even when switching from MPLS to IP core and back >> >> All comments are most welcomed >> >> Thanks >> Ahmed --------------enigEBB26429791D2718491B2673 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBKO3+G19kFA5zIYRAlwQAJwJ6UdeNnjFJeU4VTQlplvuljNS8ACePoza loHoTsAvB/yA3T7SQz/cCTA= =5bIg -----END PGP SIGNATURE----- --------------enigEBB26429791D2718491B2673-- From bashandy@cisco.com Mon Jul 16 17:14:48 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406B411E8086; Mon, 16 Jul 2012 17:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.098 X-Spam-Level: X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 TZ+EsZtjMkMm; Mon, 16 Jul 2012 17:14:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFB11E8079; Mon, 16 Jul 2012 17:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=19504; q=dns/txt; s=iport; t=1342484133; x=1343693733; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OmmVHtYtVhOjk6lisvnDXzk+Az60Diuihv6Rq3pJlkg=; b=fq/GuAgiKI/iEqWjsqQ/9TZzsZpGYZK/gJKy32Rllw0WZ9Ov1c9qQhG5 k+wca+v76acXC0yLqHqsyTLfaslp2gT3HieMh4osCWvxsStdmbF2uPKdH yJbiT7Vu3OhberNvx9JlMnbtOzXDG1774Joy2aF/wtsiSZHDYRO+zstCV M=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="asc'?scan'208,217";a="49538953" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 Jul 2012 00:15:33 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6H0FWB8015257; Tue, 17 Jul 2012 00:15:33 GMT Message-ID: <5004AEA4.7010204@cisco.com> Date: Mon, 16 Jul 2012 17:15:32 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Susan Hares Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> In-Reply-To: <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE32D90942BF1B02AC93AA80A" Cc: idr@ietf.org, "'Maciek Konstantynowicz \(mkonstan\)'" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 00:14:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE32D90942BF1B02AC93AA80A Content-Type: multipart/alternative; boundary="------------000907020606070407060406" This is a multi-part message in MIME format. --------------000907020606070407060406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The edge-node protecting BGP-FRR solution that I am aware of is the one described in draft-minto-2547-egress-node-fast-protection and section 5.1.8.4 in draft-ietf-mpls-seamless-mpls I would be happy to know to learn about other ones Thanks Ahmed On 7/16/2012 2:51 PM, Susan Hares wrote: > > Ahmed: > > =20 > > Can provide a short comparison of this BGP frr with past attempts for > BGP FRR? > > =20 > > If you wish a list of the BGP FRR drafts, please let me know. > > =20 > > sue > > =20 > > *From:*idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf > Of *Ahmed Bashandy > *Sent:* Monday, July 09, 2012 2:30 PM > *To:* idr@ietf.org List; rtgwg@ietf.org > *Cc:* Maciek Konstantynowicz (mkonstan) > *Subject:* [Idr] Fwd: New Version Notification for > draft-bashandy-bgp-frr-vector-label-00.txt > > =20 > > =20 > > Hi, > > The draft proposes a new method for BGP FRR. > > The approach is very scalable as it does not require injecting any > prefixes into the core, no re-advertisement of BGP prefixes, and no > state replication. At the same time, it is transparent to the operator > in the sense that if it is enabled by default, there is no need for > human intervention due to any reason including internal and external > topology changes or even when switching from MPLS to IP core and back > > All comments are most welcomed > > Thanks > > Ahmed > > -------- Original Message -------- > > *Subject: * > > =09 > > New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt= > > *Date: * > > =09 > > Sun, 8 Jul 2012 07:05:43 -0700 > > *From: * > > =09 > > > > *To: * > > =09 > > > > *CC: * > > =09 > > , > > > =20 > > A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt > has been successfully submitted by Ahmed Bashandy and posted to the > IETF repository. > =20 > Filename: draft-bashandy-bgp-frr-vector-label > Revision: 00 > Title: BGP FRR Protection against Edge Node Failure Using Vect= or Labels > Creation date: 2012-07-07 > WG ID: Individual Submission > Number of pages: 32 > URL: http://www.ietf.org/internet-drafts/draft-bashandy-bgp= -frr-vector-label-00.txt > Status: http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr= -vector-label > Htmlized: http://tools.ietf.org/html/draft-bashandy-bgp-frr-vect= or-label-00 > =20 > =20 > Abstract: > Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, > PE2,..., PEn know about a prefix P/m via the external routers CE1, > CE2,..., CEm. If the edge router PEi crashes or becomes totally > disconnected from the core, it is desirable for a core router "P" > carrying traffic to the failed edge router PEi to immediately restore > traffic by re-tunneling packets originally tunneled to PEi and > destined to the prefix P/m to one of the other edge routers that > advertised P/m, say PEj, until BGP re-converges. In doing so, it is > highly desirable to keep the core BGP-free while not imposing > restrictions on external connectivity or complicating provisioning > effort. Thus (1) a core router should not be required to learn any > BGP prefix, (2) the size of the forwarding and routing tables in the > core routers should be independent of the number of BGP prefixes, (3) > re-routing traffic without waiting for re-convergence must not cause > loops, (4) provisioning effort should be kept at minimum, and (5) > there should be no restrictions on what edge routers advertise what > prefixes. For labeled prefixes, (6) the label stack on the packet > must allow the repair PEj to correctly forward the packet and (7) > there must not be any need to perform more than one label lookup on > any edge or core router during steady state > =20 > = =20 > =20 > =20 > The IETF Secretariat > > =20 > > =20 > --------------000907020606070407060406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The edge-node protecting BGP-FRR solution that I am aware of is the one described in draft-minto-2547-egress-node-fast-protection and section 5.1.8.4 in draft-ietf-mpls-seamless-mpls

I would be happy to know to learn about other ones

Thanks

Ahmed

On 7/16/2012 2:51 PM, Susan Hares wrote:

Ahmed:

=C2=A0

Can provide a short comparison of this BGP frr with past attempts for BGP FRR?

=C2=A0

If you wish a list of the BGP FRR drafts, please let me know.

=C2=A0

sue

=C2=A0

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 PM
To: idr@ietf.org List; rtgwg@ietf.org
Cc: Maciek Konstantynowicz (mkonstan)
Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

=C2=A0

=C2=A0

Hi,

The draft proposes a new method for BGP FRR.

The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back<= br>
All comments are most welcomed

Thanks

Ahmed

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

Subject:

New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt=

Date:

Sun, 8 Jul 2012 07:05:43 -0700

From:

<intern= et-drafts@ietf.org>

To:

<bashandy@cis= co.com>

CC:

<naikumar@cis= co.com>, <mkonstan@cis= co.com>

=C2=A0= 

A new version of I-D, draft-bashandy-bgp-frr-vector-label-=
00.txt
has been successfully submitted by Ahmed Bashandy and post=
ed to the
IETF repository.
=C2=A0
Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  draft-bashandy-bg=
p-frr-vector-label
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  00
          
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  BG=
P FRR Protection against Edge Node Failure Using Vector Labels=


          
Creation date:  2012-07-07

          
WG ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  In=
dividual Submission

          
Number of pages: 32

          
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 http://www.=
ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt

          
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 http://datatracker.ietf.org/doc/draft=
-bashandy-bgp-frr-vector-label

          
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/draft-bashandy-bgp-frr=
-vector-label-00

          
=C2=A0

          
=C2=A0

          
Abstract:

          
Consider a BGP free core scenario. Suppose the edge BGP sp=
eakers PE1,

          
PE2,..., PEn know about a prefix P/m via the external rout=
ers CE1,

          
CE2,..., CEm.=C2=A0 If the edge router PEi crashes or beco=
mes totally

          
disconnected from the core, it is desirable for a core rou=
ter "P"

          
carrying traffic to the failed edge router PEi to immediat=
ely restore

          
traffic by re-tunneling packets originally tunneled to PEi=
 and

          
destined to the prefix P/m to one of the other edge router=
s that

          
advertised P/m, say PEj, until BGP re-converges. In doing =
so, it is

          
highly desirable to keep the core BGP-free while not impos=
ing

          
restrictions on external connectivity or complicating prov=
isioning

          
effort. Thus (1) a core router should not be required to l=
earn any

          
BGP prefix, (2) the size of the forwarding and routing tab=
les in the

          
core routers should be independent of the number of BGP pr=
efixes, (3)

          
re-routing traffic without waiting for re-convergence must=
 not cause

          
loops, (4) provisioning effort should be kept at minimum, =
and (5)

          
there should be no restrictions on what edge routers adver=
tise what

          
prefixes. For labeled prefixes, (6) the label stack on the=
 packet

          
must allow the repair PEj to correctly forward the packet =
and (7)

          
there must not be any need to perform more than one label =
lookup on

          
any edge or core router during steady state
          
=C2=A0

          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

          
=C2=A0

          
=C2=A0

          
The IETF Secretariat

          
=C2=A0=

=C2=A0



--------------000907020606070407060406-- --------------enigE32D90942BF1B02AC93AA80A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQBK6k+G19kFA5zIYRAn/+AJ4pK1lwwEhC+5DDeOUyUlSiJ/DL9gCfS3hf M/CwkCyz0V0UCfex+KOJJsw= =aZnu -----END PGP SIGNATURE----- --------------enigE32D90942BF1B02AC93AA80A-- From robert@raszuk.net Mon Jul 16 18:48:37 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0921F8592 for ; Mon, 16 Jul 2012 18:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 nL4l5UDjT-0m for ; Mon, 16 Jul 2012 18:48:36 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D91ED21F856C for ; Mon, 16 Jul 2012 18:48:35 -0700 (PDT) Received: (qmail 13651 invoked by uid 399); 17 Jul 2012 01:49:21 -0000 Received: from unknown (HELO ?216.69.69.189?) (pbs:robert@raszuk.net@216.69.69.189) by mail1310.opentransfer.com with ESMTPM; 17 Jul 2012 01:49:21 -0000 X-Originating-IP: 216.69.69.189 Message-ID: <5004C4A0.8030306@raszuk.net> Date: Tue, 17 Jul 2012 03:49:20 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ahmed Bashandy Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> In-Reply-To: <5004A3B2.4040606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:48:37 -0000 Hi Ahmed, > Thanks a lot for the comments. See Inline. Look for "AB:" You are welcome ;) >>> ii. If "rL" is per-VRF, then pop *two* labels and forward the >>> packet based on the contents under the two popped labels >> >> I am afraid this does not work. >> >> VRF lookup on any rPE would still contain the the original best path >> towards the PE which failed. This is for any AFI/SAFI. Remember the >> BGP best path has not executed yet to eliminate the BGP best path >> which can be influenced by local preference or MED. >> >> Your case mistakenly assumed that locally received EBGP route always >> win, however this is not the case in BGP. > > AB: I thought it is understandable because the draft talks about a > pre-calculated repair path. But it looks like I should say something > like: The behavior explained in this document requires the support for > multipath, such as best external or add-path. Nope. Neither best external or add-paths are required for example for SAFI 1/128. I am not talking about path distribution at all in this point. > I'll also add a statement as follows: rPE advertises "rL" with a labeled > prefix P/m only if it has an external path for the prefix and rPE is > administratively permitted to protect the prefix.For unlabeled > prefixes, rL is only needed if one of the best paths chosen by rPE is > not an external path. The label "rL" is associated with the external > path(s) only. That clarification is optional. Above I am commenting on your point that per vrf IP lookup triggered by per-VRF label will not work in your solution. VRF will still point to the original best path exit. It is my understanding that you do not keep original VRF and protected VRF - do you ? If you do then this needs to be clearly stated in the document. The content of the "protection VRF" indeed could different from the original VRF, but I am not sure if you are planning this. As I said ... if the rL points outside this works .. if the rL points to original VRF for IP lookup it does not. Please clarify. >> You re referring to per VRF lookup option in many places of the draft >> - that needs to be deleted. Only per-CE label where "last hop" rPE >> does not perform IP lookup may work. > > AB: If I add the statement mentioning that rL is only associated with > external path, then it becomes an implementation detail to say that a > router only considers external paths for packets arriving with rL even > if the router makes an IP lookup to determine the next-hop. But I agree > with you that per-CE rL is better and simpler to implement. I will not > be so hung up on the per-VRF option if people think that per-CE is > sufficient Again IMHO you have just two options .. - keep nice scaling property and _only_ bind the rL to external next hops (CEs) - compromise scaling by adding new "shadow VRFs - different from primary VRFs and allow rL to point to such shadow VRF for local IP lookup. >>> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >>> advertises a repair label rL1=3100 with the prefixes >>> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers >> >> Another issue in your proposal is that you assume that rPE will be a >> protecting PE for everyone. >> > AB: As I mentioned above, I will add a statement mentioning that > multi-path support is required and that rPE advertises rL for prefixes > to which rPE has an external path and is administratively allowed to do so. You are missing my point. In the draft you say that it is on purpose that rL is different label then normal switching label (for example VPN label). I am saying that if any box is advertising a prefix - it can advertise given BGP path only once. No best external .. no add-paths help. And multipath is irrelevant here completely as this term is used to indicate what routers installs in the forwarding. Adding two labels for the same bgp path does not make it two paths. And as pointed out this is common in the networks for an exit PE to in the same time be primary for some ingress PEs and backup for the others. >> Again in BGP this is not the case as during best path iPEs will >> consider BGP next hop metric. Therefor for the identical destination >> the same PE can be rPE for some iPEs while in the same time it can be >> pPE for other iPEs. >> >> I do not see how in any BGP today you could signal both types of >> labels (even if the label is per CE). > > AB: I do not understand "both types" refers to which types. But anyway, > for a router support any type of fast convergence, such as BGP-PIC or > PE-CE link protection, it has to support the notion of more than one path. BGP PIC or PE-CE requires the reception of more then one path. That is clear. Your proposal mandates advertisement of two types of exit switching labels (for 1/128 primary VPN label and backup rL label). In fact you propose to encode rL "as path attributes in MP/BGP updates" > And to answer your question "If we stop when do we start again ?" The > condition to start advertising pNH after stopping is the same condition > to start advertising pNH for the first time. So PHP will start to > advertise pNH again when gets the message (pNH) from the pPE again. You mean that when " c. pPE advertises pNH as a prefix into IGP" right ? Then IGP may not be impacted and may not re-advertise ... only BGP crashed. Then you will never start advertising the pNH. > AB: This is a question about an implementation detail. But to keep the > answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have > been doing a lot more than this at line rate for a long period of time Perhaps it is easy. However I recall folks who invented MPLS telling me that you never should pop more then one level of labels. Do you know if currently deployed routers can do it in practice ? Anyhow to realize your scheme even if we solve major issues a network wide upgrade of participating routers is mandatory. > First question: What is "rL" if I am not running MPLS? > rL is a label that informs rPE to always send the packet to an external > path. rL has no semantics in the core at all. So the protocol running in > the core is totally irrelevant to "rL" I am not talking about the core. I am also talking about the edge ... So edge must use label switching correct ? Hint: You could have a IP tunnel endpoint terminating at the CE/NH. > Second question: What is "vL" in a pure IP core? > Section 3.1 talks about the case where all core routers, including the > repairing router "rP", do not understand MPLS. In that case, vL is not > use at all. If it is mentioned, then it is probably a mistake ok. > Section 3.2 talks about the case where the repairing core router "rP" > understands MPLS but the rest of the core routers does not. In that > case, "vL" is used the similar to how it is used in MPLS core > Third question: What protocol distributes those labels ? > Only "vL" needs to be distributed to the core. An optional TLV in ISIS > or OSPF can be used to distribute "vL". Ahh nice .. so we are back to carrying labels in IGP .. Finally ! That has been proposed so many times :) Also maybe we will get the concept of global label rolled out in more generic way as vL is effectively and semantically a global label (per given IGP domain). Thx, R. From shares@ndzh.com Mon Jul 16 14:50:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5321F875D; Mon, 16 Jul 2012 14:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqrRZ1qFO3hH; Mon, 16 Jul 2012 14:50:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1121F875A; Mon, 16 Jul 2012 14:50:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.198.20; Received: from SKH2012HPLT (unverified [63.133.198.20]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3458822-1945496 for multiple; Mon, 16 Jul 2012 17:51:40 -0400 From: "Susan Hares" To: "'Ahmed Bashandy'" , , References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> In-Reply-To: <4FFB2330.4020809@cisco.com> Subject: RE: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date: Mon, 16 Jul 2012 17:51:39 -0400 Message-ID: <000c01cd639d$2e3f0630$8abd1290$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CD637B.A7392600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJaU3tI8rbwHuAvE5KejGfrXR6iaAFyCLallgcCZBA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Tue, 17 Jul 2012 15:11:14 -0700 Cc: "'Maciek Konstantynowicz \(mkonstan\)'" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:50:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CD637B.A7392600 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ahmed: =20 Can provide a short comparison of this BGP frr with past attempts for = BGP FRR? =20 If you wish a list of the BGP FRR drafts, please let me know. =20 sue =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Ahmed Bashandy Sent: Monday, July 09, 2012 2:30 PM To: idr@ietf.org List; rtgwg@ietf.org Cc: Maciek Konstantynowicz (mkonstan) Subject: [Idr] Fwd: New Version Notification for = draft-bashandy-bgp-frr-vector-label-00.txt =20 =20 Hi, The draft proposes a new method for BGP FRR.=20 The approach is very scalable as it does not require injecting any = prefixes into the core, no re-advertisement of BGP prefixes, and no = state replication. At the same time, it is transparent to the operator = in the sense that if it is enabled by default, there is no need for = human intervention due to any reason including internal and external = topology changes or even when switching from MPLS to IP core and back All comments are most welcomed Thanks Ahmed -------- Original Message --------=20 Subject:=20 New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date:=20 Sun, 8 Jul 2012 07:05:43 -0700 From:=20 To:=20 CC:=20 , = =20 A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. =20 Filename: draft-bashandy-bgp-frr-vector-label Revision: 00 Title: BGP FRR Protection against Edge Node Failure Using = Vector Labels Creation date: 2012-07-07 WG ID: Individual Submission Number of pages: 32 URL: = http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-0= 0.txt Status: = http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label Htmlized: = http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00 =20 =20 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity or complicating provisioning effort. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes, (3) re-routing traffic without waiting for re-convergence must not cause loops, (4) provisioning effort should be kept at minimum, and (5) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the label stack on the packet must allow the repair PEj to correctly forward the packet and (7) there must not be any need to perform more than one label lookup on any edge or core router during steady state =20 = =20 =20 =20 The IETF Secretariat =20 =20 ------=_NextPart_000_000D_01CD637B.A7392600 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ahmed:

 

Can provide a short comparison of this BGP frr with past attempts for = BGP FRR?

 

If you wish a list of the BGP FRR drafts, please let me = know.

 

sue

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 = PM
To: idr@ietf.org List; rtgwg@ietf.org
Cc: Maciek = Konstantynowicz (mkonstan)
Subject: [Idr] Fwd: New Version = Notification for = draft-bashandy-bgp-frr-vector-label-00.txt

 

 

Hi,

The draft proposes a new method for BGP = FRR.

The approach is very scalable as it does not require = injecting any prefixes into the core, no re-advertisement of BGP = prefixes, and no state replication. At the same time, it is transparent = to the operator in the sense that if it is enabled by default, there is = no need for human intervention due to any reason including internal and = external topology changes or even when switching from MPLS to IP core = and back

All comments are most = welcomed

Thanks

Ahmed

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

Date: =

Subject:

New Version = Notification for = draft-bashandy-bgp-frr-vector-label-00.txt

Sun, 8 Jul 2012 07:05:43 = -0700

From:

<internet-drafts@ietf.org>=

To:

<bashandy@cisco.com>

CC:

<naikumar@cisco.com>, <mkonstan@cisco.com>

 

A new version =
of I-D, =
draft-bashandy-bgp-frr-vector-label-00.txt
has been =
successfully submitted by Ahmed Bashandy and posted to =
the
IETF =
repository.
 
Filename:=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0  =
draft-bashandy-bgp-frr-vector-label
Revision:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0  =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0  BGP FRR Protection against Edge Node Failure Using Vector =
Labels
Creation date:  =
2012-07-07
WG =
ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0  Individual =
Submission
Number of pages: =
32
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr=
-vector-label-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00
 
 
Abstract:
Consider a BGP free core scenario. =
Suppose the edge BGP speakers PE1,
PE2,..., PEn =
know about a prefix P/m via the external routers =
CE1,
CE2,..., CEm.=C2=A0 If the edge router PEi =
crashes or becomes totally
disconnected from the =
core, it is desirable for a core router =
"P"
carrying traffic to the failed edge =
router PEi to immediately restore
traffic by =
re-tunneling packets originally tunneled to PEi =
and
destined to the prefix P/m to one of the other =
edge routers that
advertised P/m, say PEj, until =
BGP re-converges. In doing so, it is
highly =
desirable to keep the core BGP-free while not =
imposing
restrictions on external connectivity or =
complicating provisioning
effort. Thus (1) a core =
router should not be required to learn any
BGP =
prefix, (2) the size of the forwarding and routing tables in =
the
core routers should be independent of the =
number of BGP prefixes, (3)
re-routing traffic =
without waiting for re-convergence must not =
cause
loops, (4) provisioning effort should be kept =
at minimum, and (5)
there should be no restrictions =
on what edge routers advertise what
prefixes. For =
labeled prefixes, (6) the label stack on the =
packet
must allow the repair PEj to correctly =
forward the packet and (7)
there must not be any =
need to perform more than one label lookup on
any =
edge or core router during steady =
state
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
 
 
The IETF Secretariat

 

 

------=_NextPart_000_000D_01CD637B.A7392600-- From bashandy@cisco.com Thu Jul 19 12:51:20 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019D21F8734; Thu, 19 Jul 2012 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 joI0iVra-TGx; Thu, 19 Jul 2012 12:51:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 03E1C21F8700; Thu, 19 Jul 2012 12:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=12239; q=dns/txt; s=iport; t=1342727533; x=1343937133; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ooJzU5A7WKiI8H2nqmIBo1gByRodWc+eXSWe2k70UTk=; b=ABBcQRi/YAOc5G2uz9/BGgFuLc+GnycdIrQYXIn5+byXze1MYdiyK5sl rD092gmap0kx1QXM+irFVJ8/uKGxLnSYR1azhDiG8+67aOObO3JnWddMz YjKDzPNWBEyunuQh3pPh7JsrjBAIg9+rI+mRj7B3V/hqfdoKPxj+OeSzK w=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,617,1336348800"; d="asc'?scan'208";a="52355491" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 19 Jul 2012 19:52:13 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6JJqCJN031291; Thu, 19 Jul 2012 19:52:12 GMT Message-ID: <50086564.9020500@cisco.com> Date: Thu, 19 Jul 2012 12:52:04 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> In-Reply-To: <5004C4A0.8030306@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2C149076E69925839744317E" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 19:51:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C149076E69925839744317E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, May be I understood the source of confusion regarding paths The draft does not require modifications to existing prefix advertisements rules or implementations. All the draft is saying is that if a prefix satisfies the conditions for attaching and advertising "rL" and the prefix is being advertised, then rPE attaches "rL" as an optional attribute. Satisfying or loosing the conditions for advertising "rL" by itself has no bearing on the decision of whether a prefix should be advertised or not. Think of "rL" as a new export RT configured on a VRF with existing export RT in a simple VPN scenario. If the operator adds an export RT to a VRF, the PE will re-advertise the prefixes to its peers to inform them about the new RT that has been configured on top of the pre-existing ones. At the same time, the operator may prohibit the router from doing that. Regarding diverging to implementation details, I am not prepared to discuss any implementation details, at least at this point in time, and I will refrain from commenting on any of them. There are a couple of inline comments. Look for "AB2:" this time Thanks Ahmed On 7/16/2012 6:49 PM, Robert Raszuk wrote: > Hi Ahmed, > > > Thanks a lot for the comments. See Inline. Look for "AB:" > > You are welcome ;) > >>>> ii. If "rL" is per-VRF, then pop *two* labels and forward the >>>> packet based on the contents under the two popped labels >>> >>> I am afraid this does not work. >>> >>> VRF lookup on any rPE would still contain the the original best path >>> towards the PE which failed. This is for any AFI/SAFI. Remember the >>> BGP best path has not executed yet to eliminate the BGP best path >>> which can be influenced by local preference or MED. >>> >>> Your case mistakenly assumed that locally received EBGP route always >>> win, however this is not the case in BGP. > > >> AB: I thought it is understandable because the draft talks about a >> pre-calculated repair path. But it looks like I should say something >> like: The behavior explained in this document requires the support for= >> multipath, such as best external or add-path. > > Nope. Neither best external or add-paths are required for example for > SAFI 1/128. I am not talking about path distribution at all in this > point. >> I'll also add a statement as follows: rPE advertises "rL" with a label= ed >> prefix P/m only if it has an external path for the prefix and rPE is >> administratively permitted to protect the prefix.For unlabeled >> prefixes, rL is only needed if one of the best paths chosen by rPE is >> not an external path. The label "rL" is associated with the external >> path(s) only. > > That clarification is optional. Above I am commenting on your point > that per vrf IP lookup triggered by per-VRF label will not work in > your solution. VRF will still point to the original best path exit. > > It is my understanding that you do not keep original VRF and protected > VRF - do you ? If you do then this needs to be clearly stated in the > document. The content of the "protection VRF" indeed could different > from the original VRF, but I am not sure if you are planning this. > > As I said ... if the rL points outside this works .. if the rL points > to original VRF for IP lookup it does not. > AB2: I disagree with the last statement. As I mentioned before, it is implementation details to describe how a router only considers external path(s) for packets arriving with "rL". We're still not stuck on keeping per-VRF "rL".. > Please clarify. > >>> You re referring to per VRF lookup option in many places of the draft= >>> - that needs to be deleted. Only per-CE label where "last hop" rPE >>> does not perform IP lookup may work. > > >> AB: If I add the statement mentioning that rL is only associated with= >> external path, then it becomes an implementation detail to say that a >> router only considers external paths for packets arriving with rL even= >> if the router makes an IP lookup to determine the next-hop. But I agre= e >> with you that per-CE rL is better and simpler to implement. I will not= >> be so hung up on the per-VRF option if people think that per-CE is >> sufficient > > Again IMHO you have just two options .. > > - keep nice scaling property and _only_ bind the rL to external next > hops (CEs) > > - compromise scaling by adding new "shadow VRFs - different from > primary VRFs and allow rL to point to such shadow VRF for local IP > lookup. > AB2: Again implementation details about per-VRF "rL":) --> No comments >>>> a. Acting as a rPE, PE1 allocates (on per-CE basis) and >>>> advertises a repair label rL1=3D3100 with the prefixes >>>> 10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers >>> >>> Another issue in your proposal is that you assume that rPE will be a >>> protecting PE for everyone. >>> >> AB: As I mentioned above, I will add a statement mentioning that >> multi-path support is required and that rPE advertises rL for prefixes= >> to which rPE has an external path and is administratively allowed to >> do so. > > You are missing my point. > > In the draft you say that it is on purpose that rL is different label > then normal switching label (for example VPN label). > > I am saying that if any box is advertising a prefix - it can advertise > given BGP path only once. No best external .. no add-paths help. And > multipath is irrelevant here completely as this term is used to > indicate what routers installs in the forwarding. > AB2: As mentioned at the beginning of the email, the draft never indicated that it requires changes to BGP prefix advertisement rules or implementations. All the draft is saying that "rL" can be attached to advertised prefixes if the PE can and is willing to act as a repair PE > Adding two labels for the same bgp path does not make it two paths.=20 AB2: Adding "rL" has no bearing on the number of paths. Adding "rL" to a prefix indicates to iPEs and pPEs that the advertising PE is willing to act as a repair PE for the prefix > And as pointed out this is common in the networks for an exit PE to in > the same time be primary for some ingress PEs and backup for the others= =2E AB: Why do you think that there is a problem if the same ePE is primary for some iPEs and repair for others? In fact item 3(a) at the bottom pf page 9 covers this this case. If there some scenarios where being a primary and repair at the same time causes problems or does not work, it would be very helpful to point them out. >>> Again in BGP this is not the case as during best path iPEs will >>> consider BGP next hop metric. Therefor for the identical destination >>> the same PE can be rPE for some iPEs while in the same time it can be= >>> pPE for other iPEs. >>> >>> I do not see how in any BGP today you could signal both types of >>> labels (even if the label is per CE). > > >> AB: I do not understand "both types" refers to which types. But anyway= , >> for a router support any type of fast convergence, such as BGP-PIC or >> PE-CE link protection, it has to support the notion of more than one >> path. > > BGP PIC or PE-CE requires the reception of more then one path. That is > clear. Your proposal mandates advertisement of two types of exit > switching labels (for 1/128 primary VPN label and backup rL label). In > fact you propose to encode rL "as path attributes in MP/BGP updates" > AB2: Thanks for clarifying what I want to say:) >> And to answer your question "If we stop when do we start again ?" The= >> condition to start advertising pNH after stopping is the same conditio= n >> to start advertising pNH for the first time. So PHP will start to >> advertise pNH again when gets the message (pNH) from the pPE again. > > You mean that when " c. pPE advertises pNH as a prefix into IGP" > right ? Then IGP may not be impacted and may not re-advertise ... only > BGP crashed. Then you will never start advertising the pNH. AB2: No, I do not mean IGP. I mean a special advertisement. Item 2 (e) mentions that. For example, an optional TLV in LDP can be used to advertise this special IP address to the PHP. > >> AB: This is a question about an implementation detail. But to keep the= >> answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have= >> been doing a lot more than this at line rate for a long period of time= > > Perhaps it is easy. However I recall folks who invented MPLS telling > me that you never should pop more then one level of labels. Do you > know if currently deployed routers can do it in practice ? AB2: I already answered the question "Do you know if currently deployed routers can do it in practice ? " when I said "it is VERY EASY". I will not comment any further because this is implementation details. Regarding popping more than one label, routers have been doing that for a very long time. For example, a PE that advertises an explicit label (instead of implicit null) for the BGP next-hop. Besides, is there an RFC that explicitly prohibits a router from popping more than one label? > > Anyhow to realize your scheme even if we solve major issues a network > wide upgrade of participating routers is mandatory. > AB2: This is incorrect. The scheme can be incrementally deployed few routers at a time. For example, one iPE, one rP and two ePEs. >> First question: What is "rL" if I am not running MPLS? >> rL is a label that informs rPE to always send the packet to an externa= l >> path. rL has no semantics in the core at all. So the protocol running = in >> the core is totally irrelevant to "rL" > > I am not talking about the core. I am also talking about the edge ... > So edge must use label switching correct ? > AB2: This draft expects a PE to understand MPLS. PEs that do not support MPLS are not covered by this draftt. IP core means only core routers. > Hint: You could have a IP tunnel endpoint terminating at the CE/NH. AB2: The draft never claimed that it works in all scenarios (and no document should be making this claim). But for this particular scenario, can you provide more clarification? > >> Second question: What is "vL" in a pure IP core? >> Section 3.1 talks about the case where all core routers, including the= >> repairing router "rP", do not understand MPLS. In that case, vL is not= >> use at all. If it is mentioned, then it is probably a mistake > > ok. > >> Section 3.2 talks about the case where the repairing core router "rP" >> understands MPLS but the rest of the core routers does not. In that >> case, "vL" is used the similar to how it is used in MPLS core >> Third question: What protocol distributes those labels ? >> Only "vL" needs to be distributed to the core. An optional TLV in ISIS= >> or OSPF can be used to distribute "vL". > > Ahh nice .. so we are back to carrying labels in IGP .. Finally ! That > has been proposed so many times :)=20 AB2: So I heard:) So one more time would not be so weird:) > Also maybe we will get the concept of global label rolled out in more > generic way as vL is effectively and semantically a global label (per > given IGP domain). AB2: Another misunderstanding. The semantics of "vL" are not global. Is there a place in the draft where it is implied that "vL" has global semantics in an IGP domain? > Thx, > R. --------------enig2C149076E69925839744317E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQCGVs+G19kFA5zIYRAhBQAJ0c5oUYZyAZLlDf0Sqe45R4r/kFRACdGWxi uUAxfOXwpGmD2xDvyFgFxvQ= =eq/7 -----END PGP SIGNATURE----- --------------enig2C149076E69925839744317E-- From robert@raszuk.net Thu Jul 19 23:38:50 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C0C21F8645 for ; Thu, 19 Jul 2012 23:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GzNE1NH+JExt for ; Thu, 19 Jul 2012 23:38:49 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 48FC521F863D for ; Thu, 19 Jul 2012 23:38:49 -0700 (PDT) Received: (qmail 22032 invoked by uid 399); 20 Jul 2012 06:39:43 -0000 Received: from unknown (HELO ?10.77.83.122?) (pbs:robert@raszuk.net@72.254.61.36) by mail1310.opentransfer.com with ESMTPM; 20 Jul 2012 06:39:43 -0000 X-Originating-IP: 72.254.61.36 Message-ID: <5008FD2E.1000006@raszuk.net> Date: Fri, 20 Jul 2012 08:39:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ahmed Bashandy Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> In-Reply-To: <50086564.9020500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:38:51 -0000 Ahmed, > May be I understood the source of confusion regarding paths > The draft does not require modifications to existing prefix > advertisements rules or implementations. All the draft is saying is that > if a prefix satisfies the conditions for attaching and advertising "rL" > and the prefix is being advertised, then rPE attaches "rL" as an > optional attribute. To the best of my knowledge today we do not have a defined attribute in BGP to carry MPLS labels. If you are proposing a solution which does not have corresponding encoding in the protocol you intend to use I think you are going a wrong way. > Regarding diverging to implementation details, I am not prepared to > discuss any implementation details, at least at this point in time, and > I will refrain from commenting on any of them. That's neat :) While you may claim that everything is an implementation detail I think you should not be stating as an advantage of your proposal the following: " o Very scalable: o No router has to copy the routing table of another router" > AB2: As mentioned at the beginning of the email, the draft never > indicated that it requires changes to BGP prefix advertisement rules or > implementations. All the draft is saying that "rL" can be attached to > advertised prefixes if the PE can and is willing to act as a repair PE Than your solution is broken. You must at min enable best external to cover the case where the VPN chooses by local preference or med different exit point as best path. If you do not enable best external or add-paths your repair paths will not get advertised. >> Anyhow to realize your scheme even if we solve major issues a network >> wide upgrade of participating routers is mandatory. >> > AB2: This is incorrect. The scheme can be incrementally deployed few > routers at a time. For example, one iPE, one rP and two ePEs. That was correct. Pls notice what I said: "participating routers". Do you expect iPE, rP and two ePEs all be from the same vendor and same OS branch supporting your feature ??? > AB2: The draft never claimed that it works in all scenarios (and no > document should be making this claim). But for this particular scenario, > can you provide more clarification ? I am afraid this is an implementation detail how you organize the packet switching after termination of the IP tunnel. Rgs, R. From bashandy@cisco.com Fri Jul 20 18:16:59 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DF811E80A0; Fri, 20 Jul 2012 18:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 q0u2wH-H8gnX; Fri, 20 Jul 2012 18:16:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8E64221F84A2; Fri, 20 Jul 2012 18:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=4806; q=dns/txt; s=iport; t=1342833469; x=1344043069; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+37v4f8239IUffKohLsQdzf4HAanKipjB0bffY3upwg=; b=RsE5PeTE/f1KGnv2l5Kt5ZqTMxMAd7S/8iAxUh0wkx4aGMqllSJG5Dxg DExU86LLi4X4GBZLSTVAoXDdDWLDhXaNn6qd2MfCa/+qVEpDA5Y2UYRDC NardDgZxIVM63GoNtRy3SmcX0FsLBS5T4hThExrSuADUin33SPO6iM/4w s=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,627,1336348800"; d="asc'?scan'208";a="49992105" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 21 Jul 2012 01:17:49 +0000 Received: from [10.21.83.238] (sjc-vpn4-1007.cisco.com [10.21.83.238]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6L1Hlpx008334; Sat, 21 Jul 2012 01:17:48 GMT Message-ID: <500A0336.1080001@cisco.com> Date: Fri, 20 Jul 2012 18:17:42 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: robert@raszuk.net Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> In-Reply-To: <5008FD2E.1000006@raszuk.net> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10E2B7469FF4831EAB5AFA04" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 01:16:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10E2B7469FF4831EAB5AFA04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert, See comments inline. This time look for "AB3:" Thanks Ahmed On 7/19/2012 11:39 PM, Robert Raszuk wrote: > Ahmed, > > > May be I understood the source of confusion regarding paths >> The draft does not require modifications to existing prefix >> advertisements rules or implementations. All the draft is saying is th= at >> if a prefix satisfies the conditions for attaching and advertising "rL= " >> and the prefix is being advertised, then rPE attaches "rL" as an >> optional attribute. > > To the best of my knowledge today we do not have a defined attribute > in BGP to carry MPLS labels. If you are proposing a solution which > does not have corresponding encoding in the protocol you intend to use > I think you are going a wrong way. AB3: You are rushing things too fast:) We're still discussing the idea. The syntax of the new attribute will come at later versions. I hope you do not think that the whole solution is wrong just because I did not put the syntax of the attribute in the first version. > >> Regarding diverging to implementation details, I am not prepared to >> discuss any implementation details, at least at this point in time, an= d >> I will refrain from commenting on any of them. > > That's neat :) While you may claim that everything is an > implementation detail I think you should not be stating as an > advantage of your proposal the following: > > " o Very scalable: > o No router has to copy the routing table of another router" AB3: So either I diverge into implementations or blindly accept what should be kept in the draft and what should not. If I were to suggest the above modification, I would make a it more scientific by taking a closer look at the draft and trying to corroborate the suggestion by finding one or more deployment scenarios where one router needs to copy the routing table of another. > >> AB2: As mentioned at the beginning of the email, the draft never >> indicated that it requires changes to BGP prefix advertisement rules o= r >> implementations. All the draft is saying that "rL" can be attached to >> advertised prefixes if the PE can and is willing to act as a repair PE= > > Than your solution is broken.=20 AB3: No it is not. You do not have a full understanding of the draft > You must at min enable best external to cover the case where the VPN > chooses by local preference or med different exit point as best path. > If you do not enable best external or add-paths your repair paths will > not get advertised. AB3: I am not sure why you insist on pushing path selection and advertisement down the throat of the draft. The conditions for advertising "rL" are clear. What you just suggested is one way to satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE link protection are other scenarios where the conditions of advertising "rL" are satisfied without best external or add-path. > >>> Anyhow to realize your scheme even if we solve major issues a network= >>> wide upgrade of participating routers is mandatory. >>> >> AB2: This is incorrect. The scheme can be incrementally deployed few >> routers at a time. For example, one iPE, one rP and two ePEs. > > That was correct. Pls notice what I said: "participating routers". AB3: IMHO, if a network has thousands of routers, it is hard to label updating 4 routers as "network wide" > > Do you expect iPE, rP and two ePEs all be from the same vendor and > same OS branch supporting your feature ??? AB3: Ah. So now we're taking the discussion of implementation details to the level of feature release and router sales:) >> AB2: The draft never claimed that it works in all scenarios (and no >> document should be making this claim). But for this particular scenari= o, >> can you provide more clarification ? > > I am afraid this is an implementation detail how you organize the > packet switching after termination of the IP tunnel. AB3: Excellent, so I see an agreement to avoid implementation details:). > > Rgs, > R. > --------------enig10E2B7469FF4831EAB5AFA04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQCgM7+G19kFA5zIYRAq3jAJ4ivGRni5EAey+WCkONBdeq5IbcvwCgiG9u +PsEKUW/NhhZpZg1aA9/zAk= =HjHy -----END PGP SIGNATURE----- --------------enig10E2B7469FF4831EAB5AFA04-- From robert@raszuk.net Sat Jul 21 10:27:13 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B14E21F8565 for ; Sat, 21 Jul 2012 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 H9y-tJpAw5IO for ; Sat, 21 Jul 2012 10:27:12 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7321F855F for ; Sat, 21 Jul 2012 10:27:12 -0700 (PDT) Received: (qmail 22109 invoked by uid 399); 21 Jul 2012 17:28:11 -0000 Received: from unknown (HELO ?10.77.83.164?) (pbs:robert@raszuk.net@72.254.10.46) by mail1310.opentransfer.com with ESMTPM; 21 Jul 2012 17:28:11 -0000 X-Originating-IP: 72.254.10.46 Message-ID: <500AE6AA.9090608@raszuk.net> Date: Sat, 21 Jul 2012 19:28:10 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ahmed Bashandy Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> <500A0336.1080001@cisco.com> In-Reply-To: <500A0336.1080001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:27:13 -0000 Hi Ahmed, Since you seem to be skipping answering some questions in your replies let me ask (well repeat) one question at a time. Question: How are you going to propagate any information in iBGP from repair PEs to ingress PEs considering that overall best path for this prefix is advertised by some other protected PE ? Are you mandating that your solution is deployable only with use of one of the following techniques: - add-paths on rPEs, RRs & iPEs - best-external on rPEs + add-paths on RRs & iPEs - best-external on rPEs + diverse-path on RRs - full mesh of iPEs & rPEs with best external (I am skipping cluster external option on RRs as in the control plane only RRs which are randomly located this may be a bit difficult to provision). Scenario clarification: I am talking about case where pPE chooses the best path based on local preference or MED. The only comment I found related to the above is in the introduction: In modern networks, it is not uncommon to have a prefix reachable via multiple edge routers. One example is the best external path [8]. The reason for such fundamental question is that architectures which do not require at the service level participation of ingress routers and repair routers in the protection may be chosen over the one which does (your proposal). Rgs, R. From bashandy@cisco.com Mon Jul 23 18:48:27 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468E611E80F3; Mon, 23 Jul 2012 18:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6EfnZQZnmLWS; Mon, 23 Jul 2012 18:48:26 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 81FA711E80E2; Mon, 23 Jul 2012 18:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=4082; q=dns/txt; s=iport; t=1343094506; x=1344304106; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Mnf+lH0w49x/K6tg7ta8xIIqbPa+15k+eanTDAZgnp0=; b=AZtAMeFNld4pERO5WnR+9WN3XtFCtNZowIm4y1+Yo1mTBSVba7RGESNc 59BiPUn2Zm+uhPVJXfrmnH/0zfsMe6Rl8jMgXSb59otSBb02T06SG5LHw 4zdOwyIHi0rx2P3mJrrjiH5m5ZdArmKckFUdDYsBpTsmR7ln3il+coYXI w=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.77,641,1336348800"; d="asc'?scan'208";a="49714230" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 24 Jul 2012 01:48:26 +0000 Received: from [171.71.139.5] (dhcp-171-71-139-5.cisco.com [171.71.139.5]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6O1mQRs029957; Tue, 24 Jul 2012 01:48:26 GMT Message-ID: <500DFEE9.1020608@cisco.com> Date: Mon, 23 Jul 2012 18:48:25 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "robert@raszuk.net" Subject: RE: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com> <5002918F.3010107@raszuk.net> <5004A3B2.4040606@cisco.com> <5004C4A0.8030306@raszuk.net> <50086564.9020500@cisco.com> <5008FD2E.1000006@raszuk.net> <500A0336.1080001@cisco.com> <500AE6AA.9090608@raszuk.net> In-Reply-To: <500AE6AA.9090608@raszuk.net> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig36FF589D915D3182D7EC9F1C" Cc: "idr@ietf.org List" , "Maciek Konstantynowicz \(mkonstan\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 01:48:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36FF589D915D3182D7EC9F1C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It looks like I am going to re-iterate some of the statements that you seem to avoid (I don't know why) See replies inline. Look for AB4 Thanks -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net] Sent: Saturday, July 21, 2012 10:28 AM To: Ahmed Bashandy (bashandy) Cc: idr@ietf.org List; rtgwg@ietf.org; Maciek Konstantynowicz (mkonstan) Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Hi Ahmed, Since you seem to be skipping answering some questions in your replies let me ask (well repeat) one question at a time. Question: How are you going to propagate any information in iBGP from repair PEs to ingress PEs considering that overall best path for this prefix is advertised by some other protected PE ? AB4: Quotation from the first reply (AB:) "The behavior explained in this document requires the support for multipath". More explicit statement: how to satisfy the multipath requirement is deliberately left out of the draft. Are you mandating that your solution is deployable only with use of one of the following techniques: - add-paths on rPEs, RRs & iPEs - best-external on rPEs + add-paths on RRs & iPEs - best-external on rPEs + diverse-path on RRs - full mesh of iPEs & rPEs with best external AB4: No. The draft does NOT mandate particular multipath technique(s). This is a question that is already answered. Here is a quotation from the previous email (AB3:) "What you just suggested is one way to satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE link protection are other scenarios where the conditions of advertising "rL" are satisfied without best external or add-path." (I am skipping cluster external option on RRs as in the control plane only RRs which are randomly located this may be a bit difficult to provision). Scenario clarification: I am talking about case where pPE chooses the best path based on local preference or MED. The only comment I found related to the above is in the introduction: In modern networks, it is not uncommon to have a prefix reachable via multiple edge routers. One example is the best external path [8]. The reason for such fundamental question is that architectures which do not require at the service level participation of ingress routers and repair routers in the protection may be chosen over the one which does (your proposal). AB4: So all these questions are alluding to a comparison:) A more direct question, like what Susan asked, would have been easier to answer. IMHO comparison with other techniques is more befitting an informational draft= =2E For the participation of iPE and rPE, I have a comment and a request - BGP-PIC edge is a deployed solution that requires iPE participation. So it seems like other factors, such as scalability, transparency to operators, and simplified provisioning and management, are as important in deployment decisions - For rPE participation, I would be very happy if you point me to a paper/draft/implemented/deployed or about to be implemented/deployed BGP-FRR technique (that rely on local failure detection and traffic re-routing when an ePE fails) that does not require the participation of rPE. That would also help with Susan's request. Rgs, R. --------------enig36FF589D915D3182D7EC9F1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQDf7p+G19kFA5zIYRApnPAJ9xZyXYA7vcMySFg15b+Ys+CtQ0gQCcDiGT zHikPaaFJADGZ2EaYXFmSTI= =WRNI -----END PGP SIGNATURE----- --------------enig36FF589D915D3182D7EC9F1C-- From akatlas@gmail.com Mon Jul 23 20:49:45 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAE11E810E for ; Mon, 23 Jul 2012 20:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DPQ8ed0tcHlf for ; Mon, 23 Jul 2012 20:49:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE13E11E8104 for ; Mon, 23 Jul 2012 20:49:44 -0700 (PDT) Received: by yenq13 with SMTP id q13so6794618yen.31 for ; Mon, 23 Jul 2012 20:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gWLk+cfEie1loYydHtMlMJr/6SMkA5B5I5WoTloAjm8=; b=tP6p/2lQkZK4rrWCEVhVOYjJcwcVFoINFnfBdu2wkKUaPo3jstI2ClV2T71ld112JT i7EZwqaiewRSmsYDWyX8iMSxxvNbAhudOI3NzV5r4PE6ZnO+cCJARfCY+oR2HzOG/X30 Lsl0Q57/KoDZGMQS4260X+nAYlFtndrTZ48UFJ4HtLY/5+OChgr4SEXRlbGDzqvNy06m Nd3H3xfX8NTc9s74xkG+URAiI06IkHQj67IHxNgVqWcQa7um+PEEVs2c7ekV6MYvuEFJ WD0744G5Bi5+/gJ0s4ZoWnWcC86928KvMG6c7p3SS/4WbQ8jI4dZYVyEjgiG7YAJjRbk 37xg== MIME-Version: 1.0 Received: by 10.42.84.16 with SMTP id j16mr11258008icl.7.1343101783451; Mon, 23 Jul 2012 20:49:43 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 23 Jul 2012 20:49:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jul 2012 23:49:43 -0400 Message-ID: Subject: Re: agenda items for IETF 84 RTGWG From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 03:49:46 -0000 I have heard of no requests outside of: an update on MRT http://tools.ietf.org/html/draft-retana-rtgwg-eacp http://tools.ietf.org/html/draft-zhang-greennet Are there really no other requests? We're going to be setting the agenda tomorrow. Alia On Tue, Jul 10, 2012 at 2:31 PM, Alia Atlas wrote: > RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50 > (Afternoon Session II). > > Please send all agenda requests to myself and Alvaro. > Presentations are requested before IETF starts (by Friday July 27). > > Thanks, > Alia From balajivenkat299@gmail.com Tue Jul 24 04:57:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763ED21F8604 for ; Tue, 24 Jul 2012 04:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Th7TeZSW6uCN for ; Tue, 24 Jul 2012 04:57:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D821B21F8601 for ; Tue, 24 Jul 2012 04:57:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so12958617pbc.31 for ; Tue, 24 Jul 2012 04:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0FpvqxyKLqDIz3LfDdamE/MqaUHfKpJ03v9YHMIcyXc=; b=QlkfVdUzZhV1WH5UzF4eauT4SdarhvX9Nhy+F23qDyL3hWUtoyo0jma6F5i+MgVor9 2Mb3vru4dqyuJuADpb8Z1uk8zolL5Igl7rR9o0AFQaspZ4l76Ls1SuCkgGRkXGaGjWpv 43lXBJSBCkEMIU6khjPiKQL4ULBR1qybCaZ0GvV7HtoFbHDGketwxnxdC7Qrlq9nu4Rk SSJ9j2U6HGjfODOTIYXwEYQYOtLFY/Uep0MwdkamKp7yPNHCHiTf/5ZmeI8rv8LejVCj FdMYULn5U3Cx4LNQyQMJZlQJoZV6tGkZfGLYY3N0rdrR6L8dPW4PKhkePUcxqSZqitr8 0ZkA== MIME-Version: 1.0 Received: by 10.68.134.201 with SMTP id pm9mr45032495pbb.49.1343131074373; Tue, 24 Jul 2012 04:57:54 -0700 (PDT) Received: by 10.68.39.228 with HTTP; Tue, 24 Jul 2012 04:57:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Jul 2012 17:27:54 +0530 Message-ID: Subject: Re: agenda items for IETF 84 RTGWG From: Balaji venkat Venkataswami To: Alia Atlas Content-Type: multipart/alternative; boundary=047d7b10d02193274004c592125d Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 11:57:55 -0000 --047d7b10d02193274004c592125d Content-Type: text/plain; charset=ISO-8859-1 Dear Alia, This is with regard to the power metric drafts titled draft-mjsraman* in rtgwg group currently. We are from India and we unfortunately cannot travel to Vancouver for IETF84. We could probably make it to IETF85 in Georgia. One of our authors Shankar Raman will try and make it to Georgia next time. Till then we will be adding additional materials to these drafts and respin them before Georgia. We would like to request you to kindly book some slots for us in Georgia so that we can spend the sufficient time required to go over all the drafts in this category. Would be much obliged if you could kindly consider our request. thanks and regards, Balaji Venkat On Tue, Jul 24, 2012 at 9:19 AM, Alia Atlas wrote: > I have heard of no requests outside of: > an update on MRT > http://tools.ietf.org/html/draft-retana-rtgwg-eacp > http://tools.ietf.org/html/draft-zhang-greennet > > Are there really no other requests? We're going to be setting the > agenda tomorrow. > > Alia > > > On Tue, Jul 10, 2012 at 2:31 PM, Alia Atlas wrote: > > RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50 > > (Afternoon Session II). > > > > Please send all agenda requests to myself and Alvaro. > > Presentations are requested before IETF starts (by Friday July 27). > > > > Thanks, > > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --047d7b10d02193274004c592125d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Alia,

This is with regard to the power metric draft= s titled draft-mjsraman* in rtgwg group currently. We are from India and we= unfortunately cannot travel to Vancouver for IETF84.

We could probably make it to IETF85 in Georgia. One of our authors Sha= nkar Raman will try and make it to Georgia next time. Till then we will be = adding additional materials to these drafts and respin them before Georgia.=

We would like to request you to kindly book some slots = for us in Georgia so that we can spend the sufficient time required to go o= ver all the drafts in this category.

Would be much= obliged if you could kindly consider our request.

thanks and regards,
Balaji Venkat

On Tue, Jul 24, 2012 at 9:19 AM, Alia Atlas <akatla= s@gmail.com> wrote:
I have heard of no requests outside of:
=A0 =A0an update on MRT
=A0 =A0http://tools.ietf.org/html/draft-retana-rtgwg-eacp
=A0 =A0http://tools.ietf.org/html/draft-zhang-greennet

Are there really no other requests? =A0We're going to be setting the agenda tomorrow.

Alia


On Tue, Jul 10, 2012 at 2:31 PM, Alia Atlas <akatlas@gmail.com> wrote:
> RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50
> (Afternoon Session II).
>
> Please send all agenda requests to myself and Alvaro.
> Presentations are requested before IETF starts (by Friday July 27). >
> Thanks,
> Alia
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

--047d7b10d02193274004c592125d-- From alvaro.retana@hp.com Tue Jul 24 09:20:05 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7F21F8562 for ; Tue, 24 Jul 2012 09:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.417 X-Spam-Level: X-Spam-Status: No, score=-109.417 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Y68NK58ahdmk for ; Tue, 24 Jul 2012 09:20:03 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id DB09F21F852E for ; Tue, 24 Jul 2012 09:20:02 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 269D438126; Tue, 24 Jul 2012 16:19:58 +0000 (UTC) Received: from G2W2419G.americas.hpqcorp.net (16.197.128.79) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 24 Jul 2012 16:19:09 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.58]) by G2W2419G.americas.hpqcorp.net ([16.197.128.79]) with mapi id 14.02.0283.003; Tue, 24 Jul 2012 16:19:08 +0000 From: "Retana, Alvaro" To: Balaji venkat Venkataswami , Alia Atlas Subject: RE: agenda items for IETF 84 RTGWG Thread-Topic: agenda items for IETF 84 RTGWG Thread-Index: AQHNXs4I4bU6Or8fZEmZJrJ+Inx3nJc34RuAgACIZgCAAEft8A== Date: Tue, 24 Jul 2012 16:19:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.17] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE70635FFF6G2W2446americas_" MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:20:05 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE70635FFF6G2W2446americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Balaji: Please let us know when your travel plans firm up and we will be very happy= to consider your request at that time. In the mean time, I would suggest that you start a discussion of your work = on the list. Maybe wait until after the meeting in Vancouver to start the = discussion as I'm sure people will be "distracted" over the next couple of = weeks. Regards, Alvaro. From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of B= alaji venkat Venkataswami Sent: Tuesday, July 24, 2012 7:58 AM To: Alia Atlas Cc: rtgwg@ietf.org Subject: Re: agenda items for IETF 84 RTGWG Dear Alia, This is with regard to the power metric drafts titled draft-mjsraman* in rt= gwg group currently. We are from India and we unfortunately cannot travel t= o Vancouver for IETF84. We could probably make it to IETF85 in Georgia. One of our authors Shankar = Raman will try and make it to Georgia next time. Till then we will be addin= g additional materials to these drafts and respin them before Georgia. We would like to request you to kindly book some slots for us in Georgia so= that we can spend the sufficient time required to go over all the drafts i= n this category. Would be much obliged if you could kindly consider our request. thanks and regards, Balaji Venkat On Tue, Jul 24, 2012 at 9:19 AM, Alia Atlas > wrote: I have heard of no requests outside of: an update on MRT http://tools.ietf.org/html/draft-retana-rtgwg-eacp http://tools.ietf.org/html/draft-zhang-greennet Are there really no other requests? We're going to be setting the agenda tomorrow. Alia On Tue, Jul 10, 2012 at 2:31 PM, Alia Atlas > wrote: > RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50 > (Afternoon Session II). > > Please send all agenda requests to myself and Alvaro. > Presentations are requested before IETF starts (by Friday July 27). > > Thanks, > Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_C03AAF38AD209F4BB02BC0A34B774CE70635FFF6G2W2446americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Balaji:=

 <= /p>

Please let us know when y= our travel plans firm up and we will be very happy to consider your request= at that time.

 <= /p>

In the mean time, I would= suggest that you start a discussion of your work on the list.  Maybe = wait until after the meeting in Vancouver to start the discussion as I’m sure people will be “distracted” over the next co= uple of weeks.

 <= /p>

Regards,

 <= /p>

Alvaro.=

 <= /p>

From: rtgwg-bo= unces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Balaji venkat Venkataswami
Sent: Tuesday, July 24, 2012 7:58 AM
To: Alia Atlas
Cc: rtgwg@ietf.org
Subject: Re: agenda items for IETF 84 RTGWG

 

Dear Alia,

 

This is with regard to the power metric drafts title= d draft-mjsraman* in rtgwg group currently. We are from India and we unfort= unately cannot travel to Vancouver for IETF84.

 

We could probably make it to IETF85 in Georgia. One = of our authors Shankar Raman will try and make it to Georgia next time. Til= l then we will be adding additional materials to these drafts and respin th= em before Georgia.

 

We would like to request you to kindly book some slo= ts for us in Georgia so that we can spend the sufficient time required to g= o over all the drafts in this category.

 

Would be much obliged if you could kindly consider o= ur request.

 

thanks and regards,

Balaji Venkat

On Tue, Jul 24, 2012 at 9:19 AM, Alia Atlas <akatlas@gmail.com>= ; wrote:

I have heard of no requests outside of:
   an update on MRT
   http://tools.ietf.org/html/draft-retana-rtgwg-eacp    http://tools.ietf.org/html/draft-zhang-greennet

Are there really no other requests?  We're going to be setting the
agenda tomorrow.

Alia



On Tue, Jul 10, 2012 at 2:31 PM, Alia Atlas <akatlas@gmail.com> wrote:
> RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50
> (Afternoon Session II).
>
> Please send all agenda requests to myself and Alvaro.
> Presentations are requested before IETF starts (by Friday July 27). >
> Thanks,
> Alia
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtgwg

 

--_000_C03AAF38AD209F4BB02BC0A34B774CE70635FFF6G2W2446americas_-- From alvaro.retana@hp.com Tue Jul 24 12:27:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26AA11E808E for ; Tue, 24 Jul 2012 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.487 X-Spam-Level: X-Spam-Status: No, score=-109.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qcB9LiCK0MCb for ; Tue, 24 Jul 2012 12:27:43 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 45B6D11E80A4 for ; Tue, 24 Jul 2012 12:27:43 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id EB71C385A3 for ; Tue, 24 Jul 2012 19:27:40 +0000 (UTC) Received: from G2W2427G.americas.hpqcorp.net (16.197.128.80) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 24 Jul 2012 19:24:41 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.58]) by G2W2427G.americas.hpqcorp.net ([16.197.128.80]) with mapi id 14.02.0283.003; Tue, 24 Jul 2012 19:24:40 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Subject: RE: agenda items for IETF 84 RTGWG Thread-Topic: agenda items for IETF 84 RTGWG Thread-Index: AQHNXs4I4bU6Or8fZEmZJrJ+Inx3nJc45eGg Date: Tue, 24 Jul 2012 19:24:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 19:27:43 -0000 Hi! I just posted the Agenda for next week: http://datatracker.ietf.org/meetin= g/84/agenda/rtgwg/=20 As Alia mentioned below, we expect presentations by this Friday (July/27). Thanks! Alvaro. > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Tuesday, July 10, 2012 2:32 PM > To: rtgwg@ietf.org; Retana, Alvaro > Subject: agenda items for IETF 84 RTGWG >=20 > RTGWG is meeting this IETF on Tues July 31 from 15:20 to 16:50 > (Afternoon Session II). >=20 > Please send all agenda requests to myself and Alvaro. > Presentations are requested before IETF starts (by Friday July 27). >=20 > Thanks, > Alia From tnadeau@juniper.net Thu Jul 26 11:06:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9447E21F85F7; Thu, 26 Jul 2012 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 B1Kqd6m-KCHI; Thu, 26 Jul 2012 11:06:42 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB721F861E; Thu, 26 Jul 2012 11:06:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUBGHJN+nS851zOdeAP4iS+xW/auReO3Y@postini.com; Thu, 26 Jul 2012 11:06:41 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jul 2012 11:05:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 26 Jul 2012 14:05:19 -0400 From: Thomas Nadeau To: "mpls@ietf.org" , "rtgwg@ietf.org" , "pce@ietf.org" , "idr@ietf.org" , "alto@ietf.org" Date: Thu, 26 Jul 2012 14:05:18 -0400 Subject: Interface to the Internet Routing System (IRS) Discussion List Created Thread-Topic: Interface to the Internet Routing System (IRS) Discussion List Created Thread-Index: Ac1rWTdkMa/o1HJvQ46cDHHzjaMH4g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wardd@cisco.com" , Alia Atlas X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:06:43 -0000 We have created a non-WG mailing list to discuss IRS. The purpose of the list: This list is for the discussion of an interface to the routing system (IRS)= that allows applications to rapidly and dynamically install routing state = into routers, and to learn sufficient information from routers to make time= ly, data-based decisions about what routing state to specify. Such an inter= face would facilitate control and diagnosis of the routing infrastructure, = as well as enabling sophisticated applications to be built on top of today'= s routed networks. The IRS is conceived as a programmatic, streaming inter= face for transferring state into and out of the Internet's routing system, = recognizing that the routing system and a router's OS provide useful mechan= isms that applications could harness to accomplish application-level goals.= A fundamental component of the IRS is a clear data model that defines the= semantics of the information that can be written and read. An initial framework document for IRS is available here: http://www.lucidvision.com/draft-ward-irs-framework-00.txt To subscribe, please visit the following: https://www.ietf.org/mailman/listinfo/irs-discuss From alvaro.retana@hp.com Sun Jul 29 14:16:46 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA92B11E80E0 for ; Sun, 29 Jul 2012 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.604 X-Spam-Level: X-Spam-Status: No, score=-107.604 tagged_above=-999 required=5 tests=[AWL=-1.006, 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 31ydWAcelkDB for ; Sun, 29 Jul 2012 14:16:46 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7598311E80AE for ; Sun, 29 Jul 2012 14:16:46 -0700 (PDT) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 068D91C236 for ; Sun, 29 Jul 2012 21:16:46 +0000 (UTC) Received: from G1W3627G.americas.hpqcorp.net (16.193.48.85) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sun, 29 Jul 2012 21:15:07 +0000 Received: from G2W2446.americas.hpqcorp.net ([169.254.7.58]) by G1W3627G.americas.hpqcorp.net ([16.193.48.85]) with mapi id 14.02.0283.003; Sun, 29 Jul 2012 21:15:07 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Subject: Scribe for rtgwg Meeting Thread-Topic: Scribe for rtgwg Meeting Thread-Index: Ac1tqh0JKQxtv7unSsC12+NX0sZiaQ== Date: Sun, 29 Jul 2012 21:15:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.217.50.26] Content-Type: multipart/alternative; boundary="_000_C03AAF38AD209F4BB02BC0A34B774CE70636E28FG2W2446americas_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 21:16:47 -0000 --_000_C03AAF38AD209F4BB02BC0A34B774CE70636E28FG2W2446americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We need a volunteer to take notes at the rtgwg meeting this week. Thanks! Alvaro. --_000_C03AAF38AD209F4BB02BC0A34B774CE70636E28FG2W2446americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

We need a volunteer to take notes at the rtgwg meeti= ng this week.

 

Thanks!

 

Alvaro.

--_000_C03AAF38AD209F4BB02BC0A34B774CE70636E28FG2W2446americas_-- From akatlas@gmail.com Mon Jul 30 13:09:45 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8786D21F85CE for ; Mon, 30 Jul 2012 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EqLSnFYimsVZ for ; Mon, 30 Jul 2012 13:09:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0555021F85CD for ; Mon, 30 Jul 2012 13:09:44 -0700 (PDT) Received: by yenq13 with SMTP id q13so5712116yen.31 for ; Mon, 30 Jul 2012 13:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q39avYUYfE0VTyis74neTFdB18ghN547EepWsGOwTh0=; b=koMMUcBUwpz/5TGXYG8t6UXs5K5LNi9VcVfdoczzemjY/dSyj9m54fHejpXUY5Jc6l v+Wt7ce9o7XN1pNKxiHzVJUxCfLeuwVGXnsoinLMAmdniMGvuRj9xaKuTmNWWsiL3rNN bCAIreEIUoVGI5Bfs1lAvbQvgUtUvfuDswArorUZJLBUr3rJ7m7joEtCLGNUk0LQ9jaR o0szu9kThYD42TMz2uQmSpXueopvoG+x7/8P4WIAz0bjAXtFJ/x2FOqzEs1pGhF7s5oe CNhFzvba3DOWt+pNwueoNbD28wnWIJ0/i4whRTqfvnoT2ctEAarENxRkK7vVmieDSdha +zjQ== MIME-Version: 1.0 Received: by 10.50.237.72 with SMTP id va8mr340537igc.17.1343678984162; Mon, 30 Jul 2012 13:09:44 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 13:09:44 -0700 (PDT) Date: Mon, 30 Jul 2012 16:09:44 -0400 Message-ID: Subject: presentations for tomorrow are up From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:09:45 -0000 For those few who can't wait until tomorrow, you can see tomorrow's RTGWG presentations today. They've been uploaded. Thanks to everyone for getting their presentations in. Alia From akatlas@gmail.com Mon Jul 30 21:48:54 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0221F854F for ; Mon, 30 Jul 2012 21:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pNR59ph8Vv3W for ; Mon, 30 Jul 2012 21:48:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0C21F8421 for ; Mon, 30 Jul 2012 21:48:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so6099999yen.31 for ; Mon, 30 Jul 2012 21:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9Uk4LAsYParAz6EKvN/1EhqTfdiDc6FLUpTn5HTmv2k=; b=xDmWzTbhB0qZFY7p5QdoA9m1IW718qanO3TEX9smwOp+UisBzJswYKQSqEeLI0wSMg vuCFKlSMFI204wKuR96p7uQFlmkTI1Duw2BxE9TJMjV9FoXdyLphuw6R91w1UcSJelIN ai07Sf0Hw5Wlv3sw2EOccnhZKq9rn2XWdW9p0kgVT+03tIP/+zW3DcO9Y78wQ3HV/BrJ FhRSfeWlkiP3KThczXCDRAdOX7fAPNpd+l42Ws7zpEpIk7ByQc7lgS+UT3g7t8ZPW2XU GSZddpYbo2obcXpUf9MzLXtxsZjdTr8R5dLNfITVXHKeL1sWmKtyYyYNfihe2JfY+l+n C45A== MIME-Version: 1.0 Received: by 10.50.213.98 with SMTP id nr2mr803793igc.71.1343710126470; Mon, 30 Jul 2012 21:48:46 -0700 (PDT) Received: by 10.50.34.169 with HTTP; Mon, 30 Jul 2012 21:48:46 -0700 (PDT) In-Reply-To: <20120731044425.12307.52108.idtracker@ietfa.amsl.com> References: <20120731044425.12307.52108.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 00:48:46 -0400 Message-ID: Subject: Fwd: NomCom 2012-2013: Third Call for Volunteers From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 04:48:55 -0000 For those who aren't on the main IETF mailing list.... NomCom is very important - and was quite a good experience when I did it. If you qualify and can do it, do volunteer! Alia ---------- Forwarded message ---------- From: NomCom Chair Date: Tue, Jul 31, 2012 at 12:44 AM Subject: NomCom 2012-2013: Third Call for Volunteers To: IETF Announcement List The NomCom 2012-2013 Call for Volunteers is nearing its conclusion. If you are considering volunteering to participate in the 2012-2013 NomCom, please volunteer soon. Individuals willing to serve on this year's NomCom must send email to nomcom-chair@ietf.org on or before Sunday, August 5. General information on this year's NomCom (including a list of positions to be filled) can be found at: https://www.ietf.org/nomcom/2012/ I am pleased to report at this time we have 98 qualified individuals who have generously volunteer their time to serve on this year's NomCom. However, last year the volunteer pool consisted of 120 members of our community and I would hope that we can have at least as many volunteers in the pool this year. Therefore, if you are eligible to serve on this year's NomCom (i.e., you have attended 3 of the last 5 IETF meetings), please consider volunteering! The success of the NomCom process depends on randomly selecting a committee that is a representative sample of the our community. We endeavor to have a NomCom reflecting the diversity of experience and viewpoints that is our community's greatest strength. However, to achieve this goal we must have the largest possible pool of volunteers that from throughout the IETF community. If you have volunteered before 15:00 UTC on July 30, 2012 and you have not received a confirmation email from me, then an error has occurred and I would request that you resend your email. The 98 qualified individuals who have thus far volunteered are listed below. I apologize for any errors in this list, please notify me of any errors as soon as possible. Sam Aldrin, Huawei Alia Atlas, Juniper Ignas Bagdonas, Cisco Marcelo Bagnulo, Universidad Carlos III de Madrid Lou Berger, LabN Consulting Deborah Brungard, AT&T John Brzozowski, Comcast Randy Bush, IIJ Dennis Cai, Cisco Daniele Ceccarelli, Ericsson Gang Chen, China Mobile Mach Chen, Huawei Andrew Chi, BBN Uma Chunduri, Ericsson Andras Csaszar, Ericsson Subir Das, ACS Hui Deng, China Mobile Keith Drage, Alcatel-Lucent John Drake, Juniper Donald Eastlake, Huawei Charles Eckel, Cisco Mehmet Ersue, Nokia Siemens Networks Miguel Garcia, Ericsson Wes George, Time Warner Cable Richard Graveman, RFG Security Eric Gray, Ericsson Jeff Haas, Juniper Wassim Haddad, Ericsson Stephen Hanna, Juniper Sam Hartman, Painless Security Jia He, Huawei Giles Heron, Cisco Paul Hoffman, VPN Consortium Christer Holmberg, Ericsson Lee Howard, Time Warner Cable Fangwei Hu, ZTE Jon Hudson, Brocade Andrew Hutton, Siemens Enterprise Communications Cullen Jennings, Cisco Yuanlong Jiang, Huawei Sheng Jiang, Huawei Lizhong Jin, ZTE Hadriel Kaplan, Acme Packet Stephen Kent, BBN Ari Keranen, Ericsson Ning Kong, CNNIC Jouni Korhonen, Nokia Siemens Networks Mirja Kuehlewind, University of Stuttgart Eliot Lear, Cisco Hongyu Li, Huawei Guoman Liu, ZTE Dapeng Liu, China Mobile Wenhu Lu, Ericsson Yuxia Ma, ZTE Andrew Malis, Verizon Terry Manderson, ICANN Scott Mansfield, Ericsson Luca Martini, Cisco Alexey Melnikov, Isode Limited David Meyer, Cisco Monique Morrow, Cisco Thomas Nadeau, Juniper Karen O'Donoghue, Internet Society Borje Ohlman, Ericsson Dimitri Papadimitriou , Alcatel-Lucent Keyur Patel, Cisco Radia Perlman, Intel Labs Teemu Savolainen, Nokia Benson Schliesser, Juniper John Scudder, Juniper Karen Seo, BBN Arturo Servin, LACNIC Shuo (Sean) Shen, CNNIC David Sinicrope , Ericsson Haibin Song, Huawei Tom Taylor, PT Taylor Consulting Pascal Thubert, Cisco Mark Townsley, Cisco Tina Tsou, Huawei Gunter Van de Velde, Cisco Bill VerSteeg, Cisco Thomas Walsh, Juniper Yinxing Wei, ZTE Stephan Wenger, Vidyo Magnus Westerlund, Ericsson Steven White, Alcatel-Lucent Ijsbrand (Ice) Wijnands, Cisco Qin (Bill) Wu, Huawei Jiankang Yao, CNNIC Leaf Yeh, Huawei Lucy Yong, Huawei Lixia Zhang, UCLA Zhaohui (Jeff) Zhang, Juniper Dacheng Zhang, Huawei Yi, Zhao Huawei Qian (Cathy) Zhou, Huawei Ning Zong, Huawei Glenn Zorn, Network Zen The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. Thank you, Matthew Lepinski nomcom-chair@ietf.org (or mlepinski.ietf@gmail.com)